[pt-BR] Clean Code passado a limpo - Parte 1

Uma leitura crítica, sem dogmas e sem espantalhos Muito se fala sobre Clean Code, publicado no Brasil como Código Limpo. Entre iniciantes e desenvolvedores de nível pleno, é comum encontrar quem adote suas recomendações de maneira dogmática, como se o livro fosse um tratado de verdades absolutas. No outro extremo, profissionais mais experientes frequentemente o descartam por completo e parecem dispostos a queimá-lo na fogueira erguida do outro lado dessas mesmas verdades absolutas. Em ambos os casos, a leitura crítica acaba substituída por uma conclusão tomada de antemão. Para esta série, usarei a edição original em inglês. Tenho uma longa e desastrosa experiência com traduções da Alta Books e minha recomendação continua sendo direta: aprendam inglês e leiam o original. Já escrevi sobre isso e não pretendo retomar essa discussão aqui. Para quem trabalha com desenvolvimento de software, a capacidade de ler textos técnicos em inglês é fundamental. Robert “Uncle Bob” Martin sustenta publicamente posições que considero indefensáveis e que atraem um público politicamente conservador, para dizer o mínimo. A discussão em torno desses posicionamentos é legítima, mas não será o objeto desta série. Vou me limitar à análise da obra, mantendo uma distância saudável de seu autor. O livro, a escola e o mito Poucos livros sobre desenvolvimento de software alcançaram uma presença cultural comparável à de Clean Code. Suas recomendações aparecem em entrevistas de emprego, revisões de código, guias internos, cursos, vídeos e discussões sobre senioridade. Termos como funções pequenas, nomes significativos, responsabilidade única e ausência de duplicação passaram a circular de forma relativamente independente do livro, muitas vezes reduzidos a regras que cabem em uma publicação curta ou em um comentário de pull request. Essa popularidade produziu uma versão simplificada da obra. Nela, Robert Martin aparece como o autor de um conjunto fechado de mandamentos sobre como todo código deveria ser escrito. Algumas pessoas adotam esses mandamentos como critérios objetivos de qualidade; outras os rejeitam como dogmas ultrapassados, geralmente sem dedicar muita atenção ao argumento original, ao contexto dos exemplos ou às ressalvas feitas pelo próprio livro. A leitura de Clean Code revela uma obra mais complexa. Seu tom é frequentemente categórico e algumas conclusões ultrapassam aquilo que seus exemplos conseguem demonstrar, mas o livro também reconhece que representa uma escola específica de desenvolvimento de software. A tensão entre essas duas posturas, a declaração de que não existe uma verdade absoluta e a apresentação de determinadas opiniões como absolutos, atravessa toda a obra e ajuda a explicar tanto sua influência quanto boa parte das críticas que recebeu. Antes do livro, a Object Mentor A Object Mentor foi uma empresa de consultoria e treinamento em desenvolvimento de software fundada em 1991 por Robert C. Martin. Em sua biografia atual, Martin também identifica Jim Newkirk como cofundador. Ao longo de sua existência, a empresa ofereceu treinamento em C++, Java, orientação a objetos e princípios de design e, posteriormente, passou a atuar fortemente com Extreme Programming e metodologias ágeis. Seus serviços incluíam consultoria, treinamento, mentoria e desenvolvimento de software. A Object Mentor encerrou suas atividades em 2008, no mesmo ano em que a primeira edição de Clean Code foi publicada. Esse contexto ajuda a compreender o significado da expressão “Object Mentor School of Clean Code” (“Escola de Código Limpo da Object Mentor”, em tradução livre), usada no primeiro capítulo. A escola mencionada por Martin correspondia às práticas que ele e seus colegas aplicavam, ensinavam e comercializavam por meio de uma consultoria. A própria folha de rosto apresenta os colaboradores do livro como “The Object Mentors” (“Os mentores da Object Mentor”, em tradução livre), reforçando que a obra registra uma visão desenvolvida coletivamente dentro daquela empresa. Isso também explica o caráter pragmático do livro. Clean Code não se apresenta como uma pesquisa acadêmica nem procura construir suas recomendações a partir de estudos controlados sobre legibilidade, manutenção ou produtividade. Sua matéria-prima é a experiência acumulada pelos autores em projetos, treinamentos e consultorias. O conhecimento oferecido nasce da prática profissional, da observação e da repetição de soluções que, segundo eles, produziram bons resultados. Experiência é uma fonte legítima de conhecimento técnico, especialmente em uma atividade na qual contexto, equipe e domínio exercem influência considerável. Ainda assim, uma prática que funcionou repetidamente dentro de uma consultoria continua precisando ser examinada antes de se transformar em uma regra geral. Parte do trabalho desta série será identificar quando o livro apresenta uma experiência como experiência e quando a transforma em uma conclusão universal. Um livro que exige trabalho A introdução de Clean Code também contradiz a maneira superficial como a obra costuma ser consumida. Martin descreve o aprendizado da escrita de código como uma combinação de conhecimento e prática. Princípios, padrões e heurísticas teriam pouco valor quando separados do exercício de ler, modificar e compreender código real. O livro foi dividido em três partes com essa finalidade. A primeira apresenta princípios, práticas e padrões. A segunda reúne estudos de caso nos quais códigos existentes são sucessivamente alterados. A terceira organiza os smells e as heurísticas identificadas durante essas refatorações. Martin afirma que o valor dessas heurísticas depende da relação entre cada uma delas e as decisões tomadas nos estudos de caso. O leitor que ignora os exemplos e consome apenas as regras perde, segundo a própria introdução, a parte mais importante da obra. Esse detalhe é especialmente relevante porque a versão popular de Clean Code costuma fazer exatamente aquilo que o livro desaconselha. As heurísticas são retiradas dos exemplos, resumidas em frases curtas e aplicadas em contextos nos quais o raciocínio que as produziu já não está presente. Uma função deve ser pequena, uma classe deve ter uma única responsabilidade e um comentário deve ser evitado, mas raramente se discute como reconhecer os limites dessas recomendações, quais custos surgem de sua aplicação ou que características do código original levaram os autores àquela decisão. Uma análise justa da obra precisa observar os estudos de caso e verificar se as transformações propostas realmente produzem os benefícios prometidos. Os capítulos “Successive Refinement” (“Refinamento sucessivo”, em tradução livre), “JUnit Internals” (“Aspectos internos do JUnit”, em tradução livre) e “Refactoring SerialDate” (“Refatorando SerialDate”, em tradução livre) serão particularmente importantes porque apresentam o refinamento sucessivo de código, a análise interna do JUnit e a refatoração da classe SerialDate . Quando chegarmos a eles, poderemos avaliar Clean Code por meio do código que o próprio livro oferece como demonstração de suas ideias. A escola que admite ser escola Na seção “Schools of Thought” (“Escolas de pensamento”, em tradução livre), no capítulo “Clean Code” (“Código limpo”, em tradução livre), Martin apresenta uma das passagens mais importantes do livro. Ele compara escolas de desenvolvimento de software a escolas de artes marciais. Cada uma possui suas técnicas, seus mestres e sua maneira de praticar, sem que isso conceda a qualquer uma delas o monopólio da verdade. Martin pede que o leitor considere o livro uma descrição da escola de código limpo da Object Mentor. Ele admite que muitas recomendações são controversas, prevê que o leitor poderá discordar vigorosamente de algumas delas e reconhece que outras escolas possuem a mesma legitimidade profissional. Também afirma que os autores não podem reivindicar autoridade final sobre o assunto. Essa passagem precisa fazer parte de qualquer crítica honesta a Clean Code. A obra não esconde sua origem nem afirma que a Object Mentor tenha descoberto a única maneira profissional de escrever software. O livro recomenda, inclusive, que o leitor conheça outros mestres e amplie sua prática para além daquela escola. O problema surge dentro da própria formulação dessa ressalva. Martin declara que as opiniões do livro serão apresentadas como absolutos e que ele não pretende se desculpar pela estridência. Para os autores, naquele momento de suas carreiras, aquelas recomendações eram absolutas dentro da escola que haviam construído. Em poucos parágrafos, o texto pede que o leitor reconheça a legitimidade de outras abordagens e, ao mesmo tempo, prepara o terreno para defender suas próprias escolhas com uma linguagem deliberadamente categórica. Essa tensão tem uma consequência prática importante. Uma pessoa em início de carreira, e muitas vezes até em um estágio intermediário, ainda está formando o repertório e o discernimento necessários para consumir essas recomendações com um grão de sal. Sem experiência suficiente para reconhecer os contextos, as exceções e os custos envolvidos, torna-se difícil separar um princípio amplamente aplicável de uma heurística circunstancial, uma preferência estilística ou uma opinião particular dos autores e de sua escola de pensamento. Quando essas distinções são apresentadas por profissionais reconhecidos, em um livro que associa suas práticas à qualidade e ao profissionalismo, a tendência é incorporá-las como regras antes de desenvolver os instrumentos necessários para questioná-las. É nesse ponto que começa o problema. A comparação com artes marciais ajuda a compreender a proposta, mas também estabelece uma relação peculiar entre mestre e aprendiz. O estudante deve se dedicar às técnicas de uma escola, praticá-las até incorporá-las e, somente depois, procurar outros mestres. Essa estrutura favorece um período inicial de aceitação no qual as regras são tratadas como corretas dentro do sistema que lhe