0 reply content: It's time to sacrifice these two pictures! You may have a strong programming capability to write 1000 lines, 5000 lines, or even 10000 lines of code, which can be completed in a short time, and there are not many bugs, but 0.1 million lines, what about 1 million rows or even tens of millions of rows? Personal abilities always have limits.
What about the strength of the team? 2-3 people may be easy to find, but where can I find 50-people who are willing to rewrite the Code and ensure the quality?
What's more, where can I find a manager or a boss who is willing to wait for you for half a year or even a year to not respond to the demand, but to rewrite the code without changing the bug, use a new set of code to implement the same functions as the old code, and even more bugs.
Let alone the perfectionist feelings of programmers, look at and analyze the old code rationally, and ask yourself a few questions:
Is it true that the cost of continuous maintenance is higher than that of new development?
Is it because the new team has a higher level of design and development capability than the original team?
Is there some hard requirements that cannot be achieved in the old Code in any way?
Is it because no competitor is persistently pursuing updates and maintenance?
Is rewriting able to provide some killer functions to suppress competitors?
Perform SWOT analysis on the old Code and new architecture to see what the advantages, disadvantages, opportunities, and threats are.
The old code may be unsatisfactory in terms of architecture, interface design, variable naming, and indentation style, but it can work. The code that can work means a lot of problems are solved, these problems won't be automatically solved in the newly re-written code because the code is beautifully written. We still need to step on the pitfalls of our predecessors.
So can't I rewrite the code? No. You have to wait for a chance to see what happens.
I personally think that if the answer to at least three of the five questions I asked above is "yes", at least three of the results of the SWOT analysis are conducive to rewriting, then it can be said that fate may come. First understand, a piece of ugly code may be a programming level problem, or it may be to avoid the compromise made by a certain pitfall. Be patient and don't move if you don't understand it.
Once you understand it, you can make decisions based on your current needs. If there are design problems that cannot meet your needs, rewrite them and avoid compromise. If the requirements can be met, there is no serious bug, that is, the code is messy, so don't touch it easily. Instead, add a wrapper outside and pack it. Five years from graduation to the present, I have been engaged in various previous N-hand codes of the company (without any documents), and I have learned how to read the code, first, you should not think about how to rewrite the code that was previously written,
Some code that does not look very beautiful is usually the result of various business compromises.
Before refactoring, please take a look at your time and capabilities. Maybe the next programmer will think about how to refactor your code.
I did not expect an article to share the same idea as I would like to resist code rewriting.
"
Yesterday, an old superior invited me to have lunch. When we sat down and waited for food, we remembered the past of this company. His words make me feel guilty:
Ah, you judge... I remember what it looked like when you saw the code written by Dan (the first programmer in the company. You said, "This code is really bad and needs to be rewritten !"
I'm afraid I don't have enough courage to tell him that my claim that "code needs to be rewritten" is wrong. Yes, I think this code is messy. However, based on past experiences, I feel that most programmers may think about this code when looking at programs written by others. In fact, when a programmer looks at the program he has written several years later, he will also think: This code is really bad. Maybe they're right; the Code is really bad.
However, if you think the code needs to be rewritten, you will make a low-level error.
The company has some opinions that you may not recognize now. A large number of unwritten ideas may make it hard for you to explain clearly.
I like what Joel Spolsky says about such things. You never do things.:
We are programmers. Programmers are architects in their own minds. When they come to a place, the first thing they want to do is to flatten the place and build a brilliant building. They are not interested in slow repairs: minor repairs, minor repairs, improvement, and cultivation of flowers and plants.
There is an unpredictable reason for programmers to always wish to lose the code and re-write it. The reason is that they think the old code is messy. However, you will observe a very interesting phenomenon: their judgment is usually wrong. They think that the reason for the bad old code comes from an important and basic programming Law:
Reading code is more difficult than writing code.
This is why the code is difficult to reuse. This is why each team prefers to use their own functions to split strings into arrays. They need to write their own methods, which is easier and more interesting. They do not need to figure out how old functions work.
According to this law, you can now ask any programmer how they feel about the program being written. "No more chaos," they will tell you. "I would rather delete them and write them again ."
When you recruit a programmer and want to rewrite a program that seems to work well, you have to resist it. He may say that Java is outdated, too slow, and Ruby on Rails is cool. Maybe he will throw you a lot of technical terms. No matter how he does it, you have to think twice.
What do you think?
- Why never rewrite the code?
- Resist code rewriting
Last week, I changed a small code of around 500 lines, C language, all in a file, a bunch of global variables, and a lot of code repetition (that person would not use sprintf before, A copy of the self-implemented atoi copies three copies), the functions are intertwined, variable names with a variety of letters
Then I split the source code into seven different functions. Some functions are directly rewritten, the volume name is changed, the scope is adjusted according to the scope of the global variables, and finally changed to the static file scope, added the access interface, which was also pitted by the silly x compiler for more than an hour.
Then I found that it was better to rewrite or resign myself .. It was changed slowly, and the whole piece was rewritten. Rewrite is usually to immediately rewrite, and then a bunch of bugs, solve the found is a bunch of bad code that needs to be rewritten, and then suddenly understand why it is so bad at the beginning, generally it is To rewrite. After reading the input and output, I will probably understand what it is. People write 100 rows and feel that they will not be able to handle 90 rows. I think 30 rows can be done, and I will comment out and rewrite them.
