What you should never do-about code rewriting

What you should never do, part 1

By Joel Spolsky

Thursday, limit l 06,200 0

Original link http://www.joelonsoftware.com/articles/fog0000000069.html

Netscape6.0 is about to begin its first public beta. Version 5.0 has never been released. The last major release was version 4.0, almost three years ago. 3 years has been very long in the online world. During this period, Netscape stopped and was desperate because their market share plummeted.

I commented that it was a bit hypothetical to wait for such a long time between the two releases. They did this on purpose, right?

No, no. This is the most serious and strategic mistake that any software company can make:

They decided to rewrite the code.

Netscape is not the first company to make this mistake. Borland made the same mistake when acquiring Arago and integrating it into DBASE. This project took so long to make Microsoft Access eat their lunch, then they made this mistake again to rewrite Quattro Pro, which has fewer features than surprising. Microsoft almost made the same mistake. In a project called pyramid, the project was shut down, abandoned, and hidden. Fortunately, Microsoft has not stopped working on the basis of the old Code, so they can achieve results. This is only a financial disaster, not a strategic one.

We are programmers. In the minds of programmers, they are architects. What we want to do most when we arrive at a place is to flatten the road and build magnificent buildings. We are not keen on renovations: repairs, improvements, and flower beds.

There is a subtle reason that programmers always want to abandon the original code and start over again. The reason is that they think the original code is too messy. And there is an interesting phenomenon: they may be wrong. They think that the reason for the chaos of the old Code is a basic programming Law:

Reading code is more difficult than writing code.

This is why code reuse is difficult. This is why everyone in your team prefers to use different strings to split them into character arrays. They all write their own functions because they are simpler and more interesting than figuring out the old code.

As an inference of this principle, you can ask any programmer about his work today. "This is a mess." They will tell you this. "Nothing is better than throwing away these re-writes. "

Why is the code messy?

They said, "Look at this function. This is two pages long! These things should not appear here! I don't know why half of the APIs are called"

Before the release of Borland's new windows workbook, phlippe Kahn, the legendary founder, said he was boasting that Quattro Pro is much better than Microsoft Excel, because it overwrites all source code! It seems that the source code will also rust.

The idea that new code is better than old code is absurd. The old code is already in use. It has been tested. A large number of bugs have been found and fixed. This is nothing bad. Putting programs on the hard disk won't make you discover bugs. Is the software, like the old dogde dart car, waiting in the garage? Isn't software as hairy as a teddy bear if it doesn't use new materials?

Let's return to the two-page function. Yes, I know. This is just a simple function for displaying the window. It just grows something else and people know why. Okay, I'll tell you why: This is to fix bugs. One of them was modified by Nancy, which fixed the bug that appeared when it was installed on a computer without a browser. The other is to fix bugs that are generated in low memory. Another is to fix the bug that occurs when a file is on a floppy disk. This ugly loadlibrary is used to make code run in earlier Windows 95.

These bugs can only be detected after several weeks. Programmers may have spent several days in the lab to reproduce and fix bugs. Like many bugs, fixing a bug requires only one line of code or even a few characters, but a lot of work and time is required to fix the two characters.

When you abandon these code rewriting, you also discard all the knowledge, all the bugs that have been fixed, and years of programming results.

You have also abandoned your market leadership. You have given your competitors two or three years. Believe me, this time is too long for the software.

When you release only one old version of code product in a few years, you are in a very dangerous situation if you cannot make changes at all and cannot adapt to market demands to add new features, because you do not have any code that can be released. You may close your business during this period.

However, writing the existing code again is meaningless and wastes a lot of money.

Are there other options? We all agree that the old version of Netscape code is very bad. It may be terrible, but, do you know? It runs very well in real-world computer systems.

When programmers say their code is messy (they often do), it is because there are three errors in the code.

First, structure issues. The code is not arranged in the correct place. One of the core code is to pop up its own dialog box anywhere in the middle; it should be arranged in the UI code. This can be solved by moving code, refactoring, and changing the interface at a time. It allows a programmer to modify and detect the changes once, and no one will be disturbed by this problem. Even a major structural adjustment can be completed without abandoning the original code. In a Juno project, we spent a few months making only one structure adjustment: Moving code, clearing code, creating base classes, and creating clear interfaces between modules. We made a very serious effort on the basis of the original code, and we did not generate new bugs, nor did we discard the original code.

The second programmer thinks that the cause of their code chaos is the low code efficiency. Netscape rendering code is said to be inefficient. But this is only a small part of the entire project. You can optimize or even rewrite this part. You do not need to rewrite all the code. When the optimization efficiency is achieved, 1% of the work can be rewarded with 99%.

Third, the Code may be very ugly. A project I have worked on has a data type named fuckedstring. The member variable names in another project start with an underscore and start with M. Therefore, half of the functions start with "_" and start with "M _" and look very ugly. To be honest, you can use the Macros in Emacs to solve this problem within 5 minutes without rewriting the code.

It is important to remember that when you rewrite the Code, there is no absolute reason to believe that you will be better than the old code. First, you don't even have the same development team as writing the first version, so you are not "more experienced ". I will make the most of the mistakes I have made before, and there will be more new problems than the original version.

When implementing a large commercial application, it is very dangerous to generate one as before. If you have experience writing code, you may cancel the function you wrote last week after coming up with a better algorithm. This line. I may want to refactor a class which is easier to use. This is fine. However, it is dangerous and stupid to discard all programs. If Netscape has some mature managers with software industry experience, they may not hurt their feet so seriously.