Quality frontend code in HH

Headhunter is a grocery company, the quality of the code is very important to us. The better it is, the faster we can release new business features and more often please users.

For each pull request, you must pass a review, even if only one line is changed. It is necessary to have at least one person review at the same time open, anyone can participate, and this is welcome. A review is needed to improve the quality of the code and spread knowledge among various teams.

Previously, there were constant debates on how to write correctly. It took a lot of time and effort. To solve these problems Style Guide was written. He helped a lot, as there was a source of truth, which you can always refer to. Also Style Guide helps newcomers to enter the project, immediately explaining what and how to write, as well as what to expect in the review.

Nevertheless, there was a big problem with the Style Guide - people often forgot about it, it was necessary to constantly re-read it and link it to the pull request to prove that it was right. As a result, the review sometimes slipped into biased disputes, it turned out something like this:

You understand how much it demotivates the developer, and how much time is spent on useless disputes in the review. As a result, people did not want to go through the review and revision of other developers.

To make the head of the author of the code and the reviewer less busy with the questions of how to place commas correctly and in what order to write the rules for the border we decided to implement automation, at that time it was jshint , it became much better. After switching to eslint due to several advantages:

• He is more flexible
• Under it there are all sorts of plugins
• Different companies have good ready configs.

For a long time, we inherited from the airbnb , but we were not satisfied with everything in it, we had to redefine some rules. It was not very convenient, as a result we wrote our config based on airbnb-shnogo. We also added prekomit hooks, at that time we used husky . If the developer wrote something wrong, he immediately recognized it when he tried to commit his changes to github.

But to our regret, eslint did not cover all aspects of code formatting, a prettier was added to solve this problem.

The benefit of eslint and prettier work well together, you just need to put eslint-plugin-prettier and eslint-config-prettier and then fix the .eslintrc like this:

 ... "plugins": ["prettier"], "extends": ["@hh.ru/eslint-config", "prettier"], "rules": { "prettier/prettier": ["error"], ... 

Before releasing all this to the prod, it was necessary to go through the whole code base and fix it to conform to the new rules, it turned out to be not difficult at all: yarn eslint --fix <path_to_js>

After that, most of the controversy about how to write and format the code was gone, since everything is covered by automation. Total now we have:

• All js and jsx are checked and autofixed with eslint and prettier.
• For less, stylelint is used.
• For python flake8.

Modified files are checked on the developer’s machine at a commit, with lint-staged , here’s our .lintstagedrc :

 { "*.{js,jsx}": ["eslint --fix", "git add"], "*.less": "stylelint", "*.py": "flake8", "package.json": "bash -c 'yarn check-versions && yarn install --frozen-lockfile'", } 

The code that has already passed the linting and tests gets into the githab, the reviewer no longer needs to think about it and pay attention to the little things. You can fully focus on how well the code is written, whether there will be any performance problems, think about the architecture.

After the review, the docker container is assembled, during the assembly all autotests and linters are run. Now the whole build process takes about 7.5 minutes, despite the fact that we now have about 1000 js and 650 less files. All this is necessary, since you can skip locally on the machine using --no-verify , and comments in the githabe do not block the task. To deceive the assembly does not work.

After passing the auto tests begins manual testing. If the tester does not find any bugs, the task goes to the prod.

If an error occurs at any of the stages, the task is returned for revision.

As a result, it became:

• Easier and faster to write code
• Easier to make a review
• In the master always quality code
• Less controversy, more happiness

We monitor the quality of the code during the execution of business tasks, but the product is constantly evolving, additional conditions appear in the code, the complexity increases. New technologies are also emerging, old ones are dying due to all this technical tax. As part of the tax we deal with:

• Custom page optimization
• Infrastructure changes
• Improving the code base

All product teams have to spend 70% of their time on developing business tasks, and 30% on tax — this gives each developer the opportunity to tackle infrastructure tasks, maintain the code base in excellent condition, and spread knowledge about the project infrastructure to all teams. As a tax, it is not necessary to do the tasks of your team; you can write code to any part of the project. Anyone can offer a tax, if it seems useful, then it will be added to the backlog. In addition, there are architectural teams that are engaged in technological features all the time. All this allows you to keep the code base up to date.