Legacy phobia

Colleagues, I have great news for you, we received a wonderful project, it was written for several years by unknown developers, the address of which we can hardly find out (in order to “share feedback”), we wrote for a long time and we don’t know what it is, and we have to maintain and develop it. The project is now at the peak of its performance and we will soon rest on it; any inaccurate changes can put it on, but we will develop it. Hooray!

Agree, sounds strange? How delirious patient on the head of a programmer. Who likes legacy? It's always a govnod (after all, we write perfectly), it’s full of bugs (and we write without errors), terrible solutions (after all, only we choose the appropriate architecture), and it’s almost always difficult to read (after all, we write clear and beautiful).

I am familiar with this horror story as much as I am familiar with the development area. Scary legacy-code is a universal horror story for programmers, like a story about a gray top for children, which will come and bite by the flank.

Therefore, I would like to break stereotypes about legacy a little, if not all, but at least some of the developers, and give an understanding of how interesting the legacy is and that you can not really be afraid of it, but even love it.
')
At once I will make a reservation that we are now talking about the code, and only about it. Not about beautiful offices, attractive HRs, cool leads and big PR. Code.

Suppose you are a PHP developer, and you would be told, “Come to our project, we have been writing this code in PHP for several years, we have hundreds of megabytes of code, almost no OOP and procedural programming”. Does it sound doubtful in the legacy section? And if you were told "Come cod vk?". There is a difference, and it is significant.

Head over to the other side.
You would say: “Listen, I have a great opportunity for you, I need you to apply all the patterns that you know, you can use any frameworks and technologies, you can write everything from scratch, just make me a home blog for my dog.” No legacy, full of thought and freedom of action. Everything can be done perfectly beautifully on a trendy node.js, screw ajax and comet, put caches on redis, add RT search with morphology on elastic'e, but ... why?

Banality number 1:
An interesting project is one that is of interest to a developer in principle. Beyond language, beyond technology, beyond architecture. And it has nothing to do with legacy.

You know the feeling when thinking about a new project, you draw in your head a picture of how entities need to interact with what, which layers of architecture need to be done, where bottlenecks will appear and what needs to be done to avoid this? A sort of fairy-tale world with its inhabitants and connections, which lives its own life and which you gradually translate into code, into something tangible that begins to "exist".
I’ll tell you a secret - it’s impossible to write code if you’re not an “artist”. But artists are not immediately able to write beautiful canvases. They learn to more harmoniously select colors, display perspective, combine elements, etc. Programmers in the same way learn to select solutions, see the future of the project and make everything as convenient as possible, supported, efficient, and within available resources. And if in the course of the life of the picture, new requirements for it appear - “And let's do that now it is evening. And let the dragon fly across the sky. And in fact it is winter now, not summer. And let there be a Dainer killing George Martin in the background ”- at such moments it is difficult to preserve the original creative, somewhat beautiful, idea of ​​the author.

When you start working with a new project, in fact you are the creator, the inventor. Wonderful feeling. When you get a legacy code, a project to support, for some reason the majority has an image, as if they had just received the Augean stables, moreover, this was before they actually looked into the code. Just think that this is legacy.

Whatever the project, it is also based on a picture, maybe the brush strokes on it are not so harmoniously combined, but the picture was. And while you are reading a legacy, you, as a researcher, can restore it in your head, and moreover, as a professional, you can make it really beautiful. To competently add the missing details, to finish painting what has turned out very nicely with the previous “masters”, and to get a new picture, yours already, and only in your power to make it even better than it could even be from the beginning.

Banality number 2:
"Legacy" does not mean "ugly." This is a chance to make it even more beautiful.

Many people know the phrase "A fool learns from its mistakes, and a smart one learns from others." If any of you still practiced TDD, you know perfectly well that it is impossible, with all professionalism, to always write code without bugs, even with a million reinsurance schemes. This is a natural occurrence.
So, if you are experienced enough and know how, like a real detective, a researcher and even a reconstructor, delve into someone else's code, create his image in your head, find hidden patterns, then you can also extract a lot of useful information from it. Some strange solutions that actually were in place, but you suddenly think about it and realize that you know a more optimal solution, simply because you have already written something that is not optimal for you, and you saw it in action, and now you know how to do better. We all know that refactoring can be infinite, but in order to refactor, learn new things about code, you need to have it already lived, it has already been written, and then the legacy fits perfectly.
I just want to note that only those who like to find new approaches, who love to think not according to a pattern, will understand me in this. There are developers who, rather because of their inexperience, meeting with old projects, are ready to take banners and shout “Yes, there’s a complete shit, it’s all really written differently in% my_favorite_framework%, it’s perfect, it solves all the problems, everything rewrite !!! ".

