How not to suffer from legacy code on the front-end

The focus of this article is on front-end technologies, but the concepts serve both worlds.

This article was written by a student and developer who is open to getting any knowledge and passing it on, my networks [Twitter], [Linkedin], [Instagram], Brazilian Portuguese version also available [Click to access]

You don’t have to be the best developer in the world to know that legacy code is a ghost that has haunted every developer or at least will haunt in any moment and nothing like experiences passed on to prevent any apparition of him. I have gone through some challenges with the dev team that I participate, it will be an honor to share knowledge with you reader.

This is a subject that never ceases to be current, day after day we see or hear that so-and-so suffered with a code in angular version 1.4, or when we open our Linkedin and see dozens of specific proposals for programmers with experience in some technology that hasn't been updated for more than 5 years or more, or we just have to find an alternative to that random snippet of code in Jquery (yes my brothers, Jquery is a legacy technology).

But what is legacy code after all, and more importantly, how do I avoid legacy code?

First, legacy code has some characteristics that will even be easy to identify if you see one. The main features are:

• Difficulty or impossibility of maintenance;
• Bugs caused by the lack of treatment or support of the technology used;
• Pattern of architecture unrecognizable;
• Hindered scalability.

There are many other features that condition a code to be legacy, but the most apparent are described above. As the article in question aims to indicate how not to suffer from this type of code, the explanation behind each of these characteristics will have to be explained in another article.

Finally we get to the part where I explain necessary practices so that you can avoid later headaches or even “save” that legacy code that haunts you. Let’s go in stages:

• Standardize the entire structure and architecture of the code;
• Document for posterity;
• Make your code reusable;
• Use technologies that are trusted;
• Plan your updates;
• Tests are always welcome;
• Implant the culture of the “STANDARD”.

Standardize the entire structure and architecture of the code

First, let’s agree that just by the name ‘architecture’ and ‘structure’ the best of the worlds is to be just one standard, but in many situations and examples, we see that this is not what happens. Very commonly called ‘dirty code’, the lack of a standard in both the architecture and structure of a system can generate a lot of headaches, such as the difficulty of maintenance, the difficulty of training new employees, the difficulty of scaling your application, time wasted with simple bugs, and among others.

Standardizing the architecture and structure of an entire system can be quite laborious depending on its size. But it can bring huge benefits. As a way of understanding, I prepared an analogy:

Think about being in your company’s office, your boss asks for a specific report from a few months ago, which was kept with you, but you, with a terrible organization, don’t know where the report is. You look and look and find nothing, consequently your boss doesn’t like it and gives you a call for attention.

It’s a childish analogy I would say, but it serves a lot for the context. When you don’t have a standard, everything takes longer to be done, whether bugs or new implementations, and this happens because the code is all tangled up with standards that were sometimes “created” by people who don’t even be more in the company, and trying to fix bugs with dirty code is most of the time not a pleasant experience, it takes time and possibly more than one head thinking about. With that I want to leave the encouragement with a very clichéd phrase: “Time is money”. And I believe you will save a lot more time having one standard for your entire system. For background purposes, read Robert C. Martin’s Clean Code and Clean Architecture.

Document for posterity

This type of practice is at least essential for any type of code, and this statement is not just for the frontend. When I say that documenting is essential, I’m not saying that we just have to comment our code, what I mean in reality is that we have to make our code understandable to possible other programmers who might analyze/write the same, and commenting is a way to do this, but it is not the only way, there are many ways to document our code, even for reasons that sometimes commenting is not enough to make an understandable code, and obviously commenting beyond the necessary can harm our structure.

Turning to ways to document, we have some ways that can vary from language to language, from structure to structure, from methodology to methodology and so on, that is, always read the good documentation practices of technology, language, etc. that you are using.

Finally, always keep in mind that your code can reach other devs, so leave it in a way that all seniorities will understand.

Make your code reusable

A mentality I like to have is that I have to code thinking whenever my code can become a gigantic system or even an ecosystem, it makes me rethink every line I write:

“I will use this later elsewhere?”

Coding thinking about reuse changes everything, because instead of simply solving a problem, you solve a set of problems, the scope changes from a simple file to the system as a whole, I dare say that the principle of reuse, especially in the frontend, is very important because it makes our code much cleaner and leaner.

So I encourage you to do this exercise, whenever you are coding think “can it be reused?” or even “Is there already a solution to this problem in the system?”, this will bring economy and simplicity to your code.

Use technologies that are trusted

Whenever we are going to decide the technologies that will be used in the projects we tend to get carried away by the “hype” (especially in the frontend) unfortunately. And this is a punch in the pit of the stomach because wanting it or not we like to use what everyone is using, but this can be a decision that will affect your entire system due to the fact that much of what is ‘hype’ today can very well not be tomorrow.

You see, I’m not saying it’s FORBIDDEN to use technologies that are in hype, what I’m saying is that some points need to be analyzed before going out using anything that appears with many stars in github on your system (the test is free), and the points are:

• Is it a technology already consolidated in the market or just a collective delirium?;
• It have constant fixes and updates or commits separated by months and even years?;
• Through a survey, do companies large enough use the technology or only the college/discord colleague use it?;
• Is it a scalable technology or will it have problems when your system has many requests and accesses?

These and other questions have to be asked (differing from system to system) so that there are no headaches later, especially when deciding on a new technology in the middle of an existing system.

Plan your updates

Things update and change constantly and if you and your system fall behind I’m sorry to inform you that soon it will be legacy. One of the cultures that I see least in the companies I’ve been in contact with is planning to update the dependencies of the technologies used, although this is laborious and can delay plans, it is extremely important that your system has this type of culture, as annually (in case you have pondered the previous topic) dozens of updates of the technologies you use come out, and this brings changes even in the algorithms in your system, no wonder they are called UPDATES.

The lack of planning at least every six months of updates on your system will lead to even beyond the ‘legacy’, and may break your system depending on the update. So I strongly advise delaying some plans for that to happen.

Tests are always welcome

Fortunately this is a reality a little more common among us developers and companies, but I can’t leave to talk about this subject, being so important to the topic covered.

Even though this is more common than the other points, this is a culture that I see using less than necessary in frontend development (my impression). Today we have a lot of support for implementing unit tests on the frontend, whether they are e2e (end to end) or focused on applied logic.

This kind of this needed practice is no longer debatable, lack of testing can lead to exaggerated refactorings, waste of time with unnecessary bugs, loss of code quality and so on. Therefore, implementing tests on your system it should have been a reality for a long time.

Implant the culture of the “STANDARD”.

This is a somewhat unusual practice, but very effective if you are developing with a team.

It is about implementing in the team the culture of following the system standard above all, whether for new implementations or corrections / refactorings, this does not mean that new standards do not appear as time goes by, but it does mean that the team will be united in a purpose be it to keep what is there today or to implement something new.

This prevents devs from coding with irresponsibly and causes them to think in the plural instead the singular, decreasing a probability of legacy code.

Concluding…

In addition to the practices exemplified above, there are many others, varying by methodology and culture. The principle I really want to leave to you readers, is that coding is not something singular and selfish, so always think about the future of your system and your devs colleagues. Obviously we shouldn’t believe in the utopian that we can avoid any and all headaches, but the bare minimum to avoid legacy code should be done.