Can code rot be avoided?

[[409216]]

If you leave an apple on the table and ignore it, it will slowly go bad. Code is like an apple, and it will rot. Bad code is like a bad apple, it will rot more easily and rot faster. After working for a long time, the focus has shifted from individuals to the team as a whole. I wondered: Is code rot really inevitable? Is there any way to avoid code rot?

Can code rot be avoided?

I thought about this question for a long time, and later I found the answer: code decay is inevitable, it's just a matter of time. Although it's frustrating, it recognizes the essence of things and is on the right path. This is better than being unwilling to accept it and then making the wrong decision.

I came to the conclusion that code rot is inevitable after much thought. The quality of code depends on many factors, including but not limited to: the urgency of requirements, the degree of change of requirements, the technical ability of team members, the happiness of the team, etc. These factors will affect the quality of code in different ways, thus causing the code to continue to rot.

If a requirement is particularly urgent, we will not consider how advanced the code structure is to achieve it, but will just start working on it. After all, time is our real enemy now. The quality of the code is definitely not that high, and the considerations are not that comprehensive. The progress bar of the code decay will move forward quickly.

The degree of demand change will also affect the degree of code rot. If the demand changes back and forth greatly, it will be difficult for us to design a unified architecture to adapt to the demand. At this time, forks will appear. When there are too many forks, the code structure will be difficult to understand. Code rot will naturally occur.

The technical ability of team members is also a very important point. Many times we hope that everyone can use better code structures, such as design patterns, and use encapsulation ideas to write code. However, the abilities of team members are different. Some people are better at coding and have a passion for coding, so they can do a good job. But some people are just less capable and it is difficult for them to write such good code.

Simply put, it is impossible to completely avoid code rot through certain process specifications. Note that I am talking about "completely avoiding" is impossible. No matter how well you do, your system may need to be refactored after two or three years. This is normal. But we can use some process specifications to slow down the occurrence of code rot.

It is very important to figure out whether our goal is to completely eliminate code rot or to slow it down. Only by setting the right goal can we avoid making wrong decisions and have more confidence when we formulate specific actions.

How to slow down code rot?

There are many ways to slow down code decay, but I think the two most common, most profitable, and easiest to implement measures are: technical solution review and code review.

To write a technical solution, simply put, is to think about the technical solution before you develop it. What is the overall requirement, and how do you want to achieve it? How do you want to adjust the table structure? How does the data flow from front to back? What changes do you want to make? The technical solution review is to bring in students who are familiar with this business and let them look at your technical solution together. See if there are any problems with this implementation solution, and if there is a better way to implement it?

Through technical solution review, we can basically avoid major demand problems and ensure that demand changes are consistent with the original system design. Even if we have to choose another method and a design fork occurs, everyone knows the background of the matter, which is more conducive to solving the problem later.

CodeReview is the final check of the technical solution. Often the technical solution is A, but the code becomes B as it is being written. The emergence of CodeReview can avoid this problem. Of course, CodeReview has many other benefits, such as improving code quality, etc.

Summarize

Code rot is inevitable. Almost all systems are experiencing varying degrees of code rot, and most systems need to be refactored every two or three years. All we can do is slow down the speed of code rot so that the system can last longer. Technical solution review and Code Review are the two most basic and useful methods to slow down code rot.

In Zhou Zhiming's latest book, Phoenix Architecture: Building Reliable Large-Scale Distributed Systems, he also said:

Architecture decay is very similar to the aging process of organisms, and the reasons are subtle changes that occur over time. If you have participated in the development of multiple projects or products, you should be able to resonate with the following scenario: At the beginning of the project, the team will spend a lot of time deciding what technology system, architecture, platform framework, and even development, testing, and continuous integration tools to choose. At this time, it is like a child choosing his favorite toy. I believe that no matter what the result of the decision is, the team will be happy to choose what they want to choose, and firmly believe that their choice is correct.

The departure of old members and the joining of new members mean that the team always needs members who can understand the old code and complete new functions. Technical experts occasionally come to review or put out a fire, but at best they can only be considered a last-minute effort. On the other hand, the code will gradually get out of control. Over time, there will inevitably be some requirements that are not suitable for the original design. Tight deadlines, heavy tasks, complex business, unfamiliarity with code, etc. will all become reasons for compromise to incur a technical debt. Every time the bottom line of principles is slightly breached, it may be torn and magnified into a shocking bloodstain by the broken window effect, eventually accumulating to the point where every newcomer can immediately smell the stench of old age and decay.

Architecture decay is as inevitable as biological aging. Elderly people quitting, trust joining, tight deadlines, heavy tasks, and other reasons are all technical debts that we cannot avoid. As for code decay, evolutionary design may be a solution. Simply put: evolutionary design does not pursue perfection, but pursues suitability within a certain "shelf life", so that the appropriate architecture can play its value in a reasonable life cycle.

Evolutionary design is an architectural approach proposed by ThoughtWorks. Whether it is generational evolution or gradual evolution, it is controversial. It is not only a science of construction, but also a science of destruction. Neal Ford elaborated on the idea of ​​evolutionary architecture in detail in Building Evolutionary Architectures: Support Constant Change, which has received a lot of attention, but not all of its views can be widely recognized. If you are a manager, it may be difficult to accept the view that it is those systems that work normally that lead to a decrease in R&D efficiency; if you are a programmer, you may not be able to accept the conclusion that the higher the code reusability, the lower the availability, which is contrary to previous cognition.

After we think clearly about code rot, perhaps we can accept the rotten code in the system more objectively and calmly. Because we know that code rot is a natural law and is inevitable. What we can do is to slow down the rot as much as possible and let the system play its value within a reasonable life cycle.

This article is reprinted from the WeChat public account "Chen Shuyi", which can be followed through the following QR code. To reprint this article, please contact Chen Shuyi's public account.