Eu e o “Clean Code” (o livro) – Parte 1: Catequização

Faz muito tempo que digo para tomar cuidado com o livro “Código Limpo”: nunca cheguei a detalhar as razões… bem, o momento chegou. Como o texto inicial ficou enorme o dividi em partes.

Começo pela minha maior crítica que não é ao livro em si, mas ao modo como é lido, divulgado e comentado (ou seria melhor dizer… catequizado?).

Importante: no decorrer do texto ao usar o termo “Clean Code” me refiro ao livro original escrito e organizado por Robert C. Martin em inglês, não às práticas.

O termo “Código Limpo” será usado como referência à tradução para o português do livro.

Disclaimer: narro aqui a minha experiência pessoal/profissional com este livro que pode ser diferente da sua. Meu objetivo não é estar certo, mas levantar uma discussão.

“Código Limpo” é leitura obrigatória? Na minha opinião, sim.

Se na sua área de atuação muita gente fala sobre um livro é importante que você pelo menos dê uma passada de olhos nele para entender do que se trata e, ainda mais importante, poder entender do que as pessoas falam e se o que é dito de fato faz sentido.

Por mais que você odeie este livro não há como negar que hoje ele faz parte da nossa formação: mesmo que você não o tenha lido com certeza encontrou alguém que fala ou programa influenciado por algo que é dito ali.

Então, se você está iniciando na área, é importante ler o livro para entender sobre o que provavelmente seus colegas estão falando. Se você exerce papel de liderança é ainda mais importante ter lido pelos mesmos motivos. O que varia aqui é a intensidade da leitura crítica, que por natureza é menor no primeiro caso, mas obrigatória no segundo.

Aceite: “Código Limpo” é um livro influente por mais que você o deteste (disclaimer: não o detesto, apenas acho raso (o que não tratarei nesta primeira parte)).

A próxima questão é: de que “Clean Code” estamos falando?

Como o conteúdo chega a nós

Uma historinha de Filosofia

Se você teve a matéria de Filosofia no primeiro ou segundo grau (ou faculdade) provavelmente já ouviu falar sobre o “mundo das ideias” de Platão: se nunca ouviu, te conto o que é.

Segundo Platão para todas as coisas que vemos diante de nós há um equivalente “ideal” em outro plano, o “mundo das ideias” que é a representação conceitual de cada objeto. Então você vê uma cadeira diante de si, mas todas as cadeiras tem uma representação conceitual única no “mundo das ideias”, da qual participam e que as definem como… cadeiras.

Resumindo de forma bem rasa este é o “mundo das ideias” de Platão. Interessante, né? Agora é buscar na obra de Platão onde ele fala do mundo das ideias. Você não encontrará. Ou talvez… sim!

Talvez você encontre “mundo das ideias” em uma edição traduzida para o português. Mas por que eu disse que não encontrará? Por que a metáfora do mundo das ideias foi na realidade criada pelos comentadores de Platão, que a usaram para poder explicar ao leitor como era tratada a questão dos conceitos na obra do autor.

E o processo de tradução de uma obra quando bem feito nunca o é de forma direta, tal como um computador (ou um ingênuo) o faria: o tradutor mesmo que não queira leva para o resultado final do seu trabalho suas próprias pré concepções. E assim o que é dito por um comentador do século XIX vai parar na boca de Sócrates, em um texto de Platão no século V a.C…

(dica: qualquer tradução só pode ser considerada boa quando há um capítulo no livro explicando como foi feita e qual a metodologia aplicada)

No texto original, em grego, não há “mundo das ideias”.

Fontes primárias e secundárias

Fonte primária é o texto original. No nosso caso, o texto em inglês do livro “Clean Code” organizado (nem todos os capítulos do livro são escritos por ele) e escrito por Robert C. Martin.

As fontes secundárias são qualquer conteúdo que comente ou cite o livro “Clean Code”. E sabe o que também pode ser considerado uma fonte secundária? O livro “Código Limpo” traduzido para o português e publicado no Brasil pela editora Alta Books cujo tradutor sequer é citado na capa.

E sabe o que mais pode ser considerado fonte secundária? As interpretações que as pessoas fazem sobre o material, ou seja, o que seus colegas de trabalho dizem a respeito.

Neste momento o leitor deve se questionar: o que sei sobre “Clean Code” é de fato o que foi escrito por Robert C. Martin ou a opinião, interpretação ou releitura de alguém?

E muito cuidado com suas fontes secundárias: elas podem estar erradas e serem muito sedutoras.

Kico, você tá me dizendo então pra só levar a sério o Clean Code em inglês?

Não! Pelo contrário, a edição mais influente no Brasil é a da editora Alta Books e não o original. Logo, para o nosso contexto local, a leitura do original sirva mais para criticar/entender a tradução e entender o que se diz sobre o livro fora do país.

