Reply content:
It's time to sacrifice these two pictures! Perhaps you have a strong programming ability, can control 1000 lines, 5000 lines or even 10000 lines of code rewrite, short time can be completed, and the bug is not many, but 100,000 lines, 1 million lines, or even tens of millions of lines? There is always a limit to the ability of a person.
What about the strength of the team? 2-3 of people may find it, but where do you go to get 50-100 who are willing to rewrite the code and still be able to guarantee quality?
More difficult is, where to find the manager or the boss is willing to wait for six months or even a year do not respond to demand, do not change the bug, but to rewrite the code, to use a new set of code to complete the same functionality as the old code, and possibly even more bugs.
Put aside the programmer's perfectionist feelings, rationally look at the analysis of old code, ask yourself a few questions:
Is the cost of continuing maintenance really a specific proportion of the new development still high?
Is the new team a step ahead of the original team in the design and development capabilities?
Are there some hard requirements that can't be done in the old code anyway?
Is there no competitor in the chase and can't stop the update maintenance?
Does rewriting provide some killer features to suppress competitors?
Make a SWOT analysis of the old code and the new architecture, and see what the strengths, weaknesses, opportunities, and threats are.
The old code may not be as good as the architecture, interface design, variable naming and indentation styles, but it is working, and working code means solving a lot of problems that are not automatically resolved in the newly rewritten code because the code is beautifully written, but still stepping on the pits of the predecessors.
So isn't it possible to rewrite the code? No, we have to wait for the chance to see fate.
Personally, if the answer to the five questions I asked above is "yes", at least three of the results of the SWOT analysis are good for rewriting, then it may be that fate has come. Read first, a hard-to-read code may be a programming level problem, it may be to avoid a pit of the compromise, to be patient, do not understand to move.
See, then according to the existing needs to make a decision, design problems, can not meet the needs, then rewrite, do not compromise. Demand can meet, no serious bug, is code chaos, then do not move it, rather in the outside add a wrapper, wrap it up. From graduation to now 5 years, contact with the company's various previous n-Lot code (no document), to learn a reading code, first of all, do not think how to rewrite the code that people wrote before,
some don't seem to be particularly aesthetically pleasing, and are often the result of a variety of business compromises.
Please weigh your time and your abilities before refactoring, and maybe the next programmer will think about how to refactor your code.
I didn't think of an article like me. Boycott code rewriting
》
Yesterday, an old superior invited me to have lunch together. As we sat waiting to serve, we remembered the early events of the company. He had a word that made my heart empty:
Ah, you judge ... I remember what it looked like when you saw the code written by Dan (the company's first programmer). You said: "This code is really bad write, need to rewrite!" ”
I'm afraid I'm not brave enough to tell him that my "code needs rewriting" proposition is wrong. Yes, I think it's a messy code. However, according to previous experience, I feel that most programmers will think when they look at a program written by others: This code is really bad. In fact, when a programmer looks at a program he wrote a few years later, he also thinks: This code is really bad. Maybe they are right; The code is really rotten.
However, if you think the code needs rewriting, you will make a low-level error.
There are some assumptions in the company that you may not be able to recognize now. A large amount of unwritten assumptions may make it impossible for you to explain clearly.
I love what Joel Spolsky says about this kind of thing, something you never do :
We are programmers. Programmers, in their own minds, are architects, and when they come to a location, the first thing they want to do is: push this place flat and build a splendid building. They are not interested in the slow repair: small repair, improve, cultivate flowers.
There is an elusive reason why programmers always want to lose the code and write again. The reason is that they think the old code is confusing. However, you will observe a very interesting phenomenon: their judgments are usually wrong. The reason they think the old code sucks is from an important, basic programming law:
It is harder to read code than to write code.
That's why the code is hard to reuse. That's why each team likes to use its own different functions to split the string into array operations. They want to write their own methods, which is easier and more interesting, and does not need to figure out how the old functions work.
According to this law it is inevitable to draw such a conclusion that you can now ask any programmer how they feel about the program being written. "No more chaos," they will tell you. "I'd rather have them erased and re-written." ”
When you recruit a programmer, if he wants to rewrite the good program that seems to work, you have to resist. He might say Java is out of date, too slow, and how cool Ruby on Rails is. Maybe he'll throw you a bunch of professional nomenclature. No matter what he does, you must think twice.
What do you think?
- Why don't you rewrite the code?
- Resist code rewriting
Last week changed a small code of about 500 lines, C language, all stuffed in a file, a bunch of global variables, the code repeats a lot of (before that person will not use sprintf, a copy of their own implementation of Atoi copied three), function of each other, variable name of a variety of letters
Then I split into 7 different functions of the source code, some function directly rewrite, change the volume name, according to the scope of the global variable range, and finally changed to the static file scope, plus access interface, and by the way, by the stupid x compiler pit for one hours
And then I find myself writing a rewrite or resigning myself. Slowly change, a piece of slowly rewrite, eventually the whole rewrite out. Overrides are usually rewritten immediately, and then a bunch of bugs, solved by the discovery is a piece of code to rewrite, and then suddenly understand why it started so bad is generally rewritten. Look at the input and output, probably understand what it is, people wrote 100 lines, feel that their 90 line to fix it, think 30 lines can be done, decisive comment out rewrite
