With Programmer day 1024 just around the corner, today we’re going to talk about some light-hearted and humorous topics — those annoying and funny family codes.

It’s a familiar experience for many new students: diligently reviewing code only to find a bunch of old bugs. When you’re confident you’re going to fix it, and as soon as you do, the whole system collapses.

These ancestor-tribute (WA) offerings (Keng), also known as ancestral code, are a nightmare for generations of programmers.

“Nine chapter algorithm class 2020 editionExpand the class five times

Highlights of the course:

  • In the epidemic response version of “Nine Chapters Algorithm Class”, Linghu Chong, the teacher, increased the number of courses by 5 times
  • Explain 57 core interview questions in 8 weeks
  • The course is expanded from 9 to 43 chapters

7 days of video playback, free registration by poking me

What is an ancestral code?

Legacy code, literally, is code that old programmers leave behind. The person who wrote the code may have left long ago, but the code is so illogical and uncommented that posterity can’t see what it was written about!

Or it wasn’t perfect when it was written, and over time, the business needs have changed, and there are problems everywhere.

For example, you might encounter code like this:

//add by xxxx 201x-x-x:
Copy the code

This is a magical piece of code. That’s the right way to write it anyway

Almost every company has “legacy issues” in its code, and the bigger the company, the worse it is.

Amazon engineers describe their code as “a big mountain of shit, the biggest mountain you’ve ever seen, and every time you want to fix a bug, you have to climb right into the middle of it”.

Worst of all, there are some family codes that you can’t go back to once you move.

(Photo from Zhihu user: Same moon)

With this picture can not be more vivid 👇

Can I replace the ancestral code with new code?

Why isn’t the new code as good as the old one? Don’t be so quick to contradict! Just hear me out.

Old code is already run and tested. ** Countless bugs are up and running before they are discovered, and it can take days for programmers to fix them.

This fix can be a line of code or a few characters, and countless hours and hours of effort go into fixing these bugs.

When you decide to throw away the old code and start from scratch, you throw away all the previous work. Rewriting could be even riskier.

Rewriting code is also a very difficult decision for the technical leader. On a corporate level, reproducing code can even threaten the product’s market competitiveness.

Once you decide to rewrite your code, you may be two or three years behind your competitors — a long time in the software industry.

New code doesn’t bring product enhancements

Even though the new code does all the things the old code does, the fact that the new technology, new language, and new framework used in the rewrite does not make a significant leap forward.

Not to mention this time-consuming and exhausting process is also prone to some accidents:

What do you do when you think old code is rotten?

Take a chill pill. After all, this old code is live and has stood the test in production. At this point, there are three ways to understand and improve your code:

The reality is that if you rewrite someone else’s code, chances are you’re going to do it all over again. So, when faced with bad ShitCode, don’t think about rewriting it. If you can still find the person who wrote the code, give it a hard time!