How to Prevent code corruption

Many teams have this problem. Code It was originally well designed. After a while, the code will become hard to understand, difficult to maintain, and difficult to modify. Why? I have been thinking about this issue.

Let's first look at a person's situation.

1.ProgramMember Growth

Newbie code

New users have no experience in code, and basically do not consider code design. If the code size is slightly larger, they will be confused.

Advanced Code

Small Scale

Large Scale

Advanced users already know how to design code and code rules, but they are generally limited to one module. A large scale makes it difficult to maintain inter-module calls.

Code of experienced users

Experienced code: the internal code of the module is neat and tidy, and the layers between modules are clear. There are design patterns and mature systems. Keep code clean for a long time.

So what will happen to a team? It seems that as long as we have a bunch of experienced people to develop the code, there will inevitably be no problems with the code. Unfortunately, this is not the case.

2.Background

Diversity of code styles

This is the case.

This is also true.

You can see different code styles, different design ideas, and different design concepts. Every programmer has his own code personality.

Team level differences

There are new people, skilled people, and good people in a team. A well-designed architecture may deteriorate.

3.Cause

Style Fusion

When programmer A and programmer B are together, there will be the following changes:

The originally neat Code became untidy.

Progress pressure

The progress leads to the generation of flying lines, and undesigned code is generated on the pretext of time.

Modify one module for multiple users

4.Nature

The essence of all code corruption issues is communication issues. Both of them can be used to modify others' code.

When a programmer modifies the code of another programmer's module without communication, he may not understand the design ideas, code structure, and logic structure of this module, so I modified it according to my own ideas, although it seems that the current problem has been solved. But it leaves an unstable factor. This factor can be solved through refactoring. However, everyone is very "busy", and no one has time to review the Code, to communicate where I changed your code. As a result, more and more unstable factors lead to code decay.

The fastest rotten code must be the code modified by many people. On the contrary, the Code maintained by a person for a long time won't be so easy to rot. Because a person does not have a communication problem, when he modifies the code, he knows exactly how he should modify it and how to make the code more clean.

5. Solution

There is only one way to communicate more.

When you need to modify others' code at work, you should first contact this person. Clarify the logic to be modified, and then try to let him modify it. This ensures that one piece of code is maintained by one person, with the least cost.

If this person is really busy and has no time, you must explain your plan and ask him to make a suggestion. It is better for him to tell you the design idea and code design of this module, logic Design, current problems, and future plans. Make sure that the modified Code is reasonable.

The ideal state is that the entire team's thinking is highly unified. N people can work as one person. This requires long-term integration of the team.

You can think that we can't develop a specification? The specifications on paper usually do not work. The specification of a successful team is the experience summarized after the entire team reaches a high level. It is not so much learning experience as implementing regulations. The MFC code is written by one person, and all office products are made by one person. This is highly unified. We moved Microsoft's specifications, which may not necessarily be effective.

Code decay is caused by modifying others' code without in-depth understanding.

Summary:

• The solution is to ensure in-depth communication before any modifications.
• A simple rule is that a module only allows maintenance by one person.
• The ideal state is that the entire team is highly unified.