preface

You hired a new units, were told to maintain an old product, give you open the SVN access, looking for quality control manager tells you which branch out – is that branch of ten years ago has finalize the design is that more than 6 generations programmers maintenance branch – and then tell you, on this branch change, add a new interface, To support H5 Video.

So you start looking at the code, in a fog of pain, and you don’t understand the relationship between the business logic and the code, and you don’t understand why this piece of code is written this way and what that piece of code means. You’re walking on eggshells and you can’t make a move.

You ask the old colleague who has not become a regular employee for more than 5 months, he tells you that he does not understand, let you make do with adding a new interface to achieve the function. Just add new features.

You ask for almost a year older colleagues, he told you don’t move inside the code, never mind what inside, just outside the bread a layer, the first delivery of new features, other have time to say again, the logic inside nobody moved in 10 years, a person can’t explain what happened, if you change, one not careful it shows that the whole land.

What do you do?

How do you stop a monkey from eating a banana

Monkeys eat bananas:

Don ‘ts about old code

Maintaining old code is one of the worst things a programmer can do. What’s more, it’s gross, admittedly gross, and even an old programmer like me, who considers himself casual, flexible, adaptable, and unprincipled, feels that maintaining old code is a sin. If you hate a programmer, let him maintain old and crumbling code.

However, the situation mentioned at the beginning of this article is one that almost every programmer has encountered. Old code, we hate hate hate far away but can not be abandoned. For a software enterprise, old code is an asset, the core asset and important competitiveness accumulated over many years. Especially with software products, it is common for a piece of code to be maintained by several generations.

At that point, the old code comes to life, and every time a new person comes in, it makes a characteristic high-pitched sound that goes beyond our earshot: Warning, warning, a new wave of programmers are on their way, give them a kick in the ass and demoralize them.

Moreover, some old programmers familiar with the old code will earnestly warn us, these files do not move, these classes do not move, here a change to collapse, where a change can not connect to the server, minefield identification is a lot of. And the programmer who came in because he was warned and never looked at the old code will also tell us that the code nobody understands, no one has touched in how many years, better not to move, avoid trouble…

So the story happened, and the taboo was passed on. We knew there might be a problem, but no one dared to touch it, and when the last programmer who knew part of the old code was gone, the place sighed, and the new programmer became a banana-hungry monkey.

To move or not to move?

Old code becomes taboo, and we are often forced (without the time or inclination or fear or disdain) to tinker at the tip of a floating iceberg, and the deep knowledge of code becomes a pain that no one wants to talk about.

However, they do not understand the code and do not touch the old code, the old code can only be more and more old and stale, more and more no one dare to move. The more you move back the higher the cost and the less you dare to move. It’s bad for the company and bad for the team. Wrapped layer after layer, will eventually become a foot-binding, no one cares.

Once the old code is out of control, the code as an asset is effectively lost and no longer valuable, and the original lead is gradually lost as the peer group catches up.

This is a loss to business. Reading programmers is also a loss.

Why do you say that?

It is better to be an old lover

Programmers have a problem with complaining that other people’s code is not documented when they don’t document themselves, and ignoring documentation when they encounter documented code. Therefore, the industry has a saying: code is documentation. So, industry code and documentation, rarely match.

Whoa, whoa, whoa, whoa.

So let’s just accept the fact that code is documentation.

So, for programmers who maintain older products, there are only two ways to understand the logic of older products:

  • Find someone who knows the product and ask them to tell you about it. If you go to the product manager, he can only tell you how to design the product. If you approach a programmer, he or she will usually say this and that, followed by an enigmatic hate speech: Just look at the code.

  • Bite the code, bite the code, bite the code.

Ok, it’s important to maintain old products and understand product design logic and code implementation logic.

For the problem mentioned at the beginning of this article, there may be a way to wrap in the periphery. For example, you can package a local HTTP Server, use the old API to get data as HTTP flow and send it to support H5 Video tag. There may also be a compromise alternative in many cases.

There are, however, very important benefits to understanding how code implements products and businesses — important benefits for programmers:

Documentation is outdated, code doesn’t lie, and when you read the code, you really understand how the business works. When you figure out the core old code that no one dares to touch, you capture the strategic ground.

Here I want to quote a gree air conditioning slogan: master the core technology. It is true that mastery of the core technology is the only way to be competitive, and the same is true for programmers, who are valuable only if they master the core business and code.

In addition, reading code is also a very important way to learn, especially experienced online code, must be particularly good. In the process of reading, we can learn a lot, both about business and design. At the end of the day, even if you think you’re a lot better than the average person, you can still learn from the choices you made at the time and at the place: you can reflect on what you’ve seen and what you’ve seen.

So, my argument is: old code, move, why not move!

You can accept when you can’t refuse. You don’t need to reject. You can practice whenever and wherever you want. At the worst, HE also exercised his ability to read code and achieved paoding skills. He could also play a useful role in the future.

As for how to read the code to change the code, I believe that it is much easier than learning Song Zhongji to tease younger sister, in a word: read more good.