devops: Discuss team code quality management from the broken window effect

Article Directory

guide

Recently, a friend complained to me that the code of the module he participated in was very chaotic. There were public components with repeated functions, non-standard code and other problems. I had the urge to refactor the entire module, which aroused my thinking.

common problem

I believe that friends who are doing development in the team will have encountered these similar problems, because the level of team members is uneven, frequent changes in requirements to adjust the code, no good management and development specifications, etc., resulting in confusion in the overall code structure and repeated creation. Wheels etc. In my opinion, these results can often be explained by the concept of "broken window effect". If the main person in charge of the module can play a good management role in the team and the module code, these situations can be effectively avoided.

1. What is the broken window effect

A broken window, if left unrepaired for any length of time, will gradually give the building's inhabitants a sense of abandonment, a sense that the management doesn't care about the building. Then another window broke, people littered and graffiti started, and serious structural damage began. In a relatively short period of time, the building was damaged beyond the owner's willingness to repair it, and the sense of abandonment became reality.

2. Combined with the actual team development situation analysis

For example, during the development process, if the developer does not reasonably abide by the code specification, the non-standard code written is like a broken window in the building. When the person in charge does not patch and adjust this window, developers do not abide by the regulations and become more and more casual, coding graffiti at their own will. Problems such as non-standard codes of the entire project have gradually accumulated, and structural damage has begun, which will eventually lead to a sense of abandonment becoming a reality. Among them, the module leader plays a crucial role.

3. Some suggestions from friends

In this regard, I also consulted some more experienced friends, and they also shared with me some of their views on module code quality management in team development:

**A background development friend: **A module needs to have a person who is the main person in charge, and can manage and control the entire module. The most fundamental reason for code changes caused by repeated changes in requirements is that the main line of requirements has not been clarified. It is a normal phenomenon that the level of team members is uneven, which can be resolved through reasonable manpower arrangements. In most companies, the functions required by the main line will be handed over to experienced people, and newcomers will be responsible for more business functions that do not affect the main line.

The design phase is very important. The person in charge conducts regular code quality spot checks.

**A front-end development friend: **Communication is very important, don't be stingy with time to communicate, as a team, every communication is meaningful and necessary. Keep a development log. Record the daily development content, and write clearly the ideas and reasons for the modification. It is convenient for others to take over the code in the future. In this way, you can quickly locate and clarify the affected areas during modification, and avoid information loss or omission during handover, avoid repeated development, and improve code reuse.

A person in charge is needed, and this person in charge must do these tasks well, for example, some bad codes that are not conducive to the team should be corrected in time to help interns quickly integrate into the team.

4. Summary

The common points above all think that it is crucial for the person in charge to play a management role, which is also the key role that the management department needs to play in the "broken window effect". Team development improves the efficiency of development, but also increases the difficulty of code quality management. Reasonable and effective management can make the building maintain a good structure. If you have other good methods for team code quality management, welcome to comment and discuss together!

Guess you like

Origin blog.csdn.net/zhanggqianglovec/article/details/131501125