Why should programmers never rewrite code?

Rewriting code means starting over, and there are more risks!

Programmers who want to tear down old code and rewrite it, please take note: keep calm and move on!

[[228479]]

Programmers have an engineer's heart, so when they arrive at a new site, the first thing they want to do is to tear down everything that's old and start over. Yes, they will never be satisfied with simple incremental work.

Perhaps this subtle psychological positioning can explain why programmers would rather throw away the old code and rewrite it than tinker with it after joining a new project team. They think the old code is a mess.

But is this really the case? The reason why you think old code is a mess is actually determined by a basic law of programming: it is easy to write code, but it is difficult to read code.

Why do you think old code is so confusing? Because it's harder to read.

This is probably why code reuse is so hard to achieve. It's because everyone in your group likes to use a different function to convert the split string into an array. It's much easier and more fun to rewrite your own function than to guess how the old function is implemented.

As a corollary to this axiom, ask the programmers around you about the code they are working on. "It's a mess!" they will definitely say. "I just want to start over!"

Why do they think the code is so bad? "Uh, look at this function, it's two pages long! I have no idea why these things are here! I have no idea what these APIs do." They will answer you like this.

Once upon a time, Philippe Kahn, the founder of Borland, boasted to reporters that Quattro Pro would be much better than Microsoft Excel because it was written from scratch, with all new source code!

However, it is absurd to think that new code is better than old code. Old code has been run and tested. Countless bugs have been put into production before they were discovered, and programmers may have spent many days fixing these bugs after they were discovered. This fix may be a line of code or a few characters, and countless time and energy have been spent on these bug fixes.

When you decide to throw away the old code and start from scratch, you also throw away the results of all the efforts of your predecessors.

Is the new code definitely better than the old one? NO, rewriting may bring greater risks.

For technical leaders, rewriting the code of a project is also an extremely difficult decision. Because from a company perspective, reproducing the code may even threaten the market competitiveness of the product. Once you decide to rewrite the code, you may lag behind your competitors by 2 to 3 years - in the software industry, this time is long enough.

Your ideal new code will bring improved product functionality

But in fact, even if the rewritten new code can realize all the functions and requirements of the old code, it can only bring marginal improvement to the market competitiveness of the product, because the new technology, new language and new framework used in the rewrite have not brought a qualitative leap to the product.

Not to mention that during the long process of rewriting you may encounter some unexpected situations, such as:

1. Lack of money: Broken capital chain
2. Shortage: core programmers leave

The end result is poor results: it fails to meet all the functions and requirements of the original product, which wastes time and money and also loses market competitiveness.

So rewriting the code means that you are putting yourself in a very dangerous situation, and you may not be able to write better code than before in a few years. You just spent a lot of money to rewrite the existing code.

What should you do when you think the old code in front of you is terrible?

You think the old code is poorly written, so what? They have been put online and have stood the test of actual operation. So when you find that the code left by your predecessor is a mess, you might as well calm down and start to understand and improve the code from the following three aspects:

01 There is a problem with the organization of the code

If a piece of network code suddenly pops up its own dialog, it's the UI code that needs to be dealt with. These problems can be solved by carefully moving code around, refactoring, and changing interfaces over and over again. It also takes a careful engineer to check these changes carefully and immediately to see if there are any problems, so as not to disturb others. In fact, even relatively large structural changes can be done without throwing away code.

A great programmer recalled that in a certain project, he and his team spent several months re-architecting on one point: moving the code around, cleaning it up, creating meaningful base classes, and creating the best interfaces between modules. But they were always very careful and did not create new bugs or throw away any old code.

02The code is not efficient

Netscape's rendering code was once rumored to be very slow. But in fact, this only affects a small part of the project, which is the part you can optimize or even rewrite. You don't have to rewrite the entire code. Optimizing 1% of the speed will give you an explosive 99% improvement.

03 The code is ugly

Some code is really ugly. For example, Joel once participated in a project that started with an underscore as the member variable convention, but later changed to the more standard "M_". So half of the functions started with "_" and half started with "M", which looked really ugly. But this problem can be solved in 5 minutes without having to write all the code from scratch.

Finally, you have to remember that starting over again does not mean you will write better code than before. Because you did not participate in the creation of the previous version, you are actually not experienced at all. Once you are ready to rewrite it, you may make the same mistakes as in version 1 again, and even create more new problems.

100offer said: Facing bad old code, Keep Calm & Carry On!

In large commercial projects, starting over is a very dangerous behavior. Of course, if you are doing experiments, you can always rewrite it if you think of a new algorithm.

If you change jobs or just take over a new project, and are faced with old code that looks extremely messy, please calm down, resist the urge to tear it down and rewrite it, and think about the above experiences.