We tell how front-end developer Dmitry Balaev @manmo and I remove Legacy, what Open Source configurations we use for ESLint, and how the static code analyzer influenced the development of our company’s developers.
What is Legacy and where does it come from
Legacy code is heavily maintained, low-quality or outdated code that is impossible to understand (or possible, but for a very long time). Often, Legacy means the code that the team receives as a “legacy” from previous developers. But not everything is so simple: the code that [хорошие] development teams are handed over to the customer, Legacy cannot be named, because such code can be quickly and easily figured out.
The main reasons for Legacy:
In the life of any developer, there comes a moment of collision with the “mammoth”. We were working on a project where the code was written back in 2000. Then about any ES6 it was impossible even to dream. For 20 years, hundreds of developers have changed to support that project. Each of them wrote in a way that was convenient for him, using his own methodology and convenient technologies. Due to such situations, a unified style of writing code is not obtained, but crutches in the JS code, incorrectly used variables in CSS, and much more are obtained.
This reason follows from the previous one. On finished projects, Legacy is almost inevitable, but it can also occur when creating completely new products – more on that in the next paragraph.
To work on a new project, as a rule, a team is assembled from free resources. These can be developers of different grades – from Junior to Senior, who have previously worked with other stacks and other requirements. If a good team leader didn’t take on a new project from the very beginning and didn’t build suitable requirements, the code will again turn out without a single style with all the ensuing consequences.
Clear instructions do not negate the human factor, so even very strong teams need a Code review. There is no Code review – there is Legacy and constant picking in Pull Requests. You need to remember the style of each project, and for developers it’s hard. Code review should solve this problem.
Ideally, you need to get rid of Legacy, do refactoring, bring the code to a uniform readable form. For an old 20-year-old project, this is very labor intensive, since changing a small piece of code can lead to the collapse of the entire project, and sometimes it is easier and more expedient to rewrite it from scratch. But for a new project, in which signs of Legacy have just begun to appear, the situation can be corrected – to build work under the guidance of an experienced team leader and write clear requirements for developers.
How to remove Legacy
There are a number of tools that will help you refactor and “fit” the code to the same standards. In this article, we will look at a few static code analyzers (hereinafter referred to as SCA) – they analyze the program code without actually executing it.
We use ESLint on all our projects, as it is an evolution of previous linters. I’ll tell you how we set it up and share the results of implementation.
How to set up ESLint
When creating projects on modern frameworks, the analyzer can already be built in with the initial settings. For example, when initializing a new project on Nuxt, the system suggests installing ESLint:
To install ESLint into an existing project, add it via npm “npm install eslint –save-dev” and create a configuration file “.eslintrc”. For instant highlighting of errors, you can configure the code editor. Additional plugins are also installed via npm.
On the network you can find many Open Source configurations for ESLint. These are regular node.js packages with the “eslint-config-” prefix, which contain only the ESLint configuration from a specific company/team/developer. For example, you can easily use ready-made configurations from Google or Airbnb.
Sometimes you may want to disable rules in a specific location or file. This can be done in several ways:
/* eslint-disable */ console.log(‘test’); /* eslint-enable */
console.log(‘test’); // eslint-disable-line
You can also disable specific rules:
/* eslint-disable no-console */ console.log(‘test’); /* eslint-enable no-console */
console.log(‘test’); // eslint-disable-line no-console
// eslint-disable-next-line no-console console.log(‘test’);
Not all developers agree with the implementation of ESLint, as they are used to writing code in their own way and do not want to rebuild. There were times when some developers simply ignored the rules, made a pull with errors. In this case, the library can help pre-commit, which does not allow you to commit if there are errors. But this can lead to someone turning off certain settings or ESLint itself. In this case, only proper control and Code review on the project will help.
When maintaining a project with ESLint already configured, these rules must be followed. You don’t need to disable or change anything. As they say, “they don’t climb into someone else’s garden with their shovel,” even if someone else’s config is not familiar to us.
What is the result
To completely get rid of Legacy, you need to spend a lot of time on painstaking manual work. ESLint itself will not be able to do this, but it’s quite possible to help in this and facilitate hard work.
Here is how our company was affected by the implementation of ESLint:
We save time on project support by about 30%.
Faster and easier training of new employees/trainees/juniors. They immediately see how to write cleaner code.
We are improving the code: it becomes cleaner in terms of the number of libraries, because it’s not too lazy to write your own custom code and transfer developments from past projects.
We eliminate obvious, banal errors, which sometimes take time to find, for example, writing to a previously created variable or a missing character.
We free up time to check our code. Now the developers devote their freed hours to better layout layout, creative animation, and so on. This allows you to get more cool projects.