Working on a frontend project doesn't mean you understand how it works. You may be able to make some changes, but not all of them are going to be possible or easy. It's important that you understand the context of the codebase so that you can work collaboratively.
Be ready for the unexpected.
The frontend landscape is constantly changing. What was the state of the art a year ago may be antiquated today. As things change, you should be ready for the unexpected and prepared for changes in direction.
If you're faced with an existing project that could benefit from a complete overhaul, ask yourself what your team's goals are for this project. Do they want to build something that can compete on its own merits? Or do they want to make sure it doesn't fall behind as quickly as possible?
If it's the former, then consider re-architecting your frontend codebase so that it's compatible with modern frameworks and standards. This way, if features need added or changed later down the line (which will happen), you won't have any trouble keeping up with current tech trends like React Native or Web Assembly (WASM).
It's important that you understand the context of the codebase so that you can work collaboratively.
The first thing to do is to get your head around the codebase. It's important that you understand the context of the codebase so that you can work collaboratively with other team members.
If there are already developers on the project, it's likely that they have some sort of process in place for working with new code and making sure everyone knows what's going on. But even if there aren't any developers yet (or if you're one of those developers!), it helps to know what tools are available and how others use them.
There are lots of ways to find out more—you could ask questions or request help from a co-worker who has experience using this particular technology stack, or spend some time researching tutorials online or talking with experts in another part of your company who might be able to help fill in gaps in your understanding.
Make sure you do some research.
When working with an existing project, it's important to understand how the codebase has been built and whether or not it's worth making any changes. You may be able to make some improvements by adjusting the way things have been done in previous versions of the project, but if you're starting from scratch then it can be best to start as soon as possible instead of trying to retrofit ideas into an existing setup.
Some questions that you should ask yourself when examining a new project include:
What frameworks have been used?
What is this project trying to achieve?
How is this being used? Is there documentation available? Does anyone know anything about its history or limitations?
What are its limitations—how will these show up as we build out features over time and what do they mean for our users' experiences using our product on different devices (desktop vs mobile) or browsers (Chrome vs Firefox).
There's a reason for everything, so don't be discouraged when things don't get figured out immediately.
It's a lot to take in, but don't let it get you down. You'll probably run into some challenges along the way and have some questions about what's going on. There's a reason for everything, so don't be discouraged when things don't get figured out immediately. Remember that this is your first time working with frontend code (and maybe even JavaScript), so expect to make mistakes as you learn how things work, but also feel free to ask other developers for help!
There's no point trying to rewrite someone's code.
There's no point trying to rewrite someone's code if you don't understand it. If you do, then that's another story. Some people think they can just fix someone else's code and improve it—but the truth is that this is very difficult and requires a lot of experience. Unless you are an expert in your field and know exactly how to do something better than anyone else out there, then I would advise against rewriting anything as a beginner developer (unless told otherwise by your team).
If you can't figure out what the original programmer was thinking when they wrote their code, then maybe its time for some fresh eyes!
It may be better not to touch the original codebase in some cases, such as for some boilerplate instead of pushing your own design directly into production.
If you're looking to make some changes, it's best to start by taking an inventory of what the current codebase already has. Identify areas that need improvement and which features are missing or could be improved upon. Once you've done this analysis, take a look at what kind of other projects have been done before yours so that you don't reinvent the wheel unnecessarily in your own work. If no one else has built something similar yet, consider making use of a boilerplate as a starting point for your own project rather than pushing your own design directly into production.
If any changes do need to be made to an existing frontend project's codebase, start small and test everything thoroughly before moving on to bigger changes or additions.
Conclusion
Learning how to deal with an existing frontend project can be a challenge, but it's one that you'll have to face sooner or later. Hopefully this article has helped you understand what the issues are and how to deal with them.