Why some programmers have messy code structure

Programmers have the heart of an engineer, so the first thing they want to do when they go to a new venue is to tear down the old one and start over. Yes, they will never settle for simple incremental labor.

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

But is it really so? The reason you think old code is a mess is actually determined by a fundamental law of programming: it's easier to write code than to read it.

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

This is probably the reason why code Reuse is difficult to achieve. That's what everyone in your group likes to do with a different function to convert the split string into an array. It's much easier and more fun to re-write your own functionality than to guess how the old functionality was implemented.

As a corollary to this axiom, you can ask the programmers around you how the code they are struggling with is? "It's a complete mess!" they would surely say. "I just want to do it all over again!"

Why do you think the code is so bad? "Um, look at this feature, it's two pages long! No idea why this stuff is here! No idea what these APIs are for," they'll answer you.

Comic: What's it like to read someone else's code?

At one time, Borland founder Philippe Kahn boasted to reporters that Quattro Pro would be much easier to use than Microsoft Excel because it was written from scratch, all with new source code!

However, to think that the new code is better than the old code is simply ridiculous. The old code was already run and tested. Countless bugs went live before they were discovered, and it may have taken programmers days to fix them after they were discovered. The fix could be a line of code or a few characters, and countless hours and effort were spent on these bug fixes.

When you decide to ditch the old code and start from scratch, you're also throwing away all the results of your predecessor's efforts.

The new code must be better than the old one? NO, the rewrite may be more risky.

Rewriting a project's code is also an extraordinarily difficult decision for a technology leader. Because at the company level, reproducing the code can even threaten the market competitiveness of the product. Once you decide to rewrite the code, you may be 2-3 years behind the competition - a long time in the software industry.

Your ideal new code will improve product functionality ▼

But in fact, even if the rewritten new code can achieve all the functions and requirements of the old code, the market competitiveness of the product will only be marginally improved. Because the new technology, new language, and new framework used for rewriting did not bring a qualitative leap to the product.

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

1. Lack of money: the break of the capital chain ▼

2. Lack of personnel: the resignation of core programmers

will eventually lead to poor results: the original product cannot be achieved All the functions and requirements it should have, wasted time and money, and lost market competitiveness. ▼

So rewriting code means that you are putting yourself in a very dangerous situation where you may not be able to write better code than before in a few years. You just spend a fortune rewriting the code that already exists.

What do you do when you think the old code in front of you sucks?

You think old code is badly written, so what? They are live and have been tested in practice. So when you find that the code left by your ex is messy, you might as well calm down and start understanding and improving the code from the following three aspects:

1. There is a problem with the structure of the code.

If a piece of network code suddenly pops up its own dialog box, it should be UI code needs to be processed. These problems can be solved by carefully moving the code, refactoring, and changing the interface time and time again. It also requires an attentive engineer to immediately double-check these changes for problems, so as not to disturb others. In fact, even relatively large structural changes can be done without throwing away code.

Daniel programmer Joel Spolsky recalls that once in a project, he and his team spent months re-architecting one point: moving the code around, cleaning up, creating meaningful base classes, and creating A perfect interface between modules. But they were always careful not to create new bugs or throw away any old code.

2. The efficiency of the code is not high

. Once, Netscape's rendering code was very slow. But in reality, this will only affect a small part of the project that you can optimize or even rewrite. You don't have to rewrite the entire code at all. 1% of the effort to optimize speed will get you an explosive 99% increase.

3. The code is ugly.

Some code is really ugly. For example, Joel once participated in a project and started to use the underscore as the starting member variable convention, but later changed to the more standard "M_". So half the functions start with "_" and half start with "M", which looks really ugly. But this problem can be solved in 5 minutes without writing the entire code from scratch.

Finally, you have to remember that writing it all over again from scratch doesn't mean you'll write better code than you did before. Because you didn't participate in the creation of the last version, you're not really experienced at all. Once you're ready to roll back the rewrite, you're likely to repeat the mistakes of the first version, and even create more new problems.

A summary: In

the face of bad old code, Keep Calm & Carry On!

In large commercial projects, it is very dangerous to tear down and start over. Of course, if you're experimenting, you can always rewrite new algorithms when you think of them.