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á!
Deixe uma resposta