Remember that one time you were looking at your team’s codebase (or even your own) and thinking “who the hell wrote this code…?” just to have that awkward moment when Git Lens shows it was actually YOU who committed the code.

I’ve been there, done that. There’s nothing worse than the realization that the huge bowl of spaghetti code 🍝 you’re looking at came from your own 2 hands.

Gordon Ramsay would be ashamed.

The Problem ☠️

Deadlines exist, features are requested at an accelerated rate, and you can sometimes get caught weighing quantity over quality.

Although nothing may seem wrong on the surface to a user’s perspective, rushing these things can sometimes make the codebase slowly but surely begin to become inconsistent, hard to read, and overwhelming especially for new onboarded developers.

Focusing on pushing new features is great and all until the time comes when you find yourself refactoring more code than you're implementing.

I have experienced this in the past and wanted to provide some of the ways I try to avoid this happening before it happens to you and your team.

The (Partial) Solution 🛠️

Better Variable & Function Naming ✅

The next time you think of naming a variable...

const data = {}

or a function...

function _handleOnClick() {}

...take a little more time to better describe what the object is storing & what the function is doing.

I already know that data is coming from the server, but what data? I already know this method is attached to a button onClick, but what is happening when it is clicked?

This can sometimes be tricky, you can find yourself spending more time sitting there thinking of better ways of naming things than actually writing the code.

Trust me it is worth it.

Instead of thinking of names before implementing it sometimes I initially give it a generic name and then once everything is hooked up and working I go back and ask myself:

“How can I make this code more readable for someone who has never seen it before?”

(Or myself when I look at it again 6 months from now)

Naming things can sometimes be easier after it is implemented because you can then see all the implementation details of what it does.

Design Patterns ✅

The good news is that you don't have to reinvent the wheel, there are already design patterns to solve commonly occurring problems in software design.

The bad news is that there is a lot of them. This topic alone could be its own blog post and realistically would be more than one although you have probably already used some even without knowing and you don't have to memorize every single one of them.

That being said, I'll just list some resources I used to get started:

Consistent Project Structure & Flow ✅

It is so much easier to navigate and read a codebase if you have consistency in things like a folder, module, and code structure.

Don't you always feel more comfortable working on your own personal projects?

You know where things are & should be, keep everything consistent in the way things are done, and know how to go about making changes to the codebase.

Obviously, this takes more time to implement in a team environment but is definitely worth sitting down with team members and figuring out an agreed-upon approach for different aspects of your project.

Good Test Coverage ✅

Tests are documentation and a safety net for developers. They should describe what the specified code is responsible for and what its expected outcomes are.

It is much easier to read the descriptions of these test cases than going line by line figuring out what the code does in its implementation.

TEAM Code Review ✅

When new code is requested to be merged, it is the responsibility of ALL developers on the team to view the PR and be aware of the changes being made.

It is much easier to continuously stay updated on the changes made to the codebase than getting an assigned user story or bug fix to code that you have never seen before.

Use Comments In Your Code ✅

It is inevitable that you will have to code an algorithm or logic that is a bit more complex than normal.

In these scenarios simply adding a comment describing the logic the same way as a test case describes the test it is about to run will help the reader quickly understand what the code does.

I tend not to leave comments on everything because if you are naming your stuff correctly like mentioned above, you really won't need to.

Conclusion

Computers and code are what make your websites and applications run but you need to also remember that humans need to be able to read and easily understand the code as well.

Utilizing some of these techniques and learning from experience can help decrease the time you find yourself refactoring your codebase.

No more spaghetti! Write better code and make Gordon Ramsay proud 👍