DEV Community

Cover image for Maintaining large JavaScript applications

Maintaining large JavaScript applications

Mathias Schäfer on January 16, 2019

Lessons we have learned from maintaining large JavaScript applications in the long term. At our agency, a client project typically lasts a couple ...
Collapse
 
simonhaisz profile image
simonhaisz

Developing in a 'legacy' codebase

looks at bad code
"Ugh, this is terrible and now I have to deal with it. Who wrote this crap?"
runs git blame
reads commit log
"2012, Bug-23876: Fix null-pointer from race condition. User id:..."
sighs

Collapse
 
lysofdev profile image
Esteban Hernández • Edited

Great post!

Avoiding rewrites is probably the biggest lesson I've learned. We face the urge to rewrite our front-end applications per sprint almost but I think everyone underestimates how much of the existing codebase can't just be lifted into another codebase especially when dependencies differ.

Another important thing I've learned is that the team should take some time to familiarize with the framework and tools in use. Lack of knowledge of the existing tools leads to weeks of work being spent reinventing the wheel only to find that a simple function provided by the framework provides significantly better performance than our in-house solution.

Collapse
 
nverinaud profile image
Nicolas Verinaud

I have an experience similar to yours where I maintained a codebase over multiple years and I went to the rewrite route three times... I faced the same problems over and over again. Then I realized that the only way that I have found to be really efficient to maintain and evolve a codebase is to write automated tests suites.

With automated tests suites you can refactor the code, clean it and make it better, simpler, because you no longer fear of breaking anything.

Have you tried it ? :)

Collapse
 
rhymes profile image
rhymes

For me, the opposite is true. Maintaining a project’s code over a couple of years taught me more about software development than multiple short-lived, fire-and-forget projects.

Ahah there's truth in that. Although in the long run there should be a little bit of both (maintaining and working on new things)

Really good overview, thanks!

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
casen profile image
Casen

One of the best posts about large Javascript applications. Functions are the best! I've learned to embrace functions in the same way, and it has made my code so much more maintainable. After writing and maintaining large JS applications for many years, I've been able to remedy all the poor design patterns from other object oriented languages by using functions. Things are even better now with Typescript.

I think the reason there is always so much temptation to rewrite the frontend is because many of the early frameworks were designed poorly, and those poor design patterns led to a terrible and complex monstrosity over time. React, as you mentioned, is embracing small, single-purpose components and functions. This allows for composability and re-use. I think it offers better training wheels for more novice developers, which will hopefully lead to more maintainable code for most organizations that use it.

Collapse
 
yskristiawan profile image
yskristiawan

I would say make your own UI class which calling any UI framework you use. Next time you need to modernize your UI, replace the UI framework and change the class.

Collapse
 
marttingm profile image
Martin Giannechini

Great post! Thanks for sharing, I will definitely use some of your insights in a project I'm working on.

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
yaron profile image
Yaron Levi

Great tips! thank you