Refactoring some ideas on how to treat the old programs inside the company

is maintaining this C mixed C + + code, last week to reconstruct some of the data, mainly to the C code to C + + migration, so that the code looks comfortable, such as too many function parameters (17 you believe) some two pointers, and even some data with a single pointer for the linked list, I don't know what he wants to do without reading all the code. Orz ....

Originally intended to change, but spent a large half a day, there is no way to completely change the data structure and function, the function of the algorithm are tightly coupled, reaching. Even if there is a test job, this project is not a complete test case to do the regression, only by random testing. This will not be the case of pressing the gourd up scoop, there is no guarantee that no other bug. At the same time, the new energy function had to be done and had to be postponed.

Read the article today and be inspired by the problems you are experiencing:

There's a module in our code that works perfectly for many years, but the code is just too messy. I persuaded my boss that I could rewrite the module, so I spent three weeks rewriting the module. Today, I remember that my boss was standing behind me looking at me, and I was in the middle of a bucket of sweat to fix the "super Beautiful" module I rewrote one after another bug. Since then, I have not rewritten the code anymore unless there is a significant benefit.

Reviews: This is called slaughter-type programming. This case tells us two reasons, 1) the maintenance code should be carried out in the most conservative way. 2) before refactoring the code, learn to calculate benefits like a businessman. Of course, ThoughtWorks's consultants will tell you that TDD, pairing, limits, and so on, can tell you how to refactor if you practice. But I want to tell you, a program in the production environment for several years to run without problems is a very difficult thing, it is afraid of the code again rotten, you can not see the past, you have a clear mind to understand these points,1) The quality of the software is much larger than the code quality, 2) Your test case is much smaller than the production environment, 3) the perfect quality of the software is the long run, the test and the wrong heap, rather than some kind of methodology .

Source: Programmers who are sad.

The measure of income is one aspect that should be considered, for my present situation, the income is really not big, after not absolutely necessary, should not go to change the old data structure.

Refactoring some ideas on how to treat the old programs inside the company