Aceite Tudo, Não Entenda Nada

Pressionar enter para aceitar sugestões de código exige menos esforço do que rolar a tela para passar por elas. Um único toque na tecla torna o código seu. Ler e entender esse código não ficou mais rápido.

Existe um abismo entre a velocidade com que você aceita o código e a velocidade com que o entende. É nesse abismo que os erros acontecem.

A dívida técnica costumava ter causas claras. Você tinha prazos apertados ou tomava atalhos. Você conseguia apontar o motivo. Agora, você acumula dívida em uma terça-feira tranquila. Você aceita seis sugestões seguidas porque elas parecem estar certas. Ninguém te apressou, mas o código permanece sem ser examinado.

Brian Kernighan disse em 1974 que depurar é duas vezes mais difícil do que escrever um programa. Ele estava falando sobre o código que os humanos escrevem. Pelo menos os humanos entendem o próprio trabalho.

Hoje, uma sugestão pode passar pelo linter e até passar nos testes. Ela ainda pode se basear em uma premissa errada. Isso acontece porque as pessoas leem a sugestão como uma saída, e não como código. Uma saída que parece boa é aprovada.

Se um modelo escreve tanto o código quanto os testes, você está corrigindo o dever de casa com as próprias respostas do aluno. Isso não lhe diz se a lógica é sólida. Não lhe diz se os casos de borda foram cobertos. É fácil esquecer disso quando o código aparece no seu próprio editor e no seu próprio estilo.

Isso cria problemas reais:

  • Você depura um código que nunca leu. Quando algo quebra semanas depois, você começa do zero.
  • Casos de borda falham. Uma sugestão lida bem com o caminho feliz. Ela inclui uma verificação de nulo. Mas ela ignora a lógica específica que o seu negócio precisa.
  • Você não consegue defender seus próprios pull requests. Se um revisor perguntar por que você escolheu um método, você não terá resposta. Você não tomou a decisão. Você apenas não a rejeitou.

Essas ferramentas são úteis. Elas ajudam a explorar bases de código ou planejar novos recursos. O problema é a sua postura. Você deve tratar cada sugestão como algo para ler e decidir, não apenas algo para dar uma olhada rápida.

Para boilerplate ou scripts rápidos, a velocidade é aceitável. Para lógica de negócio ou segurança, sua abordagem deve mudar. Leia o código como se você fosse ser o dono dele. Porque você será.

Em vez disso, faça o seguinte:

  • Discuta sua solução com o modelo antes de pedir o código.
  • Revise o diff como se você mesmo o tivesse escrito.
  • Peça para a ferramenta explicar o raciocínio dela antes de aceitar o código.
  • Trate as sugestões como o trabalho de um desenvolvedor júnior. É útil, mas não é a verdade absoluta.
  • Diminua o ritmo em linhas que te surpreendam. A surpresa é um sinal.

O toque na tecla ficou mais barato. Sua responsabilidade, não. Velocidade sem compreensão é apenas dívida rápida.

Source: https://dev.to/cloudx/accept-all-understand-none-4dob

Optional learning community: https://t.me/GyaanSetuAi