Headhunter es una empresa de productos, la calidad del código es muy importante para nosotros. Cuanto mejor sea, más rápido podremos lanzar nuevas funciones comerciales y más a menudo complacerán a los usuarios.
Para cada solicitud de extracción, debe aprobar una revisión, incluso si solo se cambia una línea. Al menos una persona necesita una evaluación, la revisión está abierta, cualquiera puede participar, y esto es bienvenido. Es necesaria una revisión para mejorar la calidad del código y difundir el conocimiento entre los diferentes equipos.
Anteriormente, la revisión tenía un debate constante sobre cómo y qué escribir correctamente. Tomó mucho tiempo y esfuerzo. Para resolver estos problemas, se escribió una Guía de estilo. Ayudó mucho, ya que apareció una fuente de verdad, a la que siempre se puede referir. La Guía de estilo también ayuda a los principiantes a ingresar al proyecto, explicando de inmediato qué y cómo escribir, y qué esperar en una revisión.
Sin embargo, había un gran problema con la Guía de estilo: la gente a menudo se olvidaba de él, tenía que volver a leerlo constantemente y vincularlo a la solicitud de extracción para demostrar que tenía razón. Como resultado, la revisión a veces se deslizó en disputas sesgadas, algo como esto resultó:
Usted mismo comprende cuánto desmotiva al desarrollador y cuánto tiempo se dedica a disputas inútiles en la revisión. Como resultado, la gente no quería revisar y revisar otros desarrolladores.
Para que el jefe del autor del código y el revisor estén menos ocupados con preguntas sobre cómo colocar comas y en qué orden escribir las reglas para el border decidimos implementar la automatización, en ese momento era jshint , se volvió mucho mejor. Después de cambiar a eslint debido a una serie de ventajas:
- El es mas flexible
- Hay todo tipo de complementos para ello.
- Diferentes compañías tienen buenas configuraciones listas para usar
Durante mucho tiempo, heredamos de la airbnb , pero no todo nos convenía, tuvimos que redefinir algunas reglas. No fue muy conveniente, como resultado escribimos nuestra configuración basada en airbnb. También agregamos ganchos de precompromiso, en ese momento utilizamos husky . Si el desarrollador escribió algo mal, se enteró de inmediato cuando intentó enviar sus cambios a github.
Pero desafortunadamente, eslint no cubrió todos los aspectos del formato de código, se agregó más bonito para resolver este problema.
Afortunadamente, eslint y prettier funcionan bien juntos, solo necesita poner eslint-plugin-prettier y eslint-config-prettier y luego arreglar .eslintrc esta manera:
... "plugins": ["prettier"], "extends": ["@hh.ru/eslint-config", "prettier"], "rules": { "prettier/prettier": ["error"], ...
Antes de lanzar todo esto al producto, era necesario revisar toda la base del código y corregirlo para cumplir con las nuevas reglas, resultó que no fue nada difícil: yarn eslint --fix <path_to_js>
Después de eso, la mayor parte del debate sobre cómo escribir y formatear el código desapareció, ya que todo está cubierto por la automatización. Total ahora tenemos:
- Todos los js y jsx se verifican y se arreglan automáticamente usando eslint y más bonito.
- Por menos, se usa stylelint .
- Para escamas de pitón 8.
Los archivos modificados se verifican en la máquina del desarrollador cuando se comprometen, usando lint-staged , aquí está nuestro .lintstagedrc :
{ "*.{js,jsx}": ["eslint --fix", "git add"], "*.less": "stylelint", "*.py": "flake8", "package.json": "bash -c 'yarn check-versions && yarn install --frozen-lockfile'", }
Un código que ya pasó el linting y las pruebas entra en el github; el revisor ya no necesita pensar en esto y prestar atención a las pequeñas cosas. Puede concentrarse por completo en qué tan bien está escrito el código, si habrá algún problema de rendimiento, y pensar en la arquitectura.
Después de la revisión, se ensambla el contenedor acoplable, durante el ensamblaje se ejecutan todas las pruebas automáticas y linters. Ahora todo el proceso de ensamblaje demora aproximadamente 7.5 minutos, mientras que ahora tenemos aproximadamente 1000 js y 650 archivos menos. Todo esto es necesario, ya que localmente en la máquina puede omitir usando --no-verify verify, y los comentarios en el github no bloquean la tarea. Engañar a la asamblea no funciona.
Después de pasar las pruebas automáticas, comienza la prueba manual. Si el probador no encuentra un solo error, la tarea pasa a pinchar.
Si se produce un error en cualquier etapa, la tarea vuelve para su revisión.
El resultado fue:
- Es más fácil y rápido escribir código.
- Más fácil de hacer una revisión.
- El asistente siempre tiene un código de calidad.
- Menos controversia, más felicidad
Monitoreamos la calidad del código durante la ejecución de las tareas comerciales, pero el producto está en constante evolución, aparecen condiciones adicionales en el código y aumenta la complejidad. También aparecen nuevas tecnologías, las antiguas mueren por todo esto, aparece un impuesto técnico. Como parte del impuesto, nos dedicamos a:
- Optimización de página personalizada
- Cambio de infraestructura
- Mejora de la base de código
Todos los equipos de productos deberían dedicar el 70% de su tiempo a desarrollar tareas comerciales y el 30% a impuestos; esto le da a cada desarrollador la oportunidad de participar en tareas de infraestructura, mantener la base del código en excelentes condiciones y difundir el conocimiento sobre la infraestructura del proyecto en todos los equipos. Como impuesto, no es necesario realizar las tareas de su equipo; puede escribir código en cualquier parte del proyecto. Cualquiera puede sugerir un impuesto, si parece útil, se agregará a la cartera de pedidos. Además, hay equipos de arquitectura que se ocupan de las características tecnológicas todo el tiempo. Todo esto le permite mantener actualizada la base del código.