How to reduce the amount of code

I always think that the Code should be part of the architecture, and that is not enough to express the importance of code quality. I know that this is contrary to the definition of the traditional school's party architecture. It is generally believed that the architecture is a macro process of describing the design blueprint. However, the gradual prevalence of agile methods has slowly begun to subvert this design argument. The code should not only reflect the principles and ideas of the architecture, it also influences the architecture through code, and even uses code to supplement and improve the architecture.

Yourdon and Constantine believe that the overall cost of the software system is equal to the development cost and maintenance cost, while the latter cost is far greater than the development cost. Maintenance costs include understanding, change, testing, and deployment costs. The so-called "Understanding" mainly involves how maintenance personnel understand the code, especially when a change occurs. Only a clear code structure can help us understand the system, and only a clear code structure can improve the code quality. So I think code is part of the nano architecture.

After raising the code to a certain height, let's take a look at how to improve the code quality. In addition to keeping the code clear and readable, the number of codes has also begun to attract people's attention. Infoq recently published the news "code is debt, the less the better", according to the lean method inventory to get the conclusion of reducing the number of code. Michael feathers, author of The Art of code modification (working processing tively with legacy code), is best at dealing with legacy code. He believes that "code is also our inventory and needs to be minimized ." The ideas extracted in this news are warning words that arouse our attention to the number of codes.

In my opinion, the best way to reduce the amount of code is to improve the reusability of the Code. The programmer's cultivation path holds that repeated types include:
1. imposed repetition
2. Unintentional repetition
3. Non-tolerable repetition
4. repetition between developers

In summary, I think there are three reasons for code duplication:
1. Laziness, so we can tolerate bad code;
2. Insufficient skills, and unnecessary duplicate code may often occur;
3. Lack of communication, lack of collaboration between teams, and repetitive manufacturing.

The key to reuse is to maintain an appropriate granularity and decouple the relationship. The granularity is manifested in the method level, that is, many small methods need to be compiled, find the responsibilities that can be called repeatedly in the class, and extract them as separate methods. Class-level granularity can adopt auxiliary classes, or by searching for commonalities, we can extract common features in a generalized way. At the module level, the Reuse Principle of modules should be taken into consideration to reasonably remove the dependency between modules.

The main reason for a lot of bad and messy legacy code is that the distribution and separation of duties are not good enough. If the assignment of duties is inaccurate, the code structure may be unclear, and the separation of duties may lead to code duplication. After too much work to maintain the legacy code, I often find that the legacy code is not well divided into modules, but is rate-oriented. Sometimes there may be a huge project, contains all objects such as data access, business logic, and interface performance, which means that it does not have a reasonable layered architecture. During design and development, I pay great attention to the division of modules and try to avoid bidirectional dependency and circular dependency between modules. At the same time, we also need to think about the division and definition of modules from the perspective of release. When coding, I will think about the ownership of the class and put it in a proper position to express its responsibilities without generating ambiguous dependencies.

We can also identify and reuse Use Cases. In the use case diagram, examples that contain, expand, and generalize relations may all be potential reuse points.