The Path Through Legacy: Delicate Balance Between Tolerance and Phobia

Rate this content
Bookmark
Slides

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.

8 min
06 Jun, 2023

AI Generated Video Summary

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.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
React Finland 2021React Finland 2021
36 min
The Eternal Sunshine of the Zero Build Pipeline
For many years, we have migrated all our devtools to Node.js for the sake of simplicity: a common language (JS/TS), a large ecosystem (NPM), and a powerful engine. In the meantime, we moved a lot of computation tasks to the client-side thanks to PWA and JavaScript Hegemony.
So we made Webapps for years, developing with awesome reactive frameworks and bundling a lot of dependencies. We progressively moved from our simplicity to complex apps toolchains. We've become the new Java-like ecosystem. It sucks.
It's 2021, we've got a lot of new technologies to sustain our Users eXperience. It's time to have a break and rethink our tools rather than going faster and faster in the same direction. It's time to redesign the Developer eXperience. It's time for a bundle-free dev environment. It's time to embrace a new frontend building philosophy, still with our lovely JavaScript.
Introducing Snowpack, Vite, Astro, and other Bare Modules tools concepts!
React Summit 2022React Summit 2022
17 min
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
There are many ways of authoring components in React, and doing it right might not be that easy, especially when components get more complex. In this talk, you will learn how to build future-proof React components. We will cover two different approaches to building components - Composition and Configuration, to build the same component using both approaches and explore their advantages and disadvantages.

Workshops on related topic

DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.