Programming sentiment: Why rewrite the code?

Document directory

• Code Quality
• Agile legends
• (1) external reasons
• (2) internal reasons

Most of the efforts of codoon are focused on code maintenance, at least in the department I work. From this point of view, the Code farming community has formed the following consensus:

The code is first written to people.

This requires coders to consider readability and maintainability when coding, using simple design, general methods, and a unified style.

Every code farm project has a code garden, where the code is well designed, elegant, and pleasing to the eye. The meaning of the Code to be expressed is very clear, and the comments are just right, so that you can understand the intent of the author without speculation. Even if a bug occurs, you can easily locate the error by checking the code without complicated debugging. No longer afraid of increasing and changing requirements, because the Code has good scalability.

But in fact, the vast majority of coders maintain code, but there are two other scenes: the quality of code is terrible, with hundreds of errors. coders face the surging bugs and new demands, working overtime, and getting exhausted. I have to admit that mainiao is a group that pursues perfection. With excitement, mainiao can't help but rewrite the code, and re-implement a system in mainiao, this will greatly improve the Code Quality and eliminate bugs. When demand changes, there is no fear, because it is easy to modify and expand, to embrace changes. From time to time, I think that if the system has been rewritten, how happy and beautiful future maintenance work will be. In fact, every rural code has, or at least has, such an impulse. We have to think deeply about the reason. Can rewriting really bring a beautiful ending to our imagination?

1. objective reasons

After the painstaking efforts of previous developers, the code library in front of us is like the garbage building that Wali persistently builds in the last day. It looks very neat on the surface and looks at it carefully, the code library is full of bad code.

Code Quality

The good code is roughly the same, and the bad code is varied. For example:

• The design is complex, or you cannot understand it without design.
• Severe coupling. modules and functions are intertwined and cannot be separated.
• Code already exists, serious code already exists, CTRL + C, CTRL + v code everywhere
• The style is messy, and the previous generation of code farmers have left their own unique code personality and marks.
• Code is discarded, useful, or useless, and the code is there, only increasing or decreasing
• Invalid comments, outdated comments are not good comments, and misleading comments are rogue comments

It is generally believed that the poor code quality is the culprit of frequent product bugs. Any code, regardless of the quality, hides bugs and low-quality code, which is especially serious.

Once a bug occurs, the general response of the coders is: this is not the code I wrote, it is the old Code, and there is always a problem. Even if the bug is newly introduced, you can easily find out the reason: "the old code is too bad, and any change will make a mistake ". In the eyes of coders, the code in the code library is so bad that all problems can be blamed for the old code.

Agile legends

Demand is constantly changing, and coders are exhausted. There is a legend that agile can solve this problem. It is worth mentioning that at present, our agile business has achieved gratifying results. Agile means no longer afraid of bugs, because there are complete tests to eliminate bugs in the bud. agile means no longer afraid of changes in demand, because we embrace changes; agile means, developers are no longer afraid of changes, because agility requires everyone to be all talented and master them. agile, we are no longer afraid of bad code, because we have mastered the magic of refactoring code.

Agility encourages code refactoring and improves code quality. Agile advocacy, code should embrace changes, in order to adapt to new needs and changes, should constantly refactor the code. Agility: good code quality brings good product quality. This encourages coders to perform Code tests and refactoring. The Code tests give coders confidence that they do not have to worry or hesitate to refactor.

Since agility is mentioned, let's talk a little more. There is no doubt that agile practice is the best practice for software development, but you must be extremely careful when introducing agile into the management process. Agility is not a silver bullet. Only by recognizing its nature can agility be used to improve development efficiency and product quality. Instead of being used for agility, the team becomes "inagile ".

2. Subjective reasons

Code rewriting is the inner desire of the codoon, and a positive embodiment of the Coon's pursuit of beautiful code. What are the possible motivations for code rewriting?

• Code cleanliness, code cleanliness is very important, but not enough
• Elegant obsessive-compulsive disorder, elegant design, abstract, to adapt to future changes, but where is the future?
• It is easy to rewrite the code and replace the existing code.
• I hope that after some effort, the subsequent maintenance work will be easier.
• With a sense of responsibility for post-code farmers, I hope to leave an excellent code heritage and a legend.

Every Rural Code has its own aesthetic of code, which is a matter of beauty and human existence. Rural Code developers hope to write elegant code and maintain elegant code, which is understandable and should be encouraged.

3. Resistance to code rewriting

However, code rewriting rarely occurs in systems that are at least used for a relatively long time.

(1) three ultimate problems for external leaders

