Who wrote such bad code?

Every programmer sends this soul-searching question.

Bad code can be heir-heir-heir-heir-heir-heir-heir-code, code written by a previous generation of programmers, code written by a former coworker, code written by a colleague, code written by you!

Some code passed for four or five years, some passed for more than a decade, and some passed for more than 20 years!

As a Java student, can you imagine a system that only uses JSP to do?

I’ve had a 6000-plus line JSP act as Controller, and a programmer who added more code to the JSP at one time simply failed to compile.

Isn’t the famous Oracle strong?

In 2018, an Oracle programmer joked that every time he worked on a Bug, it would take him two weeks to figure out 20 different flags and their mysterious roles before he could add some new flags and logic to fix the Bug.

The code then needs to be submitted to a test cluster of 200 servers, waiting 20 to 30 hours to run millions of tests. There may be 100 to 1000 tests that fail, and you need to analyze them and more flags.

This repeats for two weeks until you make sure that the mysterious combination of flags passes all the tests.

Then add hundreds of tests to your changes so that no one else breaks them.

Isn’t that crazy?

You can also look at the code you have and see who the original authors are and how many versions they have gone through.

The first version I saw was 1998, and the author is now a senior architect.

If you’re lucky enough to start a brand new project right from the start, there are no heirloom code issues.

Rest assured, however, that according to the Law of Code Corruption and the Broken Window effect, your project will quickly become “code heirloom”, no exception!

Resist the urge to rewrite code

I more than once hit the keyboard side scold: so bad code, maintenance costs so high, rewrite it!

But my sanity tells me that rewriting costs a lot more, that the heir-apparent code is bad, but it’s been tested and tested by real users, and that the seemingly irrational branches and conditions are just compensating for the logic that the programmers didn’t think about.

If you do rewrite, can you make sure that all the logic is correct? Is there any guarantee against major mistakes? Is it guaranteed not to cause significant financial loss to the company?

Software quality includes two aspects: internal and external.

Intrinsic is the quality of the code, external is whether the behavior of the external performance is expected, not consistent is a Bug.

The external quality of ancestral code is good, after all, it has been tested by fire and blood.

If you rewrite, can you guarantee that both the quality of the code and the behavior of the code are better than those of the ancestral code?

Rewriting to ensure that the business can not be interrupted is a basic condition. When I was working as an agile consultant in Huawei in 2010, I remember a slogan of Huawei very clearly: to change the wheels of a car on the highway, is it possible? It is said that Huawei has a team really made it, if it is true, really let a person admire.

Second, look for the shadow of a good architecture

The ancestral code is messy, but the initial architecture is generally excellent.

I saw a product like this in Huawei. The code piled up in the application layer looks very bad, but if you look carefully, you can see the shadow of excellent architecture. It must have failed to keep it, and then it slowly deteriorated.

So in the face of the ancestral shitmountain code, to hold your nose, abandon the details, in the search for a good architecture shadow.

Functionally, what are the components of the system and how do the components interact with each other?

Technically, what software are these components deployed to? What protocols do components use to interact with each other, synchronous or asynchronous? How does data flow between components?

How are the internals of some core components stratified?

Anyway, to answer the question: Could I have built this system on my own?

One day, you’re going to be one of those people. Keep your reserves.

Refactor as much as possible within your own scope

In the face of ancestral code, the original intention does not change.

Try to write their own code well, can refactor as much as possible, even if it is a function, a variable name.

These are skills you rely on to survive. You can’t just write worse code because your ancestral code is bad!

Refactoring and testing are the same. Write your own unit tests, do your own functional tests, and ask your testers for help if necessary.

You have to have the guts to do it, especially when it comes to Shit Mountain Code.

To live up to their own, can not pit their own.

Four, expand the field of vision, look at the excellent source code

Ancestors code has the shadow of a good architecture, but if you look at it too much, you’ll vomit.

There is still good source code in the world, especially open source code. There is no great pressure of progress, and maintainers have plenty of time to polish their code and act like craftsmen.

Some of the best sources I know are: JUnit, Redis, SQLite, Spring, etc.

This code is now very complex, looks tired, it is best to find its early source, it is much simpler, and the basic architecture is still there.

In the early days of JUnit, for example, several hundred lines of code combined many design patterns, which were so clever that the design pattern was less than a living example.

After reading, try to build a wheel, the main ideas to reflect, your skill at least on the next level.

Source: Yard farmer turn over


Author: Code farmer turn shen liu xin


Disclaimer: The article was forwarded on IDCF public account (devopshub) with the authorization of the author. Quality content to share with the technical partners of the Sifou platform, if the original author has other considerations, please contact Xiaobian to delete, thanks.

Every Thursday in July at 8 PM, “Dong Ge has words” R & D efficiency tools special, public account message “R & D efficiency” can be obtained address

  • July 8, Leansoft – Wenyang Zhou “Azure DevOps Toolchain”
  • July 15, Aliyun Intelligent Senior Product Expert – Chen Xun “Practice of Efficiency Improvement in Complex Research and Development Collaboration Mode”
  • On July 22, Yang Yang, solution architect at GitLab, shared “Exploring the Automated Testing of Infrastructure as Code”
  • On July 29, Bytedance Product Manager — Xianbin Hu shared “Automated Testing: How to Be Offensive and Defensive”.
  • Wang Zhi, head of Acoustics AgoracicD System, shared “Creating a Closed Loop of Software Delivery Quality Assurance from 0 to 1” on August 5.