[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 lhes dá origem. Para uma atividade técnica, entretanto, a coerência interna de uma escola não encerra a discussão sobre os efeitos de suas recomendações.

A ressalva de “Schools of Thought” protege o livro de uma leitura excessivamente literal, mas não transforma todas as afirmações posteriores em simples preferências pessoais. Sempre que Martin associar uma prática à única maneira de trabalhar com rapidez, à definição de código limpo ou à própria condição de profissional, haverá uma afirmação que pode e deve ser examinada tecnicamente.

O custo de uma bagunça

O capítulo começa com uma premissa difícil de contestar: código ruim possui um custo. Na seção “The Total Cost of Owning a Mess” (“O custo total de manter uma bagunça”, em tradução livre), Martin descreve sistemas nos quais cada alteração quebra outras partes e equipes cuja produtividade diminui à medida que a base de código se torna mais difícil de compreender. Qualquer pessoa que tenha trabalhado por tempo suficiente em sistemas legados provavelmente reconhecerá alguma parte dessa descrição.

Na subseção “The Grand Redesign in the Sky” (“A grande reescrita dos sonhos”, em tradução livre), uma equipe tenta substituir integralmente um sistema cuja manutenção se tornou inviável. O título sugere uma solução idealizada, atraente em princípio, mas irrealista ou dificilmente alcançável. Enquanto o novo sistema procura reproduzir as funcionalidades existentes, o antigo continua recebendo alterações, fazendo com que a substituição persiga um alvo em movimento. Martin afirma já ter visto esse processo durar dez anos e terminar com a nova equipe pedindo a reescrita do sistema que deveria substituir o anterior.

Eu vi uma versão surpreendentemente literal dessa história. Trabalhei em uma empresa que mantinha uma das maiores bases de código Erlang do mundo. Em determinado momento, foi descoberto um bug que comprometia diretamente o uso do produto e a empresa ainda não havia encontrado, dentro ou fora da equipe, alguém que conseguisse corrigi-lo. Diante disso, decidiu iniciar uma grande reescrita em Java.

A decisão criou duas facções antagônicas dentro da empresa. Uma continuava responsável pelo sistema original em Erlang, enquanto a outra trabalhava em seu futuro substituto. Como o produto não podia deixar de evoluir durante a reescrita, os dois sistemas passaram a receber novas funcionalidades, cada um com sua própria equipe e seu próprio backlog. O sistema em Java tentava alcançar uma base em Erlang que continuava se movendo, exatamente como na situação descrita por Martin.

A reescrita nunca terminou. Em algum momento, a empresa contratou alguém maluco e habilidoso o suficiente para encontrar e corrigir o bug no sistema original. A justificativa técnica que havia iniciado o projeto desapareceu, mas já era tarde demais para voltar atrás. A reescrita havia acumulado investimento, equipes, compromissos e dependências suficientes para adquirir vida própria.

Como os dois sistemas continuaram existindo, um terceiro projeto precisou ser criado para servir como camada de abstração entre eles e o restante da empresa. A arquitetura final passou a incluir o sistema original, seu substituto incompleto e uma nova camada destinada a esconder a coexistência dos dois. A iniciativa que deveria substituir uma base considerada impossível de manter terminou ampliando a quantidade de sistemas, equipes e interfaces que precisavam ser mantidos.

Minha experiência torna a narrativa de Martin imediatamente reconhecível, mas continua sendo um caso particular. Ela demonstra que uma grande reescrita pode assumir essa dinâmica, sem estabelecer que toda reescrita seguirá o mesmo caminho. Também não permite concluir que a dificuldade para corrigir o bug tenha sido causada exclusivamente pela qualidade do código em Erlang. Escassez de conhecimento, decisões arquiteturais, perda de contexto histórico e características do próprio domínio podem ter contribuído para o problema. A correspondência mais clara com o relato de Clean Code está na tentativa de substituir integralmente um sistema que continuava evoluindo e no custo organizacional acumulado enquanto o novo sistema perseguia esse alvo móvel.

A situação descrita é plausível e bastante conhecida na indústria. O problema está na maneira como parte do argumento é construída. O livro também apresenta a história de uma empresa que teria sido levada ao fracasso pela deterioração de seu código, sem identificá-la ou oferecer elementos que permitam verificar a relação de causalidade. O gráfico que representa a queda de produtividade funciona como ilustração, sem dados ou método que o transformem em evidência. A familiaridade da narrativa ajuda o leitor a reconhecer o problema, mas não demonstra que código ruim tenha sido a causa determinante da falência daquela empresa ou que toda base de código desorganizada seguirá a mesma trajetória.

A moralização da qualidade do código

A discussão se torna ainda mais categórica na seção “Attitude” (“Atitude”, em tradução livre). Martin atribui aos programadores uma parcela considerável da responsabilidade pela degradação do código e rejeita explicações baseadas em prazos, mudanças de requisitos, decisões gerenciais ou pressões comerciais. Sua intenção parece ser combater a postura passiva de quem culpa a organização enquanto continua produzindo código difícil de manter. Essa cobrança por responsabilidade profissional possui valor, principalmente em ambientes nos quais desenvolvedores evitam comunicar riscos ou aceitam decisões técnicas que sabem ser prejudiciais.

A analogia usada para sustentar o argumento compara o programador a um médico que se recusaria a realizar uma cirurgia sem lavar as mãos, mesmo que o paciente exigisse rapidez. A comparação concede força moral à posição do desenvolvedor, mas aproxima duas situações com riscos, responsabilidades e níveis de autoridade bastante diferentes. Uma decisão sobre higiene cirúrgica possui evidências médicas, protocolos estabelecidos e consequências diretas para a vida do paciente. Uma discussão sobre duplicação, tamanho de funções ou prazo de entrega costuma envolver incerteza, compromissos comerciais e alternativas tecnicamente defensáveis.

Ao afirmar que ceder à vontade de gestores que não compreendem os riscos é uma atitude não profissional, o livro desloca parte da discussão técnica para o terreno moral e cria um problema potencialmente perigoso. O desenvolvedor não é dono do sistema, do orçamento ou da empresa e raramente possui autoridade para decidir sozinho quanto risco o negócio deve aceitar. Sua responsabilidade profissional inclui identificar as consequências técnicas, comunicá-las de forma compreensível, propor alternativas e participar da decisão, mas isso não lhe concede controle absoluto sobre prioridades, prazos e investimentos.

Maturidade profissional, nesse contexto, não consiste em defender uma concepção particular de código limpo a ferro e fogo. Ela aparece na capacidade de negociar uma solução que considere as necessidades técnicas e comerciais, talvez reduzindo o escopo, registrando uma dívida técnica, delimitando a vida útil de uma solução provisória ou combinando condições para uma correção posterior. Uma postura inflexível pode colocar o emprego do desenvolvedor em risco, prejudicar o projeto e reduzir sua influência sobre decisões futuras, sem necessariamente produzir um sistema melhor.

Há situações em que a recusa é uma obrigação, especialmente diante de riscos à segurança, violações legais, fraude ou consequências graves para outras pessoas. A maioria das divergências sobre qualidade interna de código, entretanto, não possui a mesma natureza da higiene necessária antes de uma cirurgia. Ao usar essa analogia, Martin transforma uma negociação sujeita a contexto e compromisso em um teste moral de profissionalismo.

Na seção “The Primal Conundrum” (“O dilema fundamental”, em tradução livre), Martin declara que a única maneira de cumprir um prazo e trabalhar rapidamente consiste em manter o código tão limpo quanto possível durante todo o tempo. A expressão “única maneira” transforma uma recomendação razoável sobre manutenção em uma afirmação universal que o capítulo não demonstra. Ela também ignora que decisões profissionais são tomadas dentro de organizações, sob restrições técnicas, financeiras e humanas que não desaparecem apenas porque o desenvolvedor está convencido de que sua solução é a mais correta.

Uma solução provisória, conscientemente limitada e acompanhada de riscos conhecidos, pode ser a decisão profissional mais adequada. Protótipos descartáveis, respostas emergenciais, experimentos, migrações transitórias e sistemas com vida útil curta não recebem necessariamente o mesmo investimento destinado a uma plataforma que deverá ser mantida por décadas. A dificuldade está em evitar que o provisório se torne permanente sem que ninguém perceba, mas essa possibilidade não elimina a necessidade de avaliar custos, prazo e expectativa de vida do software.

O nascimento do mito

Clean Code oferece uma combinação poderosa para a formação de um cânone. O livro apresenta problemas que quase todos os desenvolvedores reconhecem, associa suas soluções à experiência de profissionais respeitados e emprega uma linguagem moral ligada a cuidado, disciplina e profissionalismo. Ao mesmo tempo, fornece regras fáceis de memorizar e exemplos que parecem confirmar uma visão coerente sobre como o código deveria ser escrito.

A ressalva de que existem outras escolas exige uma leitura mais cuidadosa do que afirmações sobre a única maneira de trabalhar rapidamente ou sobre a relação entre testes e limpeza. Quando as ideias circulam fora do livro, as formulações categóricas sobrevivem com mais facilidade do que as limitações apresentadas no primeiro capítulo. O resultado é uma versão de Clean Code formada por mandamentos, frequentemente aplicada sem os estudos de caso, sem a reflexão proposta na introdução e sem o reconhecimento de que a própria obra se apresenta como produto de uma escola específica.

Essa transformação não pode ser atribuída exclusivamente aos leitores. Martin reconhece a pluralidade de abordagens, mas escolhe defender suas opiniões como absolutos dentro de sua escola. O mito de Clean Code como fonte definitiva nasce do encontro entre uma comunidade interessada em respostas claras e um livro disposto a oferecê-las com grande confiança.

A leitura adotada nesta série aceitará a advertência feita pelo próprio autor. A Object Mentor não possuía autoridade final sobre desenvolvimento de software, suas práticas foram construídas dentro de um contexto histórico e profissional específico e suas recomendações podem conviver com outras escolas. Essa abertura não impedirá uma análise crítica das passagens em que preferências são apresentadas como necessidades, experiências são usadas como prova e escolhas técnicas recebem um peso moral maior do que seus argumentos conseguem sustentar.

A melhor defesa e a crítica mais consistente de Clean Code começam no mesmo lugar: a leitura daquilo que o livro realmente diz.