Executando verificação de segurança...
2

O Husky é uma ferramenta excelente!

Em uma empresa onde trabalhei, tentamos implementá-lo para executar testes automatizados antes de cada commit.

O resultado foi.... um caos rs

O problema não estava na ferramenta em si, mas sim no fluxo de trabalho da equipe e nas constantes demandas urgentes dos clientes. Essa urgência fez com que o Husky se tornasse um obstáculo para resolver problemas rapidamente, levando a equipe a abandoná-lo. Contudo, acredito que, com uma equipe focada em TDD (Desenvolvimento Orientado a Testes) e um cliente com necessidades mais claras, a ferramenta teria sido um sucesso.

Uma coisa que eu não faria seria integrar um pre-linter ao Husky, mesmo que fosse apenas nos arquivos staged. Isso porque existe o risco de ele corrigir formatações em partes do código que não foram modificadas. Essa situação pode gerar dor de cabeça durante o code review e também causar confusão ao revisar commits antigos. Por exemplo, alguém poderia pensar: 'O John Doe errou a lógica nesta parte do código', quando na verdade foi apenas um ajuste de formatação feito pelo linter. Isso pode gerar situações desagradáveis. Particularmente, acredito que o linter deve estar sempre configurado no pre-save de cada desenvolvedor, para que ele saiba imediatamente onde o código está sendo alterado, antes mesmo do commit.

Mas, no geral, com uma equipe preparada e determinada a seguir as melhores práticas, o Husky pode trazer muitos benefícios.

Parabéns pela postagem!

Carregando publicação patrocinada...
1

Muito obrigado por comentar, já tinha usado no meu antigo trabalho, mas deu problema quase pelo mesmo motivo, eu penso que é tudo questão de momento, as vezes o time não está em um momento que considere a importancia de uma ferramenta dessa, assim como a empresa as vezes não dá a liberdade para tal. No meu trabalho atual está ajudando bastante na parte de lint de código, o fluxo não fica tão punitivo e ajuda a manter o padrão.