How to Maintain Legacy Projects in Javascript

Depending on the scope of a project, the actual development phase might take anywhere from a few months to a few years to complete. A poorly managed project, or a project that wasn’t scoped correctly from the get-go, has a significant potential for errors, unscalable parts, and an unwieldy code base.

In the case of Jobsity, for example, we’ve been working at Jtalent for almost two years. Developers have come and gone, and while the scope remains relatively consistent, there’s a constant need to add new features and fix functionality bugs.

Refactoring swathes of code is a costly approach that, while ideal, can inflate a budget and take resources away from finishing a product before the deadline.

One of the newest approaches on Javascript is to rewrite existing features with the newest, most popular frameworks, instead of building on top of the older code. However, project limitations regarding time and budget might prove this approach unworkable, and that’s when we have to figure out ways to make small improvements to the code.

A quick exercise to do with your existing codebase is re-reading through features you’ve already done and figure out why you did it that way. This test could give you an insight as to what you would do differently, what sort of logic you would use these days, and sometimes if you’d even keep the existing logic as is, but you would use a different framework to work it into the project.

Here are some tips on what to look out for when re-reading legacy code.

Reuse Functions

A function is just a piece of code that takes input and returns a value. When writing good, reusable code, it’s easy to fall into the trap that more complex structures often mean better code. The truth is that by effectively and smartly using the most basic and flexible of Javascript structures, your code base then falls into a nice clean pattern all on its own. It’s just a matter of being smart with how you use and deploy them.


An object is mostly just a structure of values. They can have properties, same as any other object in an object-oriented programming language, which dictate the kind of data the object manipulates. If a function is attached to an object, the function is known as a method, and it allows the object to manipulate data. Objects exist in most Javascript projects as they are highly flexible.


Classes are essentially line manufacturers of objects. They are made up of objects and can manipulate them.

Classes in JavaScript are less intuitive than in other languages since Javascript is a protocol bases language. Standards like ECMAScript make it easier to use, but in the end, classes are just a cleaner, simpler syntax for complex objects.

Classes should come into play when they have a specific purpose. The general “best use” consensus these days dictates a move away from rich classes and into more stateful components.

Structuring Code

The best way to approach large projects in Javascript is by using functions. Functions are versatile structures that can accommodate most of the requirements in the code. Use pure functions as much as you can. That is functions that return the same result given the same parameters and is not dependant on states.

Another good way of structuring code is to avoid mixing data and logic.

Also, since classes can become unwieldy and confusing, avoid using them as much as you can. If the need arises that you must use a class, it should do only one thing.

Popular Javascript frameworks like Angular and React, define their components via classes. Whenever required, you should create a new lightweight component class for any new concerns.


Modules should be used to create a single export (or few) that would result in one file per function, or one file per class, and so on. This way of grouping modules creates a large number of small files, which makes code much more readable and maintainable. Also, dependencies are declared more efficiently with this method.

Phase Out Untyped Objects

One of Javascript’s most ubiquitous features is its ability to create objects on the fly. So widespread is this practice that it gave rise to another data format that we use today called JSON.

Smaller codebases don’t suffer much through the use of independent untyped objects all over the place, but when used liberally through larger projects, they become a liability.

Having dangling objects without a defined membership can cause significant headaches during runtime, as it’s difficult to infer if a property exists or if a type has been set. On first glance, these objects don’t tell you what their status is at runtime.

Clean Code

These are just some guidelines that could help you better future proof applications in Javascript. Frameworks rise and fall as the language improves, so it’s vital to keep codebases clean, and readable.


Feb 18, 2019