What is legacy code and how to work with it
Source: Dou Sooner and later, a programmer will probably have to encounter legacy code. To ease the consequences of this acquaintance, I have selected some practical tips and examples from my own experience - in particular, working with a legacy Java system.Legacy Features
Legacy is someone else's code, which is often so terrible that it is generally not clear how to work with it. And if you have to work with a legacy system, in addition to the old code, you will also encounter:- with outdated technology;
- heterogeneous architecture;
- lack or even complete absence of documentation.
-
We cannot disrespect a system that makes millions or is accessed by thousands of people a day. No matter how poorly it was written, this disgusting code survived to production and works 24/7.
-
Since this system brings real money, working with it comes with great responsibility. This is not a startup, but something that users will work with tomorrow. This also implies a very high cost of error, and the point here is not in the client’s claims, but in the real state of affairs.
Reverse engineering
To successfully work with legacy code, you will have to use reverse engineering techniques. First, you need to carefully read the code to understand exactly how it works. This is mandatory, because we most likely will not have documentation. If we do not understand the author’s train of thought, we will make changes with unpredictable consequences. To protect yourself from this, you also need to delve into the adjacent code. And at the same time move not only in breadth, but also in depth. Where is the method called with the error? Where does the code that calls it come from? In a legacy project, "call hierarchy" and "type hierarchy" are used more often than anything else. You will have to spend a lot of time with the debugger: firstly, to find errors, and secondly, to understand how everything works. As for documentation, it would not be a bad idea to resort to industrial archaeology. It can be very useful to dig up old documentation somewhere and talk to those who remember how the code you inherited was written. Using these techniques, sooner or later you will begin to more or less understand the code. But to prevent your efforts from going to waste, you must immediately document the results of your research. To do this, I recommend drawing block diagrams or sequence diagrams. Of course, you will be lazy, but you definitely need to do this, otherwise in six months without documentation you will be digging through this code like it was the first time.
Don't rewrite the code
The most important thing in the development process is to beat yourself up on time and not try to rewrite the entire code from scratch. Estimate how many man-years this will require. It is unlikely that the customer will want to spend so much money on redoing something that already works. This applies not only to the system as a whole, but also to any part of it. Of course, they may give you a week to figure everything out, and another week to fix something. But they are unlikely to give you two months to write part of the system again. Instead, implement the new functionality in the same style as the rest of the code. In other words, if the code is old, you should not be tempted to use new beautiful technologies: such code will then be very difficult to read. For example, you may encounter a situation like we had: part of the system is written in Spring MVC, and part is written in bare servlets. And if in a part written in servlets, something else needs to be added, then we add it in the same way - in servlets.Respect business interests
It must be remembered that any tasks are determined, first of all, by value for the business. If you do not prove to the customer the need for certain changes from a business point of view, these changes will not happen. And in order to convince the customer, you must try to stand in his place and understand his interests. In particular, if you want to refactor just because the code is hard to read, you won't be allowed to do it, and you have to live with it. If you really can’t bear it, you can reorganize the code quietly and little by little, spreading the work across business tickets. Or convince the customer that this, for example, will reduce the time required to find errors, and therefore ultimately reduce costs.Test
It is clear that testing is necessary in any project. But when working with legacy systems, special attention must be paid to testing also because the impact of changes made is not always predictable. You will need at least as many testers as developers, otherwise you should be incredibly good at automation. In our project, testing consisted of the following phases:- Verification, when the implemented functionality of a feature is checked in a separate branch.
- Stabilization, when a release branch is checked in which all the features are merged together.
- Certification, when the same thing is run again on slightly different test cases in a certification environment that is as close as possible to production in terms of hardware characteristics and configuration.
Formalize DevOps and Release
The release procedure could, for example, be as follows. When development is completed and two or three testing phases have been completed, we write an email to the DevOps team 36 hours before the expected release time. After this, we call the devops team and discuss all changes in the environments (we inform them about all changes in the database and configuration). For every change we have a document (a ticket in Jira). Then, during the release, everyone involved in this gets together, and everyone says what they are doing now: “We uploaded the database,” “We restarted such and such servers,” “We went to run regression tests in the production environment.” If something goes wrong, the release rollback procedure is launched, exactly described in the original release document - without such a document we will definitely forget something or get confused.Control code quality
And finally, code review is a practice that for some reason is not used in all projects. It's great if every piece of code is reviewed by more than one person. Even in a very strong team, some bugs are always discovered during the code review process, and if several people look at it, the number of bugs identified increases. Moreover, sometimes the third or fourth reviewer finds the worst thing.Tools that make writing technical documentation easier
Source: Dzone Most programmers don't like to write technical documentation. Psychology expert Gerald Weinberg even called documentation “the castor oil of programming”: developers love to read it, but they simply hate writing it themselves.
A lack of guidance or a blank roadmap results in a lack of information about how different parts of the software work. This ultimately worsens the experience for end users of the code because, in the absence of documentation, they cannot rely on the accuracy and usefulness of the product. To make it easier for programmers to form the habit of writing documentation, I recommend paying attention to four excellent tools that are now available to almost everyone.
GO TO FULL VERSION