How the "shit mountain code" was made
Shishan code has always been criticized by most people in the software industry. It refers to a bunch of codes that are piled up irregularly and don't even want to look at them. These codes can run, but cannot be iterated, are not efficient, but cannot be discarded, so they form the content you have to pay attention to. I am a developer with code cleanliness. From the first day I entered the industry, I would want to optimize any bad code I saw. At the same time, I try my best to understand the ideas of the predecessors, and sum up several key reasons for the formation of Shishan code:
- There was no architectural planning and architectural design at the initial stage of the project, including business architecture and technical architecture (technical architecture design that does not consider business architecture will eventually become nonsense)
- After the business scale is formed in the middle of the project, only the business iteration is considered, and the scalability of the technology is not considered, resulting in the final technology not being updated, and business development is complicated
- The construction of technical teams is not systematic. Many teams do not have excellent technical personnel in the early and mid-term. The technical atmosphere of the team is backward, and the design capabilities of core technical personnel are short, resulting in a lack of system capabilities.
- Product technical cognition is incomplete and inconsistent, that is, many product technical testers do not have a clear understanding of the system and system products they want to make, resulting in no concept of whether the project launched during the development process is good or bad
- The core members of the team lack architectural thinking, and architectural thinking can help us understand the original appearance of things. If we work without this kind of thinking, we will be confused when faced with piles of codes.
From the above reasons, in fact, most of the problems are caused by the team and the core members of the team. The formation of Shishan code is not caused by a single person, but is formed by the team's long-term irregular development. If you want to avoid it, you need team building and core personnel training.
Key Steps to Optimizing Your Code
Most of the shit mountain code is valuable. For those of no value, either do not need to be updated, or can be discarded directly. Don't give up. For various systems, various codes face different problems. Based on my years of experience in refactoring and optimizing projects, I summarize the following steps:
1. Deep understanding of business value
Many people will complain that other people's code is bad, but when you ask him how should this code be optimized? Many people can't tell why. I just feel that the code is not easy to read and understand, it is not easy to maintain, it is just bad. If it is only to such an extent, then it is conceivable that your code will also be given such an evaluation by others a few years later. One of the key sticking points leading to these is that there is no in-depth understanding of business value (in addition to personal technical capabilities are also important).
The business value determines the effort you put into the corresponding business module and the number of lines of code you write. And what needs to be preserved for expansion and so on. For some codes that have no key business value, there is no need to do too much optimization, as long as the function is completed.
Business value is the ultimate goal of our software projects. Only by understanding the business value can we determine the final direction and optimize in which direction. If there is no goal, just to optimize the code for technology, then it is unnecessary to spend a lot of time, because there is not enough value output in the end.
2. Analyze the original business structure and technical structure
In the process of in-depth understanding of the business, it is also important to focus on analyzing the original business architecture and technical architecture. In this process, a global abstract understanding of the original business scenarios, business functions, business capabilities, and business elements is required. And outline the original business architecture, but also figure out the original technical architecture.
With the iteration of technology, there will be many choices for the implementation of various systems. For the same function, different technologies will be used to achieve different difficulties and business application capabilities. For example, message events, databases, caches, etc., there are many implementations of these. The implementation methods are different, and the problems faced are also different. This is also within the scope of consideration when doing technical architecture code optimization.
3. Design new business architecture and technical architecture
After understanding the existing business system and business architecture technical architecture, we need to optimize the code, then we need to re-design and optimize this business architecture and technical architecture based on the future business value system. The new business architecture helps us re-plan the original code, divide business modules, and layer business logic. The new technical architecture can help us introduce a new technical framework system without the code logic as much as possible, so that the system has stronger support capabilities.
Fourth, the code is divided into functional blocks and classified
In the code transformation planning, we still need to classify the code into functional blocks. Blocking is mainly based on the new business architecture. Grading is mainly based on business value. The priority of modification suggestions for different situations is as follows:
- High business value and high reuse rate of business modules
- High business value, poor logic scalability, high reusability, refactoring may be considered
- High business value, poor logic scalability, low reusability, refactoring may be considered
- Average business value, high reusability of business modules
- No value, high reusability of business modules
Generally speaking, priority should be given to optimizing business modules, and at the same time, priority optimization should be given to those with high reuse. For poor reusability, there is basically no need to deal with those of little value. Code with high reusability should be optimized and refactored in time.
5. Promote the optimization of Shishan code
The previous four steps are all theoretical level. If you want to actually optimize, some capabilities that you need to have in the process of transforming the code are basically necessary. I personally think that the following aspects are indispensable:
- To understand the code, you need to be able to read, analyze and debug various design paradigms and pattern codes as well as project source code
- Be able to divide the previous historical code into blocks. Don’t rush to change the logic during the optimization process. Blocking is to split the code into small modules, allowing more people to optimize together. The splitting process is mainly to refine the structure standardized coding style
- Collaborative transformation, if resources allow during the optimization process, remember to work behind closed doors, you need to cooperate with others, optimize together at the same time, lead the code block by yourself, and then everyone can optimize the collaborative efficiency together to improve
fully aware of Shishan code
How to fully optimize Shishan code? In theory, no one can say that their code is absolutely perfect. Most of the code will have room for improvement and optimization in terms of technical theory and future expansion capabilities, so what kind of code can be considered to have completed system refactoring and optimization and completely understands Shishan code? The following criteria are considered necessary:
- The business expansion point is clear, and the business value can be continuously improved.
- High scalability, rapid iteration over a long period of time
- High maintainability, less prone to failure
- Code can be standardized and managed