O livro Clean Code é polêmico, mas acho que muito mais pela forma que consumimos do que pelo conteúdo. O cientificismo do livro e da engenharia de software, que faz o livro ser atraente e “perigoso” ao mesmo tempo.
Código limpo é uma ideia que não existe no vácuo, depende de quem vai mexer no código e do que está sendo feito. Esse livro é para programador profissional Java dos anos 2000, não faz sentido para quem quer automatizar uma planilha usando Python.
6 comentários
curiosidade
eu não li esse livro Clean Code, mas pelos comentários que vejo sobre ele, o que ele propõe é na verdade meio antigo
me lembra um livro bem antigo que eu li (antes da internet😁) e gostei muito na época, mais ou menos sobre os mesmos temas, de uma autor não muito conhecido chamado Larry Constantine
https://en.wikipedia.org/wiki/Larry_Constantine
curiosidade: além de trabalhar com software, também era conselheiro familiar 😁
Obrigado por postar seu texto. É sempre bacana ver gente da área propondo reflexões para além do pragmatismo puro. :)
Entendo o que você diz aí, mas parece que há uma confusão entre código fonte e arte, como se houvesse algum valor intrínseco no estilo de programar, tal como de fato ocorre na arte. Bastaria fazer uma analogia com a engenharia: não há valor algum em ter estilo no processo de construção de um prédio. O estilo nesse caso teria valor no resultado do prédio, tal como há estilo no resultado de um software (UI estilosas, por exemplo).
A ideia macro do Uncle Bob com o livro Clean Code é que, dado que passamos mais tempo lendo do que escrevendo código, então o processo de ler código deveria ser a coisa mais transparente e previsível possível, a ponto de beirar o tédio. Um código limpo seria como um texto jornalístico bem revisado, objetivo, coeso e fácil de ler.
É verdade que o livro dele não tem estudos revisados por pares para sustentar seus argumentos. E o nível de convicção que ele apresenta sobre alguns aspectos de fato pode incomodar, embora eu ache que cabe entender a proposta, e aqui e ali interpretar e adaptar algumas coisas (tal como fazemos com Agile, que curiosamente tem a mão do Uncle Bob também).
A questão do número máximo de parâmetros por função que você citou no texto é um bom exemplo disso. Temos que definir um limite, senão vai ter programador que vai declarar método com 15 parâmetros (sim, eu já vi isso) ou 30 ou 100 ou 487329473892678…
O Casey Muratori fez um vídeo no ano passado metendo o pau no conceito de clean code. O vídeo dele é uma pérola que soa mal, e é frágil em cada argumento. Eu cheguei a escrever algo rápido refutando, e no final acho que é resumo do que entendo do conceito macro de clean code. Se tiver curiosidade, aqui está: https://medium.com/@fulalas/clean-code-is-not-about-performance-642bcb55007b
Bom texto. Vejo muita gente pesando a mão nas críticas ao clean code, mas parecem esquecer que código escrito por mais de uma pessoa precisa de algumas regras para não fugir do controle
Em relação a valor, acho que não encaixa muito bem nem com pontes e nem com fotografia, porque se parte da premissa que a maiorias dos software precisam ser evoluídos e/ou corrigidos. O valor da qualidade do código está nessa etapa, que não existe nos casos que usei de exemplo, não de forma tão proeminente pelo menos.
Outras áreas da engenharia imagino que tenham mais essa dinâmica de evoluir/alterar/corrigir, talvez design de produtos tenham práticas para facilitar a evolução de projetos? Em arte, talvez pensando em etapas de produção e edição de um filme ou álbum, mas são etapas posteriores…não um ciclo completo como é no desenvolvimento de software.
Perfeito, minha crítica é justamente o quão assertivo o livro, porque isso influencia justamente em como se percebe o que está sendo dito. O que é um guia de estilo, parece um livro de matemática. O conteúdo do livro acho bem válido no geral, mas seria menos polêmico (e cativante) sem esse tom científico, que ficou pior à medida que ficou datado.
Em bibliotecas de dados de Python, é comum ter dezenas de parâmetros em construtores e métodos. Não vejo problemas, até porque a maioria é opcional e são obrigatoriamente nomeados quando utilizados. Parâmetros são o que cientistas normalmente mexem em modelos de machine-learning, não sei se faria sentido abstrair de outra forma, mas para mim não é possível reduzir dado o problema. São recursos da linguagem e a natureza do problema, que subvertem completamente o contexto (na minha opinião) e explicitam que é um livro escrito de uma perspectiva muito reduzida.
Vi uma entrevista que Uncle Bob adotou Clojure, seria legal ver o que ele pensa hoje porque esse padrão acaba forçando efeitos colaterais e vão de encontro com a ideia de funções puras.
Eu cheguei a ver essa discussão sobre performance – não é algo da minha realidade, exceto questões sobre volume de dados – então não tenho muita opinião, mas parece realmente parece botar culpa em quem não faz sentido. Concordo plenamente com o seu texto.
Adorei o texto Gabriel, quantas referências!!!
Ótimo texto. Eu sou programador free style (um engenheiro eletricista que faz programas (de computador) hj em dia) e é interessante que várias discussões assim são do ponto de vista de engenharia apenas “prática”. Você vai aprender as teorias e tals, mas vc é um engenheiro, não um físico ou químico. A ideia é fazer algo que funcione no plano real, não no das ideias.
Então entre fazer um projeto extremamente aderido à física e à ciência, a engenharia vai escolher 100% das vezes uma execução que funcione (com qualidade, segurança e robustez) no prazo, custo e esforço/retorno.