Finalmente estou fechando esta série de posts sobre o livro “Código Limpo”: agora finalmente escrevo minhas impressões finais sobre a leitura e tudo o que envolve este texto.
Para ter uma visão completa sobre o que estou falando recomendo que você leia as três primeiras partes:
- Eu e o Clean Code – Parte 1: Catequese
- Eu e o Clean Code – Parte 2: Descompilando
- Eu e o Clean Code – Parte 3: O Nefasto Capítulo sobre Comentários
Minha própria estratégia narrativa
Falei tanto sobre a estratégia narrativa do Robert Matin, então pra começar entrego aqui a minha: meu objetivo nesta série foi mostrar alguns aspectos relacionados tanto à escrita do livro quanto ao que ocorre ao seu redor:
- Por que acredito que há uma postura dogmática em relação ao que ali é escrito (primeira parte).
- Em que medida o autor pode ser responsável por este comportamento dogmático (segunda parte).
- Expor a linguagem tóxica presente no texto original. Faço isto mostrando a construção de uma figura de autoridade na segunda parte e apresentando de forma explícita como esta toxicidade se manifesta na terceira parte quando disseco o quarto capítulo (“Comentários”).
- Deixar bem claro que há não um livro “Código Limpo”, mas vários: o original e as inúmeras versões alternativas do texto que se manifestam a partir dos comentários que são publicados a seu respeito em todo lugar.
Comecei mostrando o elefante branco que estava na sala, na sequência apontei o dedo para a linguagem exposta no texto e pra finalizar mostrei aonde a estratégia tóxica do texto aparece de forma mais explícita no livro (clássico mineiro comendo pelas beiradas).
Agora rasgo o verbo dizendo o que penso sobre o livro.
Código bem escrito é uma coisa e “Código Limpo” outra
Apesar da expressão “Código Limpo” fazer uma referência a código bem escrito acho importante tornar clara uma diferença aqui: quando usamos o termo “Código Limpo” estamos nos referindo ao livro “Clean Code” e a todos os produtos que Robert Martin vende (tem até logotipo).
É um fenômeno muito similar ao que ocorre quando nos referimos a palha de aço como “Bom Bril”, por exemplo. Acho isto ruim pois na prática acabamos por fazer marketing gratuito ao referenciarmos algo que deveria não estar ligado a uma pessoa/empresa, mas a uma área: estratégias para a escrita de código bem feito.
As práticas descritas no livro não são invenção de seus autores (leia a parte um para entender este plural), mas hábitos que já existiam e foram documentados por outros autores (veja na terceira parte quando mostro que o Capítulo 4 possui uma versão anterior “atóxica” escrita por Steve McConnell no Code Complete anos antes).
Aqui entra então um problema que o sucesso do livro trouxe: esta confusão de termos e a personalização de práticas.
Sendo assim daqui pra frente quando eu disser “Clean Code” ou “Código Limpo” me refiro ao livro, não a código bem escrito.
Nem todo código bem escrito segue a cartilha de “Código Limpo”
Apesar de ter achado o vídeo “Clean Code Terrible Performance” do Casey Muratory (há um texto dele também que pode ser lido aqui) muito tendencioso (merece um post a parte) amei o fato de ter vindo à tona e, de um certo modo, foi o pontapé que eu precisava pra finalmente escrever esta série de posts.
Apesar dos pesares foi levantado um fato muito importante ali: seu código não deve obrigatoriamente seguir o que está sendo dito em um livro apenas pelo fato de… estar em um livro muito conhecido e recomendado. E este talvez seja o único ponto no qual concordo 100% com Casey Muratory apesar dele não dizer isto de forma explícita em seu material.
Por que o termo “princípio” que é aplicado às técnicas apresentadas no “Código Limpo” é uma aberração e acredito que nos trouxe sérios problemas. Usamos o termo “princípio” para denotar ou o início de algo ou a base para a construção de alguma coisa (há inclusive uma conotação moral aqui – veja o que falo a respeito na segunda parte da série).
Observe os resultados que aparecem pra mim ao buscar “Princípios do Clean Code” no Google:
O último resultado grita para mim: “quais são as boas práticas de programação? “.
Em diversos artigos (como este no LinkedIn) “Clean Code” é descrito como: “conjunto de práticas recomendadas para a escrita de código considerado ‘limpo'”. Há um problema sério aqui que é o seguinte:
uma “boa prática” só faz sentido quando é adequada ao contexto!
E apesar de no próprio livro os autores mostrarem o contexto em que suas refatorações são aplicadas, na prática o que vemos é as mesmas serem aplicadas como princípios. Aliás… o termo “prática” também acho ruim. Um termo muito melhor na minha opinião é “estratégia” pois já trás em si implícita e explicitamente a necessidade de um contexto.
E vou além: a partir do momento em que o termo “princípio” se popularizou também se cria a impressão de que no “Código Limpo” estão todas as estratégias possíveis para se escrever bom código. Ignora-se todos os livros que cito na primeira parte desta série e que listo aqui de novo:
- Code Complete – Steve McConnellA Philosophy of Software Design – John OusterhoutTrabalho Eficaz com Código Legado – Michael FeathersThe Pragmatic Programmer – Andrew Hunt e David ThomasBeautiful Code – Andy Oram e Greg WilsonRefatoração – Martin Fowler (aqui tenho várias críticas, mas é um bom livro)The Practice of Programming – Brian Kernighan e Rob Pike (yeap: o “cara” do C e do Go)Os padrões definidos pela sua linguagem (ou linguagens) de programação e sua documentação oficial.Livros sobre a linguagem de programação também costumam expor boas práticas.
Resumindo: “Código Limpo” é apenas um pequeno conjunto de estratégias que só devem ser usadas quando o contexto realmente é o adequado.
A responsabilidade do autor
Um dos comentários que recebi é de uma riqueza imensa e me fez pensar bastante:
Wellington, na terceira parte da série
Como alguém que já viu a própria toxicidade gerar efeitos terríveis me senti muito seguro em responder o Wellington. Autores (geradores de conteúdo em geral) acabam construindo fama, autoridade e se tornando modelos para outras pessoas, especialmente aqueles que estão dando seus primeiros passos.
E faz parte da civilidade saber dar feedbacks que não sejam agressivos, mas honestos, especialmente para aqueles que ainda estão construindo a própria segurança. Quem está começando aprende com quem tem mais experiência, é assim que funcionamos.
(Kant descreve este aprender pelo exemplo como imperativo categórico (eu tinha de meter um filósofo aqui, né?))
E este livro é normalmente oferecido a iniciantes, que por sua vez tem a tendência de seguirem o exemplo dos mais experientes (no caso o autor) e, com isto, podem perpetuar posturas que, apesar de carismáticas, são ruins. O Wellington concordou comigo depois (aliás, foi uma bela conversa ali).
Fechando o livro
Concluindo: ainda acho que todo mundo deveria ler este livro aqui no Brasil pela sua importância e influencia, mas não pela sua qualidade.
(pessoalmente o único capítulo que gosto é o segundo – “Nomes Significativos”, escrito pelo Tim Ottinger)
O grande mérito do livro foi ter criado toda esta excitação em relação à escrita de código bem escrito, entretanto do ponto de vista cultural o considero um desastre pelas razões que expus em toda esta série e finalizei neste post.
E agora vocês sabem o que digo presencialmente a todos aqueles a quem indico a leitura deste livro.
PS:
O José Yoshiriro (tivemos uma discussão bem acalorada nos comentários) escreveu um livro sobre Clean Code publicado recentemente na Casa do Código.
Ele havia me pedido para lhe dar minha opinião sobre o mesmo durante a escrita. Na época lhe disse que não via sentido no livro por que era mais jogo ler o original. Yoshiriro, eu tava errado!
O fato de você ter escrito um livro sobre o mesmo assunto mas com uma linguagem bem melhor é uma excelente razão para que as pessoas o leiam ao invés do Código Limpo original.
Além do Yoshiriro o Alexandre Aquiles escreveu um livro sobre SOLID também pela mesma editora. Apesar de ter duas cópias impressas do livro (uma delas o Alexandre me deu de presente) até hoje não consegui ler, mas também recomendo a leitura pois tenho certeza que a linguagem é muito boa.
PS 2:
São estratégias, não princípios!
The post Eu e o “Clean Code” – Parte 4: Fim da Leitura appeared first on /dev/Kico.
Top comments (3)
Isso é uma ideia que sempre vem na minha cabeça mas nunca consegui por em palavras. Nos meus poucos anos de trabalho a ideia de clean code tem sido solução em metade dos casos e problema na outra.
Quando tive que argumentar a favor fui bem vindo, quando tive que argumentar contra conclui que era melhor me estressar lidando com aquilo do que lutando contra.
Pena que acabou! :)
vem mais coisas aí. :)