Headhunter est une entreprise de produits, la qualité du code est très importante pour nous. Mieux c'est, plus vite nous pouvons publier de nouvelles fonctionnalités métier et plus souvent plaire aux utilisateurs.
Pour chaque demande d'extraction, vous devez passer un examen, même si une seule ligne est modifiée. Au moins une personne a besoin d'une évaluation, l'examen est ouvert, tout le monde peut participer, et c'est le bienvenu. Une revue est nécessaire pour améliorer la qualité du code et diffuser les connaissances entre les différentes équipes.
Auparavant, la revue avait un débat constant sur comment et quoi écrire correctement. Cela a pris beaucoup de temps et d'efforts. Pour résoudre ces problèmes, un guide de style a été rédigé. Il a beaucoup aidé, car une source de vérité est apparue, à laquelle on peut toujours se référer. Le guide de style aide également les débutants à entrer dans le projet, expliquant immédiatement quoi et comment écrire, et à quoi s'attendre dans une critique.
Néanmoins, il y avait un gros problème avec le Guide de style - les gens l'oubliaient souvent, il devait constamment relire et lier à la demande de pull pour prouver qu'il avait raison. En conséquence, l'examen s'est parfois glissé dans des différends biaisés, quelque chose comme ceci s'est avéré:
Vous comprenez vous-même combien cela démotive le développeur et combien de temps est consacré aux litiges inutiles dans la revue. En conséquence, les gens ne voulaient pas examiner et examiner d'autres développeurs.
Pour rendre le responsable de l'auteur du code et le réviseur moins occupés avec des questions sur la façon de placer des virgules et dans quel ordre pour écrire les règles de border nous avons décidé d'implémenter l'automatisation, à l'époque c'était jshint , c'est devenu beaucoup mieux. Après être passé à eslint en raison d'un certain nombre d'avantages:
- Il est plus flexible
- Il existe toutes sortes de plugins pour cela.
- Différentes entreprises ont de bonnes configurations prêtes à l'emploi
Pendant longtemps, nous avons hérité de la airbnb , mais tout ne nous convenait pas, nous avons dû redéfinir certaines règles. Ce n'était pas très pratique, en conséquence, nous avons écrit notre configuration basée sur airbnb. Nous avons également ajouté des crochets de pré-engagement, à cette époque, nous utilisions du husky . Si le développeur a écrit quelque chose de mal, il l'a immédiatement découvert en essayant de valider ses modifications sur github.
Mais malheureusement, eslint ne couvrait pas tous les aspects de la mise en forme du code, plus jolie a été ajoutée pour résoudre ce problème.
Heureusement, eslint et prettier fonctionnent bien ensemble, il vous suffit de mettre eslint-plugin- prettier et eslint-config- .eslintrc puis de corriger .eslintrc comme ceci:
... "plugins": ["prettier"], "extends": ["@hh.ru/eslint-config", "prettier"], "rules": { "prettier/prettier": ["error"], ...
Avant de divulguer tout cela à la prod, il fallait parcourir toute la base de code et la corriger pour se conformer aux nouvelles règles, ce ne fut pas du tout difficile: yarn eslint --fix <path_to_js>
Après cela, la plupart du débat sur la façon d'écrire et de formater le code a disparu, car tout est couvert par l'automatisation. Total, nous avons maintenant:
- Tous les js et jsx sont vérifiés et corrigés automatiquement en utilisant eslint et plus joli.
- Pour moins, stylelint est utilisé.
- Pour python flake8.
Les fichiers modifiés sont vérifiés sur la machine du développeur lors de la validation, en utilisant lint- .lintstagedrc , voici notre .lintstagedrc :
{ "*.{js,jsx}": ["eslint --fix", "git add"], "*.less": "stylelint", "*.py": "flake8", "package.json": "bash -c 'yarn check-versions && yarn install --frozen-lockfile'", }
Un code qui a déjà passé les peluches et les tests entre dans le github; le réviseur n'a plus besoin d'y penser et de faire attention aux petites choses. Vous pouvez vous concentrer entièrement sur la qualité de l'écriture du code, s'il y aura des problèmes de performances, et penser à l'architecture.
Après l'examen, le conteneur docker est assemblé, pendant l'assemblage, tous les autotests et les linters sont exécutés. Maintenant, l'ensemble du processus d'assemblage prend environ 7,5 minutes, alors que nous avons maintenant environ 1000 js et 650 fichiers de moins. Tout cela est nécessaire, car localement sur la machine, vous pouvez ignorer en utilisant --no-verify , et les commentaires dans le github ne bloquent pas la tâche. Tromper l'assemblage ne fonctionne pas.
Après avoir réussi les autotests, le test manuel commence. Si le testeur ne trouve pas un seul bug, la tâche passe à prod.
Si une erreur se produit à un stade quelconque, la tâche retourne pour révision.
Le résultat a été:
- Il est plus facile et plus rapide d'écrire du code.
- Faire un examen plus facilement
- L'assistant a toujours un code de qualité
- Moins de controverse, plus de bonheur
Nous surveillons la qualité du code lors de l'exécution des tâches métier, mais le produit évolue constamment, des conditions supplémentaires apparaissent dans le code, la complexité augmente. De nouvelles technologies apparaissent également, les anciennes meurent à cause de tout cela, une taxe technique apparaît. Dans le cadre de la taxe, nous nous engageons à:
- Optimisation de page personnalisée
- Changement d'infrastructure
- Amélioration de la base de code
Toutes les équipes de produits devraient consacrer 70% de leur temps au développement de tâches commerciales et 30% à la fiscalité - cela donne à chaque développeur la possibilité de s'engager dans des tâches d'infrastructure, de maintenir la base de code en excellent état et de diffuser les connaissances sur l'infrastructure du projet à travers toutes les équipes. En tant que taxe, il n'est pas nécessaire de faire les tâches de votre équipe; vous pouvez écrire du code dans n'importe quelle partie du projet. N'importe qui peut proposer une taxe, si cela semble utile, elle sera ajoutée à l'arriéré. De plus, il existe des équipes d'architectes qui traitent constamment des caractéristiques technologiques. Tout cela vous permet de maintenir la base de code à jour.