Adeus, código limpo (2020)

Despedida da organização do código

• Um colega fez o check-in, tarde da noite, do código que havia escrito ao longo de toda a semana.
• Implementação de um recurso para ajustar o tamanho de formas na tela de um editor gráfico.
• O código funcionava, mas era repetitivo.

Na manhã seguinte...

• O chefe pediu uma conversa em particular e solicitou que as mudanças no código fossem revertidas.
• No começo foi um choque, mas no fim percebeu que a decisão do chefe estava certa.

Fase

• Ficar obcecado por "código limpo" e remoção de duplicação é uma fase pela qual muitos desenvolvedores passam.
• Quando você não tem confiança no seu código, é tentador vincular sua autoestima e seu orgulho profissional a coisas mensuráveis.
• Depois de aprender abstração, você passa a querer usá-la sempre que vê código repetido.

Opinião do GN⁺

• O importante é que buscar a "limpeza" do código não é o objetivo em si, mas um tipo de mecanismo de defesa no processo de lidar com sistemas complexos.
• O "código limpo" ajuda desenvolvedores a atuar como guia em territórios desconhecidos, mas é preciso saber não se apegar apenas a isso e conseguir deixá-lo ir.
• Este texto oferece uma perspectiva interessante para lembrar aos desenvolvedores da importância da colaboração e da praticidade no processo de escrever e manter código.

[GN⁺]

Comentários no Hacker News

• "Clean Code" precisa de um reposicionamento de marca

  • O objetivo de clean code é tornar o código mais simples e fácil de manter
  • O valor do software está na sua capacidade de mudar ao longo do tempo
  • Se a refatoração tornou a manutenção mais difícil, então isso não é clean code
  • Não discutir a refatoração com o desenvolvedor original é uma questão separada de clean code

• Às vezes duplicação de código pode ser boa, mas isso não é prova de que clean code é ruim

  • Se 10 linhas de cálculo matemático repetido foram substituídas por uma função, isso pode deixar o código mais limpo
  • É preciso revisar o PR e rejeitá-lo se não atender aos critérios
  • Ignorar a importância de clean code acaba levando a uma base de código em que ninguém quer trabalhar
  • A lição é que são necessárias melhor comunicação e moderação

• Um colega escreveu muito código com copiar e colar

  • A refatoração deve ser enviada para revisão
  • Um chefe intervir diretamente e mandar reverter é um mau sinal
  • A lição não é que copiar e colar seja melhor do que escrever uma função

• É bem provável que a versão clean code tenha substituído um código sujo

  • É preciso uma lição sobre como trabalhar em equipe

• Revisão por colegas é necessária ao alterar código

  • É preciso reconhecer a falta de um bom processo
  • Refatoração de código só deve ser feita quando necessário

• No setor financeiro, é comum lidar com produtos parecidos, mas diferentes

  • É importante evitar abstração excessiva e manter o código limpo

• Linguagens como Haskell maximizam a abstração no nível da linguagem

  • Ao mesmo tempo em que minimizam abstrações específicas do projeto, têm alto custo de aprendizado

• Mover cálculos matemáticos repetidos para uma função separada se encaixa em clean code

  • Refatorar funções de redimensionamento que parecem formar uma interface é um erro

• Explicação sobre abstrações ruins

  • O problema é projetar sem considerar suficientemente o uso futuro

• Rob Pike disse: "um pouco de cópia é melhor do que um pouco de dependência"

  • O princípio DRY às vezes adiciona abstração, mas se a abstração não for suficientemente ortogonal, ela acaba piorando o problema