DEV Community

Cover image for Lessons Learned by Maintaining a Large Vue.js Codebase
Maxence Poutord
Maxence Poutord

Posted on • Originally published at maxpou.fr on

Lessons Learned by Maintaining a Large Vue.js Codebase

I've been maintaining a massive Vue.js codebase for the last 3 years. Here are 9 lessons I've
learned along the way. Not really mistakes I've made but most likely things I'd do differently
today.

TL;DR:

No standards, no consistency

I don't think it's possible to have consistency without any communication. If your app is
organised in 3 different feature teams you don't want to have 3 different ways of doing one thing.
Agree on standards then communicate. Communication is the key.

Don't be afraid to repeat yourself: "pedagogy is the art of repeating yourself".

Close the door on bikeshedding

It starts by linting your code. No one likes comments like "you forgot a semicolon" on pull
requests. Find a set of rules and follow it. Blindly. If you start to discuss it, you open a door
for bikeshedding.

I also recommend you to write a "Pull request: do and don't" so everybody knows what is and what's
not expected.

Respect your elders

Working with legacy can be frustrating. But it's not a reason to finger-point your elders. Try to
find the root cause (i.e. code was written by Backend, there was no communication at that time...).
Migrating towards greener pastures is a slow process. If there's no plan to get rid of the debt,
it's time to make one.

"F*** the future. Program for today."

DHH Tweet with the original quote

We've made a lot of big technical decisions based on FUTURE. Guess what? Years after this future
never happened. I don't have a crystal ball so I can't tell what the future will look like. If it's
the same for you, don't make big decisions based on dreams and hopes.

Program for today!

Dependencies: we should have been stricter

a very long list

Me opening the package.json

Every time I open the package.json file, I keep thinking the same thing: "we should have been
stricter"
. We have a list of 95 dependencies and 90 dev-dependencies.

Why?

I think the fear of being a gate blocker played a big part. A second factor was probably letting
the pull request merge without approval from a frontend developer. Having many dependencies increase
the risk of having a malicious package. Also, if we want to change the Vue.js version, we have to
ensure that each library support it.

// TODO: refactor

a 3y old todo!

TODOs are the graveyard of important but not urgent tasks. The "I will fix it later" strategy
doesn't work. If you're not very proud of the code you wrote, it's fine. It happens to the best of
us ;) But please don't pollute the code with a TODO.

Keep your audits

We have made a lot of progress in terms of performances, accessibility, and code quality. In 3
years, I've made tons of audits with tools like Google Lighthouse or Axe. But I never kept a single
one. It's such a pity because if today someone asks me what the progress we've made over the last 6
months, I can't give any numbers.

By the way, it can also provide some metrics for your CV ;)

Mimic your users

If you work on your app locally, with a 1500€ laptop and a fiber-optic internet connection, you will
never experience a performance issue.

I can say the same thing if you're using a large screen. 2.5y ago, I went fully remote and I dropped
my fancy 26" curved screen. I realized that a few pages or our app were not readable on a 13".

Don't create your core components from scratch!

Creating your custom component library is a waste of time. Change my mind

We started building our component system ~2.5y ago. A lot of components we created ended up being
surprisingly complex. When we couldn't refactor them, we created a new one (and deprecated the
other).

Today, we have ~30 deprecated components and some of them are used a hundred times.

Looking backwards, we wasted so much time creating the components (from scratch), testing, making
them accessible (a11y) and writing the documentation. If we started with an existing one, we could
have spent more time focusing on the business or the architectural part.

No one cares if the button component you're using doesn't have "the perfect border-radius"!


Thank you for taking the time to read this post. I hope you found it useful! If you liked it, please give it a ❤️ or a 🦄! Also, feel free to comment or ask questions in the section below or on Twitter @_maxpou :)


Originally published on maxpou.fr.

Top comments (5)

Collapse
 
domiii profile image
Domi

Hi @maxpou

I can wholeheartedly empathize with all of your points. But, of course, not all points are equally difficult or important.

I personally find that one of the hardest things to do is to find that balance that keeps us "writing for the present".

So here we go:

How to avoid writing for the future?
How to avoid writing your own "framework code" (or "core components", as you call them)?
How to do all that and still avoid all that ugly copy&paste, that has become increasingly common in frontend code? Or is copy, paste and adapt a good way of doing things now?
Any deeper thoughts on this?

Feel free to reach out, if you have the time and motivation.

Collapse
 
maxpou profile image
Maxence Poutord • Edited

Hey @Domi thanks!

How to avoid writing for the future?

Well if during the development I think about something that may come out later (but it's not business approved), I forget about it. Let say I'm creating a comment section for a blog. If I only have 10 comments/day, I'm not gonna create a very complicated administration panel just because "it's going to scale". That's the idea.
But, I do agree with you: it's hard to write code for the present!!

How to avoid writing your own "framework code" (or "core components", as you call them)?

Don't get me wrong, it's ok to have your custom component. I was working on an educational product. We made our own calendar/timetable... And I still support this.
However, I think creating our own Tab/Panel/Popup component was a waste of time.
If you feel you're reinventing the wheel, just take an OSS (or a paid) component library.

How to do all that and still avoid all that ugly copy&paste, that has become increasingly common in frontend code? Or is copy, paste and adapt a good way of doing things now?

Hmmm good question. I'm not completely against code duplication. As someone told me once: "duplication is far cheaper than the wrong abstraction". Duplicating code x2 or maybe 3 times is ok. But at the 3rd time, a dark pattern is emerging and, it's time to do something!
When we planned our sprint we dedicated 10-20% for tech debt reduction. So we're sure debt stay "under control".

Hope I answer your questions :)

Collapse
 
domiii profile image
Domi

Thanks for the reply!

"I'm not gonna create a very complicated administration panel"

This sounds more like feature creep or miscommunication within the team, no?

"I think creating our own Tab/Panel/Popup component was a waste of time"

Sure, if a library already does the job (and it is sufficiently flexible and/or has an active developer team), it's a good starting point. I find, I often end up writing light-weight wrappers on top of most libraries just to remove a lot of the boilerplate. This way, 80% of the library's usage (hopefully) ends up streamlined toward one or two specific approaches, rather than having everyone on the team trying things out and then ending up with a mess of mis-used features and squares squeezed into circular openings. I guess, this approach might apply to teams mostly consisting of Juniors who would appreciate the additional guidance, not necessarily to more experienced dev teams.

"Duplicating code x2 or maybe 3 times is ok. But at the 3rd time..."

"we dedicated 10-20% for tech debt reduction"

Good ideas and sounds like numbers to play around with. I will certainly incorporate that into future planning!

All in all, you are bringing up great stuff! Thanks for the quick forth-and-back.

Collapse
 
technicaldee profile image
gisthive

Wow... Thanks for sharing

Collapse
 
maxpou profile image
Maxence Poutord

Thank you :)