Clean Code vs. Filosofia de Design de Software

• É uma conversa sobre design de software entre Robert “Uncle Bob” Martin e John Ousterhout, realizada de setembro de 2024 a fevereiro de 2025
• Ambos escreveram livros sobre design de software
• Mostraram diferenças de opinião em três temas principais: comprimento de métodos, comentários e Test-Driven Development
• O foco central da conversa é como reduzir a complexidade do código, melhorar a legibilidade e escrever testes de forma adequada

Comprimento de métodos

• Uncle Bob (doravante UB) enfatiza a posição de que “funções curtas são boas, e, se possível, devem ser divididas ainda mais”
  • Um método deve fazer apenas “uma coisa (One Thing)”
  • No entanto, se isso for aplicado de forma extrema, pode levar à decomposição excessiva (over-decomposition)
• John aponta que métodos pequenos demais podem, ao contrário, dificultar a compreensão do fluxo geral
  • Quando há muitos métodos “rasos (shallow)

[mhj5730]

Tenho vários livros da série Clean, mas acho que eles servem mais como referência em um nível metacognitivo. Quando você trata isso como princípio ou lei, fica extremamente cansativo e nada prático. É sempre o Uncle Bob falando dos princípios SOLID... pessoalmente, não acho que haja tanto conteúdo realmente prático assim.

[ahwjdekf]

Acho que Code Complete e Clean Code empatam em 1º lugar no ranking dos livros mais superestimados.

[carnoxen]

A tradução de Software Philosophy já saiu? Procurei, mas não consegui encontrar.

[mageia]

Ironicamente, parece que um livro irônico como "como programar de um jeito difícil de manter" seria mais fácil de absorver do que um livro que só fica dizendo o que seria um bom código.

[aer0700]

Acho que hoje em dia briguei mais por causa de gente que é fã de uma stack tecnológica ou arquitetura específica e fala como se fosse o fim do mundo não adotar essa stack ou arquitetura do que por causa de clean code. O certo é aplicar conforme a situação; parece que não existe nada que seja bom em qualquer caso.

[yadameda]

Ótima discussão.

[spilist2]

Pensando bem, eu também recomendava a Philosophy of Software Design, do John, para os juniores, mas nunca recomendei muito Clean Code.

[bbulbum]

Acho que o importante é não seguir cegamente apenas as manchetes sobre qualquer coisa, mas entender bem o contexto e aplicar isso adequadamente.

[savvykang]

Acho que livros de desenvolvimento pessoal voltados à programação são úteis para iniciantes que ainda não têm valores formados sobre tecnologia ou formas de implementação, mas, à medida que a experiência se acumula, sua utilidade diminui. Isso também porque não existe uma verdade absoluta que se encaixe em todos os projetos e ambientes, e há situações em que princípios gerais não se aplicam. Como acontece com conselhos de livros de desenvolvimento pessoal em outras áreas mais gerais, parece melhor manter certa distância, aplicar apenas as orientações adequadas a cada contexto e não perseguir esses conselhos cegamente.

[nicewook]

Concordo um pouco mais com o John.
Acho que o ponto principal é que, em vez de seguir cegamente o que os dois dizem como se fosse um dogma, devemos entender por que eles dizem isso e seguir em frente a partir daí.

[leojineoo]

Não podemos esquecer que código limpo não é o objetivo, mas um meio.

[ilikeall]

No fim das contas, moderação é essencial mesmo.

[elddytbt]

Muito útil 👍🏻

[GN⁺]

Opinião no Hacker News

• Algumas pessoas podem ser muito dogmáticas sobre certas coisas. Não consigo entender por que tratam isso como se fosse um evangelho

  • Já tive que lidar com gente que ficava brava toda vez que alguém passava do limite de 80 caracteres por linha
  • Essa tendência é ainda mais forte não só em estilos de programação, padrões e idiomatismos, mas também em stack tecnológica e arquitetura de soluções
  • Conversar com pessoas que apenas repetem o que leram em livros ou blogs é muito frustrante
  • Isso foi especialmente forte na febre de NoSQL e microsserviços, e ainda dá para sentir o mesmo em PaaS/SaaS e conteinerização
  • Apps, lambdas ou trabalhos de transformação que só executam funções básicas apenas aumentam a carga de manutenção e não agregam valor
  • A única diferença entre quem escreveu o livro ou blog e eu é que eles escreveram. É preciso sempre lembrar que a opinião deles não é fato

• Quando você passa por um projeto que segue cegamente as recomendações do Uncle Bob, percebe como o valor disso é baixo

  • Ele produziu alguns textos tentando melhorar a engenharia de software, mas estão cheios de conselhos terríveis
  • O sucesso dele vem da necessidade interminável de desenvolvedores juniores por guias
  • Código com muita indireção acaba se tornando difícil de trabalhar

• Clean Code é apenas uma das ferramentas na caixa de ferramentas de um bom engenheiro de software

• Algumas pessoas simplesmente agrupam linhas próximas e chamam isso de "refatoração", em vez de separar funções quando elas serão reutilizadas ou fazem sentido lógico

  • Quando li Clean Code na faculdade, senti bem o tom geral do Uncle Bob
  • Parece vir da mentalidade de que uma função deve ter X linhas
  • Sou grato aos recursos de inline dos IDEs modernos e reorganizo o código para conseguir entendê-lo

• Há um caso importante que não foi mencionado sobre a importância dos comentários

  • Ao escrever software de driver para dispositivo USB, é fácil colocar o dispositivo em um estado incorreto
  • Sempre que implemento uma solução alternativa, adiciono um comentário para documentá-la
  • Sem comentários, é difícil para outra pessoa entender a intenção do código

• Recomendo fortemente "A Philosophy of Software Design"

  • O ponto central é medir a qualidade da abstração pela proporção de complexidade
  • Depois de ler outros livros de conselhos sobre programação, meu código não melhorou

• Foi uma reação aos problemas reais da indústria de software antes do movimento Clean Code

  • Clean Code foi na direção certa, mas foi corrigido em excesso
  • Não sei se as pessoas vão voltar de novo a métodos gigantes e condicionais profundamente aninhadas

• A opinião do Bob sobre comentários é estranha

  • A paranoia com comentários incorretos é absurda
  • Já perdi muito tempo por causa de código pouco claro
  • Em vez de fazer diagramas esquisitos, seria mais fácil explicar brevemente o algoritmo ou fornecer um link

• Os livros do Uncle Bob são algo do qual você acaba se afastando com o tempo

  • Seguindo as diretrizes de Clean Code, aprendi sobre a "decomposição excessiva"
  • Funções pequenas acabam não fazendo nada
  • Se você quer escrever um bom código, precisa ler bom código e desenvolver um gosto próprio

• Há reclamações sobre o próprio nome Clean Code

  • Não dá para medir objetivamente a limpeza do código
  • O problema é o elemento inconsciente de que escrever "código limpo" parece obviamente algo bom
  • A base do "Uncle Bob" já era corrompida desde o início