What do you do when your old code sucks?

You think old code sucks, so what? They’re online, they’ve been tested in the field.

Rewriting code took 12 months!

The time we wasted rewriting code from scratch. Can you imagine being in the software industry for 12 months without any new product launch, without any new version updates?

Really, I couldn’t help but ask myself the question:

How much can we do in December in this fast-moving world?

“Tuesday, January 20, 2015 at 5:10 PM, AntiMalware software has finally entered its first public beta.”

After dozens of hours of nonstop sleep, the first version of the software specification was finally posted on the website, marking the beginning of our new journey.

I work for a small cybersecurity company that provides security software to businesses and end users. The software we develop protects users from malicious software. If a user’s computer is infected with malware, our software helps them clean it up. AntiMalware is one such software.

Feedback on the first beta was encouraging. We had four developers working on the product, constantly fixing bugs, improving features, and releasing new versions.

Why did you find the old code so confusing? Because it’s harder to read code

This is probably why the code Reuse is so hard to implement, and why everyone in your group likes to use different methods to convert a split string into an array. It’s much easier and more fun to write your own feature than to guess how the old one worked.

As a corollary to this axiom, ask the programmers around you what about the code they’re working on? “It’s a mess! They will certainly say so. “I want to start over!”

Why do you think the code is so bad? “Well, look at this feature, it’s two pages long! I have no idea why these things are here! I have no idea what these apis do.” “They’ll say.

How to avoid code refactoring?

Refactoring is inevitable, and programmers will always have to choose between good architecture and changing requirements to digest dirty code through constant refactoring. What you want to avoid is the process of completely refactoring after the code is completely out of control.

Simple, don’t save money, don’t look for outsourcing, find some awesome programmers, better recruit a team.

It’s not like you want good code, it’s just a result, and you don’t care if the code is good or bad, so it’s normal for irresponsible and incompetent programmers to mess things up, and you can’t take advantage of it.

I’ve seen good code remade into garbage, and I’ve seen garbage code that can’t be maintained and can only be refactored, depending on whether the people on the payroll have good taste.

But bosses probably don’t have to worry about paying to poach people from higher-end companies and having them checked by the right people.

How to understand code

So when you find your ex’s code messy, calm down and understand it and improve it in three ways:

1. The structure of the code is wrong

If a piece of network code suddenly pops up its own dialog box, it should be the UI code that needs to be addressed. These problems can be solved by carefully moving code around, refactoring, and changing interfaces over and over again.

It also requires a careful engineer to examine the changes carefully and immediately, so as not to disturb others. In fact, even large structural changes can be made without throwing away code.

Big time programmer Joel Spolsky recalls a project where he and his team spent months rearchitecting a single point:

Tinkering with code, cleaning it up, creating base classes that make sense, and creating perfect interfaces between modules. But they were careful not to create new bugs or throw away any old code.

2. The code is not efficient

At one time, Netscape’s rendering code was passed very slowly. But in reality, this only affects a small part of the project that you can optimize or even rewrite. You don’t have to rewrite the entire code at all.

Optimizing 1% of your work faster will give you an explosive 99% improvement.

3. Ugly code

Some code is really ugly, like the one Joel worked on that started the member variable convention with underscores, but then switched to the more standard “M_”.

So half the functions start with “_” and half with “M”, which looks really ugly. But this problem can be solved in five minutes instead of writing the entire code from scratch.

Finally, remember that just because you’re writing from scratch again doesn’t mean you’ll write better code than before. Since you weren’t involved in the last release, you’re not really experienced at all.

Once you’re ready to rewrite, you’re likely to repeat the mistakes you made in the first version, and even create new problems.