Ler esta tradução pode falar bastante sobre nosso mercado de trabalho atual (foge de mim me aprofundar neste post a respeito, fica pro próximo).

Fonte primária é melhor que secundária?

Não necessariamente. Como o próprio nome diz, a fonte primária apenas diz aonde começa o assunto, não onde ele obrigatoriamente vai ser melhorado.

As críticas feitas ao Clean Code tornaram o assunto “código limpo”, por exemplo, muito melhor e mais rico quer o dito no texto original.

(neste caso o conceito de melhor diz respeito às práticas, não à análise do conteúdo original)

Dogmas

O que é um dogma? É qualquer doutrina defendida como indiscutível. E infelizmente “Código Limpo” é visto e usado desta forma por muita gente. Aí que mora a maior parte dos meus problemas com o livro.

Você provavelmente já passou por situações assim: lhe é imposto um padrão de codificação e então você o questiona. E a resposta final é algo como “Código Limpo”. Você questiona “Código Limpo” e na sequência é fuzilado por olhares ou ações que te acusam de heresia. Quem nunca?

O mais interessante é que na esmagadora maioria dos casos que presenciei o que se falava sobre “Código Limpo” na realidade não era sobre o livro em si, mas sim sobre fontes secundárias.

O livro “Código Limpo” e seu original sofrem as consequências do seu sucesso: criaram uma horda de fanáticos que dificultam a leitura crítica do que ali é escrito.

Os seguidores: a questão da autoridade e o nascimento dos dogmáticos

Quando você publica um livro ou artigo, palestra em eventos, produz conteúdo e este é consumido em massa (em massa = mais de uma pessoa :) ) você adquire autoridade no assunto se for bem recebido.

Afinal de contas em teoria você sabe o suficiente sobre o que diz ao ponto de ter a segurança de se expor. No caso de livros esta autoridade é ainda maior pois este formato (o livro) sempre veio acompanhado de adoração. Culturalmente a escrita quase sempre foi (merecidamente) muito valorizada.

(confesso que nesta época na qual ser contra a ciência virou moda esta autoridade literária me gera alívio)

A autoridade da qual falo tem duas faces: a primeira é a do autor, a segunda é a do leitor, e talvez você ache o que vou dizer agora agressivo.

Não dá pra negar que vivemos em uma sociedade que lê pouco. Sendo assim não é raro que uma pessoa ao concluir a leitura de um livro veja este feito como uma conquista pessoal.

(aqui falo com experiência pessoal pela época em que trabalhei como livreiro (livreiro é aquela pessoa que trabalha em livrarias vendendo e indicando livros))

E terminar um livro de fato é uma conquista pessoal, dado que é muito mais difícil ler um livro que assistir a um filme/seriado/palestra/podcast. A leitura precisa ser ativa, sua atenção precisa ser redobrada, que requer exclusividade no processo e talvez você sequer saiba ler de fato (escrevi sobre isto aqui), o que talvez explique pro que tantas pessoas não gostam de ler.

E as pessoas querem defender sua conquista e o farão com unhas e dentes quando só tiverem lido este livro: nasce aqui o “dogmático do código limpo”. Mas a pessoa não vira este monge dogmático só por ter terminado a leitura, vejo mais fatores aí:

• A estrutura narrativa do “Clean Code” leva a isto (é o tema do meu próximo texto, aguarde).
• Existe um ecossistema criado ao redor do “Clean Code” que induz ao leitor que aquele é O CAMINHO a ser seguido para se obter qualidade (e você sempre quer estar entre aqueles que considera os melhores)
• A insegurança pessoal: se você está dando os primeiros passos e encontra um livro (uma autoridade) que te dá suporte, você naturalmente se agarra a ela.

E ser dogmático na nossa área é péssimo pois tudo é definido pelo contexto e este sempre varia por mais que tentem nos dizer que não.

Como evito ser um “monge do clean code” então? Simples: lendo outros livros. Só assim você vai conseguir ver que há diferentes visões sobre o mesmo tema, muitas vezes contraditórias entre si.

E aqui entra o problema: se estas diferentes visões são contraditórias entre si, qual a correta? A que tá dentro do contexto em que você se encontra.

O processo de catequização

Observo algumas situações o tempo inteiro:

• No LinkedIn a pessoa posta orgulhosa uma foto do kit de boas vindas da empresa: nele há uma edição de “Código Limpo”.
• Livros são publicados sobre “Código Limpo” que até agregam algumas informações adicionais mas não críticas ou pontos de vista discordantes do que é dito no Clean Code.
• O mesmo dito sobre os livros repito sobre apresentações e vídeos e lives.
• A pessoa chega na empresa e lhe é dito que deve seguir o “Clean Code” à risca como prática mínima de desenvolvimento sem questionar.
• No currículo a pessoa diz que segue “as boas práticas do Clean Code”.
• Olhares incrédulos para quem questiona “Código Limpo”.