In legacy code, a lot can be learned with the right approach and skills. First of all, how the other developer sees the code, and what is his approach good, and what is bad. Expanding your picture of the world always makes it even more complete, if you do not close on the template solutions.
In fact, the code for most popular frameworks, libraries, and components has become legacy in many ways. And I think you are unlikely to deny that studying this code will never give you something new, valuable to the developer. That you will not read in one book.

Banality number 3:
Legacy is a great tutorial on how to do it and how not to do it.

Have you ever read books that were very difficult for you to understand? Take, for example, to compare the poems of Dante, or the stories of Hermann Hesse, or Ayn Rand, or even any RF code. Familiar feeling when the gears of the thinking process begin to break each other teeth on the second page? But does it in any way detract from the semantic value of the work?
So, reading someone else's code can sometimes be no less furious. Of course, a concept such as CodeStyle has long been invented. However, for some reason, many legacy is associated with something that is very difficult to read, which is written in violation of all the rules for a very long time. In fact, the person who wrote this code simply followed the “rules”, and learning to read code in any style is not so difficult.

Banality number 4:
Legacy is not that hard to read, even if CodeStyle is broken. In addition, the main modern IDEs have already learned at a decent level to support code auto-formatting.

Once upon a time, on freelance, one familiar customer asked to modify a simple project on a well-known framework. It was made to him by one freelancer, literally recently, but he disappeared after payment was received, but you need to fix the small change.
What was my surprise when I found a copy-paste of launching a simple controller with a single view-file, in which all the (!) Project code was located. The man made the project "on the fashionable framework", but how (!) He did. If this code otlezhal year or two, and got someone to support, he would have with horror in his eyes would say, "What kind of legacy ?!". But for me this code wasn’t "week old". It was an ordinary, banal govnokod.
Now I am working on a project, the code of which is being developed for the 12th year and will continue to grow. And you know, despite some shortcomings, even very old pieces look and read very well. It is legacy, good, good legacy, many times refined, but still legible and readable.

Banality number 5:
"Legacy" is not equal to "shit".

Has it ever happened to you that when opening a project after a few years ago, you see the code and feel light deja-vu? As if out of the fog, the outlines of something painfully familiar, almost dear, gradually begin to appear. And in order to dispel the last doubts in the course goes blame and annotate, and then everything falls into place. Is he. He is. And thoughts start spinning in my head like “How could I write this ?! Ehhh, green was. Oh, but I did it cool, simply and with taste. So it is, but this must be quickly corrected so far no one has seen. ” Familiar?
So for some reason, many people think that legacy is something that happens to someone else. That you’ll either never look at your code in a few months / years, or don’t even admit that now you are writing something that looks like legacy (or does it already look like this?). However, it is not.

Banality number 6:
You also write Legacy.

Summarizing all the above, I would like to say that, as such, the term legacy does not deserve the honor of being a “horror story”. It has its wonderful sides, and only the inexperience of the developers, and not only those who wrote the code, and sometimes those who are going to work with it, creates such fame for him. A lot of legacy code went through my hands, and I really enjoyed working with most of it. Understand how it works, try to understand the author’s intention, find more suitable solutions or, on the contrary, make sure that the author’s decision was not very obvious, but it turned out to be very effective. To finalize what works, what they use, to do it better is an excellent experience. You cannot learn how to write code well, if you write it either always from a template or always from scratch. Man cognizes everything in comparison, and the more sources for comparison, the better you write.



Successes to you on the open spaces of development and more good, good Legacy-code! I hope, now this phrase is perceived for you differently than before the beginning of the article.

Bonus in the form of a list of books, if you have not read:

Refactoring - Improving the Design of Existing Code
Working Effectively with Legacy Code
Refactoring to Patterns
Clean Code: A Handbook of Agile Software Craftsmanship