Recently, I was analyzing the existing code and extracting a part of the logic for service. During the analysis, I found that there are many "pits" in it. During interviews with relevant responsible persons, it was found that most programmers have the following habit:
- Faced with a new demand, the usual practice is to use the existing design completely, without considering whether the existing design is suitable for the new demand and whether to be transformed;
- Do everything possible to tinker with existing code and complete new features with minimal modification.
- In the face of old, useless code, deletes are rarely or never done to ensure the lowest risk.
Then, after a while, the code becomes so hard to read that only a few people grasp the "truth" in it. I personally think that this is acceptable if it is for a specific application with small scale, few users, short software life cycle, and few requirements changes. But in the Internet industry, the situation is completely different: the product cycle is very long (unless it is dead), the requirements change frequently, and the business direction changes frequently, which makes the code very difficult to understand very quickly (I recently refactored The logic is actually only about a year and a half later). The final result is that it cannot be maintained, re-developed, and enters the next vicious circle.
This situation has often been encountered before, and it is definitely not an isolated case, or even a common one. I jokingly told my colleagues that programmers are disgusted by the code written by others, and then make the already disgusting code even more disgusting, and then use it to disgust other people's process (he leaves or goes to other systems, others take over him work). This has a great impact on the programmer's entire living environment. Maintenance work no one wants to do, but most work is maintenance type work.
Why not do it in a different way?
- First, receive a requirement, evaluate whether the requirement is completely consistent with the existing structure, and make a small amount of adjustments for the places that do not match;
- Make sure every commit of the code makes the readability a little bit better (at least not worse) (from "97 Things Programmers Should Know")
- Architects or senior programmers fully participate in the project and provide corresponding support;
- Establish a better unit test, integration test, and automatic construction system to reduce the risk of refactoring as much as possible.
Some programmers have encountered the problem of splitting. For example, a programmer knows that the bottom layer cannot call the upper layer logic, but when encountering a process at the bottom layer, he must notify the upper layer, and no one tells him what to do, so he has to rely on it. In this regard, I can only say that almost every Java programmer knows about IOC, but there are not so many people who can deeply understand it. If you understand IOC, you will not know how to deal with it.
The tight construction period is also a problem. Of course, some programmers do not move the original logic because it is not really because of the construction period, but because of the construction period as an excuse, they are unwilling to do those thankless jobs. I personally attribute it to professionalism. I would rather get off work later and write better code. This is the "ethical" norm that professional programmers should abide by.