Observo que é um processo que normalmente surge no topo das hierarquias das empresas (ou dos produtores de conteúdo) como um dogma: regras que devem ser seguidas. Do ponto de vista pragmático e preguiçoso faz muito sentido: em teoria já estão ali no livro as práticas e todas em teoria muito bem justificadas.

(Além disto se alguém questionar você sempre pode soltar a velha carta do “tá no livro, cadê o seu?” pra usar. É prático!)

Problema: quem originou a indicação da leitura o fez de forma crítica avaliando-o em relação ao contexto em que atua? Outra pergunta: quem está indicando o livro possui experiência técnica?

Já vi Clean Code ser indicado pelo RH, donos/gestores de empresas ou por líderes técnicos que só sabem do conteúdo do mesmo por fontes “terciárias”. Não raro motivados por pensamentos como “código é tudo igual”, “programador é tudo igual” e não raro algum trauma com desenvolvimento no passado. É a busca por qualidade usando-se uma solução que parece ser a mais fácil: diligenciar a uma autoridade.

(já vi ser indicado por muita gente boa de serviço também, tá?)

Há uma soma de autoridades aqui: literária, cultural (produtores de conteúdo que são formadores de opinião e portanto manipuladores da cultura) e a hierárquica (empresa/mercado). Você entra em uma empresa ou quer fazer parte, é uma pessoa iniciante, então o que pensa? Vou seguir a dica!

Até aí, problema algum: mas e se não seguir os “mandamentos do Clean Code” e for obrigado a fazê-lo mesmo quando não faz sentido para o seu contexto? Quando se tem experiência, você argumenta, quando não se tem, normalmente se cala por não se sentir seguro para tal.

E após repetidas vezes seguindo os “mandamentos do Clean Code” o que ocorre? Você os aceita e se este for o único livro de boas práticas que leu agora você é um dogmático e sequer se deu conta disto. E quer ver piorar? Você vai ascender na carreira e continuará todo o ciclo novamente.

Isto é triste pois você contrata gente justamente por ser… gente: pessoas que vão pensar diferente e trazer soluções interessantes para o seu dia a dia. Nada contra bons padrões de codificação, mas quando são impostos como dogmas e não como possíveis caminhos a serem seguidos você vê gente sendo tratada como robôs (que podem ser facilmente substituídos) e não como seres criativos (que é onde está o valor).

E isto tudo é feito dentro de um contexto no qual se cria a impressão de que o único livro sobre boas práticas de construção é o Clean Code. Resultado: sua visão de mundo vira o… “Clean Code” seja lá o que é que estão chamando de “Clean Code”.

Por que você tá chamando de catequização?

Por que é a imposição de uma cultura e hábitos sobre outra que não aceita o diferente: que por pura ignorância (e arrogância) impõe uma visão de mundo monolítica, por ser baseada em uma única fonte.

O que narro aqui é esta visão limitada da realidade quando o assunto é qualidade ou boas práticas na construção de software. Uma visão que, inclusive, tal como a dos jesuítas, não é a original, mas sim a resultante de camadas e mais camadas e mais camadas de comentários a respeito sendo que boa parte são no final das contas bobagem.

Como sugiro resolver o problema

Só vejo uma forma: lendo outras coisas além do Clean Code e entendendo que o que há nele é a visão de mundo dos seus autores. Uma visão que não é a única, nem a melhor, nem a pior.

Tenho indicação de livros pra dar? Claro, seguem apenas alguns:

• Code Complete – Steve McConnell
• A Philosophy of Software Design – John Ousterhout
• Trabalho Eficaz com Código Legado – Michael Feathers
• The Pragmatic Programmer – Andrew Hunt e David Thomas
• Beautiful Code – Andy Oram e Greg Wilson
• Refatoraçã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.

Mas não se baseie nesta lista que passei: busque por si próprio, há inúmeros que não mencionei aqui. O fundamental é ver que há outras visões além do Clean Code.

Continua…

Nesta primeira parte não falei do Clean Code em si. Não disse que é um texto ruim nem bom. Meu objetivo é fazer uma leitura crítica do texto.

Minha crítica aqui foi ao modo como o livro infelizmente é usado. Ok, aí não é culpa do livro, certo?

Não necessariamente. O modo como ele é escrito talvez induza este fenômeno que descrevi aqui.

É a questão que quero levantar no meu próximo post, em que vou analisar a estrutura narrativa do texto que sim, pode alimentar este comportamento dogmático que descrevi aqui.

Até lá!