The similarities between leaders and coders are that they all focus on the quality of code. The difference is that the leaders focus on KPI indicators such as the number and severity of bugs. coders care about the quality and elegance of code. Coon believes that the more elegant the code, the higher the quality of the product. Every time the Coon lobby the leaders, there are both how the code is rotten and how to improve the quality of the code and product after rewriting. Leaders are always calm and then throw three ultimate questions:

1. Will it introduce new problems?
2. Which functions are affected? How big is the impact?
3. What are the risks in the project?

Rewrite will certainly introduce new problems, of course, will have an impact on the existing functions, the impact is great, code farmers have been pondering for a long time, still not sure, had to go down.

This is why most coders often mention it and are also the most indignant. It seems that without this resistance, it will be a vast sky where you can display your talents as much as you like.

Xuanjicang

In those years, coders and bugs of their predecessors fought for the Bright Summit. In order to correct the bugs, they made all efforts to solve them. Modifying bugs in bad code and modifying them in a worse way is a fast and clever way that is favored by leaders. This is because the method is poor, but it solves the current problem very well. Facts have proved that the method of getting rid of the defects solves the bug, but does not introduce new problems, does not affect the existing functions, and minimizes the risks of the project, successfully answered the three ultimate questions of the leadership.

Every code farmer who has changed countless Bugs has a humble heart and has a deep power and name, without any trace. As a result, the Code farmer sees a piece of surprising code, but does not know how to hide it, the system bug is blocked. Code has also become a treasure, rich in valuable wealth accumulated by code farmers, but hidden too deep, countless gold miners failed to return. These hidden knowledge treasures gradually become history. Slowly, history becomes legends, and legends become myths.

We were always in awe when looking at and modifying the Code, after we were overwhelmed by our leaders. I often use an immersive sense of substitution to feel the confusions and contradictions in the inner hearts of the coders of my predecessors, and to understand the complexity of their experiences. I had to endure the headache of writing such confusing code. Therefore, we are always cautious and do not dare to change it at will. We always think about it and guard against waking up the sleeping bug boss.

(2) Internal Cause 1984

Engineering risks, requirements of leaders, worries about bugs, code farmers being heavily surrounded, every step of the work is cautious and cautious. Note! Eldest brother has been staring at you!

Bad Code not only leads to poor product quality, but also brings about high code change costs. modifying a code sentence often means engineering risks, leading scolding, and fear. What's more serious is that bad code will gradually influence the developer's initial pursuit of "Beauty. To get familiar with the business, you have to follow the existing code ideas; to add new features, you have to pile up more bad code; To solve bugs, you have to immerse yourself in bad code and cannot extricate yourself. Imperceptible is the most powerful and thorough way to change. Without knowing it, the developer finds the lowest-cost way to work: solve the problem by thinking about bad code and pile up more bad code.

The coders who have lost their "Initial heart" are struggling to sink and sink to the "comfort zone ". Mainong has completely forgotten his old "Initial heart", lost his struggle, and smiled happily after having finally solved a fault all night long. Finally, he was enjoying the absence of complaints.

Code jianghu

The code is Jianghu. Mainong is a swordsman walking in the rivers and lakes. The Swordsmen have the honor of the world and are eager to accept their enemies. However, the rivers and lakes are sinister and the crisis is hidden. The novice swordsman who entered the Jianghu community is not proficient in learning, but has a higher heart than heaven. The old Swordsmen who have been on the waves for many years often know the depth of water and are afraid of risks, because they have gradually understood the rivers and lakes.

It is easy for a novice swordsman to make his path rough. However, it is not easy to wait for the time. It is easier to read and understand Jianghu. This is a typical example of the ease of knowledge and behavior. We also like this story. How can I fix it? When a newbie sees a bug, he wants to give up the sword of rewriting, but he does not want to understand the existing code.

However, is code rewriting easier than reading code? Whether the novice Swordsman is skilled and has profound internal skills. Only by recognizing the swordsman can the swordsman be used. Whether the novice coders consolidate their skills, have a deep understanding of the problems to be solved, and cannot control the existing code, so it is impossible to re-write the ideal code.

Old bird Luo Jianghu asked at the beginning of his Rom Conference: "Are you ready ?", We always have to ask ourselves: Are you sure you are ready to thoroughly innovate the entire system or module?

4. Summary

In the face of resistance, our attention is often focused on external factors. coders often complain that, if the leaders agree, the Code has already been rewritten without causing such a mess. But often ignore their own reasons, code farmers tend to prefer hiding in the "comfort zone" to cry, not willing to toss after the satisfaction of the smile.

The impulse to rewrite code should be cherished. Without the courage and actions to overturn the old ones, there will be no great progress. However, can we boldly rewrite the code? Have you really mastered the system/module? How to obtain hidden knowledge? Is agility a panacea? To what extent can the test provide?

With these problems, we still need to think further.