As a front-end teamlead, I was faced with the challenge of transitioning multiple legacy projects, which happened rapidly and was a painful process. One of the main issues I encountered was dealing with a legacy project that had no documentation. I had to figure out how to stabilize it, put it in order, and reduce the cost of its maintenance and development.
Video Summary and Transcription
Legacy can refer to ancient architecture or old code, and it is important to acknowledge and address legacy issues. Legacy code can be disorganized and outdated, making it difficult to update and extend. The goal is to leave the code base in a better condition than before, prioritizing code that is easily modifiable by others.
Available in Español
1. Introduction to Legacy
Short description:
Today we will talk about the legacy. Legacy can be some ancient architecture or old code. Legacy games built upon previous iterations to create a unique gaming experience. Acknowledging the problem in time is essential for combating legacy. Rewrite may be justifiable in certain circumstances. Documentation is important but often neglected by developers.
Hi, my name is Max. Today we will talk about the legacy. First, a couple of words about our projects. In Teotihu, Kazakhstan, Altel Digital, we developed four main mobile apps, more than 10 web applications, and more than 150 microservices.
Let's talk about good old essential problems. What is legacy? It can be some ancient architecture, maybe board game cases. Everyone left their legacy path in this world. It works in both ways. Stickers on your board game map or your package cross-dependency in React project. Well, both legacy board games and legacy codes share the same commonality of passing the down something from the past. The nature of their legacy is entirely different. Legacy games built upon previous iterations to create a unique and personalized gaming experience.
So what is legacy code anyway? You might fall into the trap of thinking that it's just an old code. Yes, it can be old. But old code is not necessarily considered legacy just because it's old. With this approach, your own very code you wrote yesterday is legacy by now. Next or following characteristics might seem familiar to you. The answer that we write code which most likely ends up as legacy is outside of the actual coding process and implementation aspect. If you are making your own small project or startup, you are more likely to write fast and revisit later. Nowadays if you haven't taken this route as a small team or one-man army project, you most likely don't have a business. The key is acknowledging the problem in time to move the practical ways of combating the problem. Unfortunately, there is no such instrument in software development like MagiKwan or Sword of Thousand Truths to make everything we want perfectly. But just as weapons and mana bars are tools to success in gaming experience, standard commitment is essential for using technology effectively and responsibly.
As developers we find the idea of rewriting because it's easier. At least, that's what we think. It's easier to judge code written before us and think we have a better solution, often ignoring the business logic that old code serves and what edge cases it was trying to solve. While I tend to believe that rewrite is often not necessary, there may be certain circumstances where it is justifiable. For instance, if a particular section of a project has reached its limit and further expansion requires complicated hacks or workarounds or if certain components are no longer in use and can be isolated, starting anew may be the best course of action. Documentation is one of those things that all developers agree but few do. At least in a practical and efficient way.
2. Challenges of Legacy Code
Short description:
You can write an endless amount of disorganized, outdated mess which makes it incredibly hard to update. A piece of code might work but it's not useful if you can't extend it. Remember what I told you before. The code you write today is old code by tomorrow. Our task is to leave the code base in a bit better condition than it was found. Rather than following best practices, it is preferable to prioritize creating code that is easily modifiable by others.
You can write an endless amount of disorganized, outdated mess which makes it incredibly hard to update. It's far easier to write lots of mindless documentation. Some say code base can be documentation by itself but having small number of links and anchors in your repository can be a thing. It's pretty much an art in and of itself.
A piece of code might work but it's not useful if you can't extend it. Sure, it can work as expected and still generate profit for the company but one day it can break the entire business workflow. We can minimize the problem by keeping things isolated so it doesn't affect the rest of the code. This can be a permanent solution.
Usually when you write new stuff they will depend on some legacy system, depending on the size, the larger the size of the code base the more challenging it will be to fix it. So, optimizing your code for change and making it easier to delete ironically makes it easier to extend in time and you will not produce legacy code today. Remember what I told you before. The code you write today is old code by tomorrow. Is your intention to be the most clever or is it to help all other future developers that will probably come long after you are gone? Our task is to leave the code base in a bit better condition than it was found. Rather than following best practices, it is preferable to prioritize creating code that is easily modifiable by others. The goal here is to slowly make incremental changes on legacy system.
