Headhunter é uma empresa de produtos, a qualidade do código é muito importante para nós. Quanto melhor, mais rápido podemos lançar novos recursos de negócios e agradar com mais frequência aos usuários.
Para cada solicitação de recebimento, você deve passar por uma revisão, mesmo que apenas uma linha seja alterada. Pelo menos uma pessoa precisa de uma avaliação, a revisão está aberta, qualquer pessoa pode participar, e isso é bem-vindo. É necessária uma revisão para melhorar a qualidade do código e disseminar o conhecimento entre as diferentes equipes.
Anteriormente, a revisão discutia constantemente sobre como e o que escrever corretamente. Demorou muito tempo e esforço. Para resolver esses problemas, um Guia de Estilo foi escrito. Ele ajudou muito, como uma fonte de verdade apareceu, a qual sempre pode ser referida. O Guia de Estilo também ajuda os iniciantes a entrar no projeto, explicando imediatamente o que e como escrever e o que esperar em uma revisão.
No entanto, havia um grande problema com o Guia de estilo - as pessoas frequentemente se esqueciam dele, ele precisava constantemente reler e vincular à solicitação de recebimento para provar que estava certo. Como resultado, a revisão às vezes entrava em disputas tendenciosas, algo assim:
Você mesmo entende o quanto isso desmotiva o desenvolvedor e quanto tempo é gasto em disputas inúteis na revisão. Como resultado, as pessoas não quiseram revisar e revisar outros desenvolvedores.
Para deixar o chefe do autor do código e o revisor menos ocupado com perguntas sobre como colocar vírgulas e em que ordem escrever as regras para border decidimos implementar a automação, na época era jshint , ficou muito melhor. Depois de mudar para eslint devido a várias vantagens:
- Ele é mais flexível
- Existem todos os tipos de plugins para isso.
- Diferentes empresas têm boas configurações prontas
Por um longo tempo, herdamos a airbnb do airbnb , mas nem tudo nos convinha, tivemos que redefinir algumas regras. Não foi muito conveniente, como resultado, escrevemos nossa configuração com base no airbnb. Também adicionamos ganchos de pré-autorização, na época usamos husky . Se o desenvolvedor escreveu algo errado, ele descobriu imediatamente quando tentou confirmar suas alterações no github.
Mas, infelizmente, o eslint não abrangeu todos os aspectos da formatação do código, foi adicionado mais bonito para resolver esse problema.
Felizmente, eslint e mais bonito funcionam bem juntos, você só precisa colocar eslint-plugin-prettier e eslint-config-prettier e, em seguida, corrigir o .eslintrc assim:
... "plugins": ["prettier"], "extends": ["@hh.ru/eslint-config", "prettier"], "rules": { "prettier/prettier": ["error"], ...
Antes de liberar tudo isso para o prod, era necessário percorrer toda a base de código e corrigi-lo para cumprir as novas regras, mas não foi nada difícil: yarn eslint --fix <path_to_js>
Depois disso, a maior parte do debate sobre como escrever e formatar o código desapareceu, pois tudo é coberto pela automação. Total agora temos:
- Todos os js e jsx são verificados e corrigidos automaticamente usando eslint e mais bonito.
- Por menos, stylelint é usado.
- Para python flake8.
Os arquivos modificados são verificados na máquina do desenvolvedor ao confirmar, usando o fiapo , aqui está o nosso .lintstagedrc :
{ "*.{js,jsx}": ["eslint --fix", "git add"], "*.less": "stylelint", "*.py": "flake8", "package.json": "bash -c 'yarn check-versions && yarn install --frozen-lockfile'", }
Um código que já passou no teste e no linting entra no github; o revisor não precisa mais pensar nisso e prestar atenção às pequenas coisas. Você pode se concentrar completamente em como o código está escrito, se houver algum problema de desempenho, e pensar na arquitetura.
Após a revisão, o contêiner do docker é montado, durante a montagem todos os autotestes e linters são executados. Agora, todo o processo de montagem leva cerca de 7,5 minutos, enquanto agora temos cerca de 1000 js e 650 arquivos a menos. Tudo isso é necessário, pois localmente na máquina você pode pular usando --no-verify , e os comentários no github não bloqueiam a tarefa. Enganar a montagem não funciona.
Depois de passar nos autotestes, o teste manual é iniciado. Se o testador não encontrar um único bug, a tarefa será executada.
Se ocorrer um erro em qualquer estágio, a tarefa retornará para revisão.
O resultado foi:
- É mais fácil e rápido escrever código.
- Mais fácil de fazer uma revisão
- O assistente sempre tem um código de qualidade
- Menos polêmica, mais felicidade
Monitoramos a qualidade do código durante a execução das tarefas de negócios, mas o produto está em constante evolução, condições adicionais aparecem no código e a complexidade aumenta. Novas tecnologias também aparecem, as antigas morrem por causa de tudo isso, um imposto técnico aparece. Como parte do imposto, estamos envolvidos em:
- Otimização de página personalizada
- Mudança de infraestrutura
- Melhoria na base de código
Todas as equipes de produto devem gastar 70% de seu tempo no desenvolvimento de tarefas de negócios e 30% em impostos - isso dá a cada desenvolvedor a oportunidade de se envolver em tarefas de infraestrutura, manter a base de códigos em excelentes condições e disseminar conhecimento sobre a infraestrutura do projeto em todas as equipes. Como imposto, não é necessário executar as tarefas da sua equipe; você pode escrever código em qualquer parte do projeto. Qualquer pessoa pode sugerir um imposto, se parecer útil, ele será adicionado ao backlog. Além disso, existem equipes de arquitetura que lidam com recursos tecnológicos o tempo todo. Tudo isso permite que você mantenha a base de código atualizada.