AtkFrame

Refactoring and reuse are an ancient topic in software.

In daily software project development programs, how to ensure the strength of the team's code and maximize the consistency of code in the changing process is difficult to control in project development. We can use various source code management and standard workflow systems and the increase of staff in various positions to control it. However, over time, due to the addition of various levels of developers, the code becomes difficult to manage.

But the market and customers always look unreasonable to our software. When we deliver the software products to our customers with confidence, we still have to deal with various accusations. Some demands are repeated, "No, this has not met our needs at the time, different from what I thought." In the constant changes and repeated, the code has been modified beyond recognition, and the team is helpless.

From actual management, we cannot completely eliminate the combination of code and the confusion of code. Every programmer has his own world in his heart. As the saying goes, "There is no second in literature and no first in martial arts." Every programmer will think that his code has no problems. As a project manager, you can only minimize the changes in the human factors of the programmer, so that the larger the standardized code occupies in the project. If this is the standard code generated by the tool, then when the demand changes, repurchasing the code becomes very easy and easy to control.

If you use tools to generate standard code for users and quickly build a visible demo for users during the communication with customer needs at the beginning of the project, the project requirements will become clearer and easier to control. Although this is still a big gap from the final delivered product, it can still reduce the clarity of customer needs. If we separate controllable code from non-controlled code during production, then when customer needs change later, the tool can still refactor the changing needs.

Let technically excellent personnel build basic libraries and template common functions used in daily development. In this way, framework-tool-templates will become a container of technology and experience in the team, making redevelopment easier, controllable and stable. We do not need to write a lot of time on those repetitive and heavy attribute codes, and constantly copy various attributes. When the requirements change, we will also make a lot of time cloud corrections. We should give more time to communicate business needs with customers and write robust application designs. Then we should use the correct framework, gradually accumulate reusable function support libraries, and make the functional modules low-coupling, and use code tools to template various function calls. This not only ensures the coding consistency, but also minimizes the labor intensity of coding and reduces the precious time consumed by repeating simple codes, but also allows organizations and teams to coordinate technology with less time and money investment.

A good architecture can cope with different application needs, but there is no feasible and versatile architecture. Otherwise, I won’t have to discuss the architecture issue if I haven’t here. This is not only a problem of code. As time goes by, the progress of various programming technologies has made some originally complex problems simpler and easier to implement functions. Customer needs are always greedy and the requirements are more complex, making new demands arising, and technology implementation also requires more energy and time. Because of this, we should not spend time and energy on endless reconstruction at the same time, but should make writing code more tool-oriented and template-oriented to replace it with a more fashionable word, which is more intelligent.