Headhunter ist ein Produktunternehmen, die Qualität des Codes ist uns sehr wichtig. Je besser es ist, desto schneller können wir neue Geschäftsfunktionen veröffentlichen und desto häufiger gefallen die Benutzer.
Für jede Pull-Anforderung müssen Sie eine Überprüfung bestehen, auch wenn nur eine Zeile geändert wird. Mindestens eine Person benötigt eine Bewertung, die Überprüfung ist offen, jeder kann teilnehmen, und dies ist willkommen. Eine Überprüfung ist erforderlich, um die Qualität des Codes zu verbessern und Wissen zwischen verschiedenen Teams zu verbreiten.
Zuvor hatte die Überprüfung ständige Debatten darüber, wie und was richtig zu schreiben ist. Es hat viel Zeit und Mühe gekostet. Um diese Probleme zu lösen, wurde ein Style Guide geschrieben. Er hat sehr geholfen, als eine Quelle der Wahrheit auftauchte, auf die immer Bezug genommen werden kann. Der Style Guide hilft auch Anfängern beim Einstieg in das Projekt und erklärt sofort, was und wie zu schreiben ist und was in einer Rezension zu erwarten ist.
Trotzdem gab es ein großes Problem mit dem Style Guide - die Leute vergaßen ihn oft, er musste ihn ständig neu lesen und mit der Pull-Anfrage verknüpfen, um zu beweisen, dass er Recht hatte. Infolgedessen geriet die Überprüfung manchmal in voreingenommene Streitigkeiten, so etwas stellte sich heraus:
Sie selbst verstehen, wie sehr dies den Entwickler motiviert und wie viel Zeit für nutzlose Streitigkeiten in der Überprüfung aufgewendet wird. Infolgedessen wollten die Leute andere Entwickler nicht überprüfen und überprüfen.
Um den Kopf des Autors des Codes und den Prüfer weniger mit Fragen zu beschäftigen, wie Kommas gesetzt werden sollen und in welcher Reihenfolge die Regeln für den border wir beschlossen, die Automatisierung zu implementieren. Damals war es jshint , es wurde viel besser. Nach dem Wechsel zu eslint wegen einer Reihe von Vorteilen:
- Er ist flexibler
- Es gibt alle Arten von Plugins dafür.
- Verschiedene Unternehmen haben gute vorgefertigte Konfigurationen
Lange Zeit haben wir von der airbnb geerbt, aber nicht alles passte zu uns, wir mussten einige Regeln neu definieren. Es war nicht sehr praktisch, daher haben wir unsere Konfiguration basierend auf Airbnb geschrieben. Wir haben auch Pre-Commit-Haken hinzugefügt, zu dieser Zeit haben wir Husky verwendet . Wenn der Entwickler etwas falsch geschrieben hat, hat er es sofort herausgefunden, als er versucht hat, seine Änderungen an Github zu übergeben.
Leider deckte eslint nicht alle Aspekte der Code-Formatierung ab. Zur Lösung dieses Problems wurde eine schönere Version hinzugefügt.
Glücklicherweise arbeiten eslint und prettier gut zusammen. Sie müssen nur eslint-plugin- prettier und eslint-config-prettier setzen und dann .eslintrc wie .eslintrc reparieren:
... "plugins": ["prettier"], "extends": ["@hh.ru/eslint-config", "prettier"], "rules": { "prettier/prettier": ["error"], ...
Bevor all dies für das yarn eslint --fix <path_to_js> die gesamte Codebasis durchgesehen und korrigiert werden, um den neuen Regeln zu entsprechen. Es stellte sich heraus, dass dies überhaupt nicht schwierig war: yarn eslint --fix <path_to_js>
Danach verschwand der größte Teil der Debatte über das Schreiben und Formatieren des Codes, da alles durch Automatisierung abgedeckt ist. Insgesamt haben wir jetzt:
- Alle js und jsx werden mit eslint und prettier überprüft und automatisch repariert.
- Für weniger wird Stylelint verwendet.
- Für Python Flake8.
Geänderte Dateien werden auf dem Computer des Entwicklers beim .lintstagedrc mit lint-staged überprüft. Hier ist unsere .lintstagedrc :
{ "*.{js,jsx}": ["eslint --fix", "git add"], "*.less": "stylelint", "*.py": "flake8", "package.json": "bash -c 'yarn check-versions && yarn install --frozen-lockfile'", }
Ein Code, der bereits Flusen und Tests bestanden hat, gelangt in den Github. Der Prüfer muss nicht mehr darüber nachdenken und auf die kleinen Dinge achten. Sie können sich ganz darauf konzentrieren, wie gut der Code geschrieben ist, wenn Leistungsprobleme auftreten, und über die Architektur nachdenken.
Nach der Überprüfung wird der Docker-Container zusammengebaut. Während der Zusammenstellung werden alle Autotests und Linters ausgeführt. Jetzt dauert der gesamte Montageprozess ungefähr 7,5 Minuten, während wir jetzt ungefähr 1000 js und 650 weniger Dateien haben. All dies ist notwendig, da Sie lokal auf dem Computer mit --no-verify überspringen können und Kommentare im Github die Aufgabe nicht blockieren. Täuschen Sie, dass die Baugruppe nicht funktioniert.
Nach dem Bestehen der Autotests beginnt der manuelle Test. Wenn der Tester keinen einzigen Fehler findet, geht die Aufgabe zu prod.
Wenn zu irgendeinem Zeitpunkt ein Fehler auftritt, wird die Aufgabe zur Überarbeitung zurückgegeben.
Das Ergebnis war:
- Es ist einfacher und schneller, Code zu schreiben.
- Einfachere Überprüfung
- Der Assistent hat immer einen Qualitätscode
- Weniger Kontroversen, mehr Glück
Wir überwachen die Qualität des Codes während der Ausführung von Geschäftsaufgaben, aber das Produkt entwickelt sich ständig weiter, zusätzliche Bedingungen erscheinen im Code, die Komplexität nimmt zu. Es erscheinen auch neue Technologien, alte sterben ab, eine technische Steuer entsteht. Im Rahmen der Steuer beschäftigen wir uns mit:
- Benutzerdefinierte Seitenoptimierung
- Infrastrukturänderung
- Verbesserung der Codebasis
Alle Produktteams sollten 70% ihrer Zeit für die Entwicklung von Geschäftsaufgaben und 30% für Steuern aufwenden. Dies gibt jedem Entwickler die Möglichkeit, sich an Infrastrukturaufgaben zu beteiligen, die Codebasis in ausgezeichnetem Zustand zu halten und Wissen über die Projektinfrastruktur in allen Teams zu verbreiten. Als Steuer ist es nicht erforderlich, die Aufgaben Ihres Teams zu erledigen. Sie können Code in jeden Teil des Projekts schreiben. Jeder kann eine Steuer vorschlagen, wenn sie nützlich erscheint, wird sie dem Rückstand hinzugefügt. Darüber hinaus gibt es Architektenteams, die sich ständig mit technologischen Merkmalen befassen. All dies ermöglicht es Ihnen, die Codebasis auf dem neuesten Stand zu halten.