Development Setup I Should Have Done

Development Setup I Should Have Done


I am used to work on a project as a solo warrior, therefore I have never consider about setting up a proper development workflow setup.

By workflow setup, I mean a set of rules that everyone in the team should follow. This includes coding styles, linter, code formatting, and set of test before pushing code to remote repository.

As a solo coder, those things never bother me because in every situation. I am always confident that every bit of code I push into remote repository will have everything I wanted the way it should look.

But everything changed once I worked in a team. Once we combined everyone's code, I started to see that there's many things I don't personally like. Of course everyone has their own styles and that's not a problem at all. But when you see a different type of styles are combined, it makes the code looks ugly and unprofessional (although I my self am still an amateur hehe).

I realize that this should not happen. The reason is becuase we want to avoid confusion among team members. Ideally, every team member should follow the guidelines so that it will make understanding code easier.

Previously I mentioned that everyone's style should not be a problem. That is true in case you are working on your own. But if you are working for your company, this could be a problem. Generally, we want to organize the code as perfect as we could. This not only will help your team members, but also new members in the future.

To solve this problem, I have read tons of articles about setting up development workflow. As a result, I found some tools that could help you and your team to write a better code by enforcing you to follow certain rules that you and your team decide prior.

1. Prettier

Prettier is a code formatter that enforces you to follow a set of rules regarding your code format. Generally, this tool should help you make your code look consistent.

2. Eslint

ESLint is the most popular JavaScript linter, a tool that analyzes code for errors, which can include stylistic errors but also coding errors that lead to bugs. Although this tool can also check code format, most people only use this to look for error regarding code logic.

3. Husky

You can think of husky as a quality assurance for your code before shipped into remote repository. It will guarantee that your code adheres all rules set in prettier and eslint. It won't let you push your code if you have errors in your code.

4. lint-staged

In addition to husky, lint-staged is a little helper with big capabilities to keep track on code you changed. Thus making the checking process faster.

With those tools setup, I'm pretty confident that your repository will look like so much better in terms of structure and logic.

Of course, those who never bothered with this tools would find this annoying at first because they are forced to follow so many rules and sometimes come accross errors that should not happen at all without all those rules and slow down their work instead. But eventually, they will be grateful and appreciate the importance of the beauty of code quality.