Eu e o Clean Code – Parte 3 – O Nefasto Capítulo sobre Comentários

Finalmente começo a comentar alguns dos capítulos do “Código Limpo” mais a fundo contando minhas experiências a respeito. O termo “experiência” aqui é o mais adequado pois vou falar sobre os efeitos que vi do capítulo 4 (“Comentários”) do livro em pessoas com quem trabalhei, projetos nos quais atuei e histórias que chegaram a mim.

O termo “Nefasto” também foi bem pensado: na minha experiência este é um dos textos que mais problemas trouxe para a nossa área.

A ideia essencial por trás deste capítulo é que os comentários são um mal necessário e que só existem por que não conseguimos nos expressar de forma clara através do nosso código. Com o tempo as pessoas foram percebendo que esta é na realidade uma ideia muito ruim, inclusive seus mais ardorosos defensores criaram um novo termo: “comentários estratégicos”.

Então neste post vou primeiro analisar como o texto é escrito e depois apresentar minhas próprias ideias sobre o tema baseadas em outros autores que li e minhas próprias experiências.

Alguns avisos

Aqui falo sobre a tradução do livro “Clean Code” para o português feito pela editora Alta Books. Para esta análise não levo em consideração o texto original.

Esta terceira parte é fundamentada no que apresento nas duas primeiras desta série nas quais analiso o modo como o texto é escrito e como, acredito, este gera comportamentos exageradamente exaltados em parte dos seus leitores. Caso não as tenha lido e se interesse, seguem os links:

Não se exalte nos comentários deste blog. Ele é meu, pessoal, e bloqueio quem eu quiser. Todos são bem vindos para discutir, mas ninguém é obrigado a ler tratados e comentários agressivos aqui.

Tal como nos outros textos não quero estar certo, mas levantar uma discussão para que seja possível termos uma leitura mais crítica e rica do texto e crescer neste assunto.

Este não é um texto sobre política (mas toca no tema (contraditório hein? (é))).

Em 2000 eu trabalhava em uma livraria…

Com 21 anos tive meu primeiro emprego que achava realmente “sério”: trabalhava como vendedor (“livreiro”) na Livraria da Travessa em Belo Horizonte, que era focada em livros da área de Ciências Humanas. Foi um período importantíssimo para minha formação pois tive contato com diversos autores que me forjaram e alguns que me enganaram.

Dentre os autores que me enganaram havia um em especial que me seduziu inicialmente pelo comportamento dos seus leitores. Eles chegavam a mim desconfiados, falando baixo, olhando para os lados com medo de serem vistos pedindo seus livros. Diziam que era alguém com opiniões muito fortes e que tecia críticas ferozes aos intelectuais e mídia da época.

(eu sempre achava que estes leitores iam me pedir algum livro pornográfico e ficava decepcionado depois quando descobria o que realmente queriam…)

Eu tinha 21 anos, não sabia nada da vida (ainda não sei) e alguém que xingava só podia ser coisa boa. Li alguns dos seus textos naquela época e o achei realmente brilhante. Era cativante por que o modo como criticava o mundo me fazia sentir que eu era parte de um grupo seleto que agora via as coisas “como realmente eram”.

No ano seguinte entrei para o curso de Filosofia e tive contato com outros autores, foi quando resolvi reler o tal autor de forma mais atenta e fiquei chocado com a quantidade de bobagens e absurdos que este dizia de forma tão sedutora. Era absurdo: escrevia sobre Aristóteles, por exemplo, como se fosse um expert, mas nunca o havia lido no original (neste caso é necessário), relativizava escravidão e, no final das contas era só um infeliz cuja escrita exteriorizava suas próprias frustrações e alimentava o ressentimento alheio.

(Quem não tem frustrações? Quem não se sente confortado ao ver alguém atacando a fonte de nossos ressentimentos?)

E esta sensação de desconstrução da genialidade (aka “perceber que era uma grande bobagem que havia me iludido”) que tive ao ler atentamente este autor e a postura de diversos dos seus leitores que se mostraram pessoas fanatizadas com o tempo (“catequizadores”) me lembram muito a minha experiência com o texto do capítulo “Comentários”. O autor a que me refiro foi o Olavo de Carvalho.

Minha primeira impressão sobre este capítulo foi tão positiva que em 2016 escrevi neste blog sobre o assunto e ao final recomendava este texto. Duvida? Aqui o link.

A ideia de que eu só escrevia comentários por que meu código não era claro o suficiente foi por um tempo inclusive um incentivo para que eu escrevesse código mais fácil de ser mantido. Entretanto com o tempo ficou claro que a questão era bem mais profunda e muito mais rica.

Um aviso sobre olavo de carvalho

Apesar de ter comparado Robert Martin a Olavo de Carvalho este texto não é sobre Olavo de Carvalho.

As similaridades acabam nos pontos que mencionei (a constatação de que o capítulo sobre Comentários não era genial, mas tóxico e parte dos seus leitores que se tornaram catequizadores). Robert Martin não tem um passado tão terrível quanto carvalho, nem disseminou desinformação (até onde sei) durante a pandemia, o que pode ter causado a morte de pessoas (no caso do Brasil, muita gente).

Robert Martin deixará um legado positivo, ao contrário de carvalho (mesmo tendo escrito este capítulo sobre o qual escrevo).

(e eu não vou aceitar comentários sobre carvalho neste blog (é meu, aceito o que quiser aqui))

De qual Código Limpo estou falando?

Tal como disse no primeiro post da série há claramente duas versões do livro: a oficial e a não oficial. A segunda diz respeito aos comentários e diversas interpretações ao texto que, neste caso, mudam bastante o significado do que está na versão oficial.

Aqui falo da versão oficial e, tal como dito na introdução, da tradução para o português feita pela editora Alta Books. Mas vou contar mais adiante uma história que me aconteceu relativa à versão “alternativa” do livro.

Construção do argumento

O início do capítulo é o momento em que o autor nos seduz para concordarmos com seu argumento usando as estratégias que já vimos nas primeiras duas partes: metáforas morais, expressões controversas e um claro apelo à emoção.

Logo no início o leitor será induzido a ter uma percepção negativa sobre comentários e isto fica bem claro nas citações que trago abaixo, presentes logo no começo do capítulo:

“Nada pode ser tão prejudicial quanto um velho comentário mal feito que dissemina mentiras e informações incorretas”

Robert C. Martin – primeiro parágrafo do capítulo – já começa com metáforas morais

“Comentários não são como a Lista de Schindler. Não são o “bom puro”. De fato, eles são, no máximo, um mal necessário.”

Robert C. Martin – segundo parágrafo do capítulo – (aqui se vê problemas na tradução inclusive). Observe o apelo á emoção na referência ao filme.

“O uso adequado de comentários é compensar nosso fracasso em nos expressar no código”

Robert C. Martin – terceiro parágrafo do capítulo – (discordo muito sobre isto e falarei mais adiante) (de novo, repare que tradução ruim na colocação dos termos)

“Por que eu não gosto de comentários? Porque eles mentem

Robert C. Martin – quinto parágrafo do texto. Atenção para o uso de metáfora moral tal como aponto na segunda parte desta série.

Mesmo quando vai falar sobre quando comentários são positivos, o autor nos solta um…

“Tenha em mente, contudo, que o único comentário verdadeiramente bom é aquele em que você encontrou uma forma para não escrevê-lo”

Robert C. Martin – primeiro parágrafo da seção “Comentários Bons” do capítulo. Novamente, atenção para a má tradução da seção e até mesmo o mal gosto da expressão usada pelo autor.

Na sequência o autor vai expor o que considera serem comentários válidos: observe que interessante.

  • Informações legais – comentários sobre licença de uso, por exemplo.
  • Comentários informativos (no texto é propositalmente vago o que ele chama de “comentários informativos”).
  • Explicitação da intenção (a maior parte dos comentários na realidade é a explicitação da intenção).
  • Esclarecimentos.
  • Alertas sobre consequências.
  • TODOs.
  • Destaques.

Observe que são tipos de comentários realmente super válidos, mas sabe o que é interessante? Na tradução para o português é gasto o dobro de páginas para falar sobre comentários ruins.

É interessante observar a linguagem adotada pelo autor na descrição dos comentários ruins: é muito parecida com aquela adotada por pessoas que agridem seus colegas (normalmente iniciantes) em seus code reviews. Vamos a um exemplo:

Às vezes você vê comentários que nada são além de “chiados”. Eles dizem o óbvio e não fornecem novas informações:

/**
Default constructor
*/
protected AnnualDateRule() {
}
Ah, sério? Ou este:
/** Dia do mês */
private int dayOfMonth;

Robert C. Martin – Capítulo 4 – Seção comentários ruidosos. Grifo do autor.

Consigo imaginar um leitor neste momento me questionando: “Kico, sério? Isto aí que você está falando é mimimi!!!” (detesto a expressão “mimimi”). Respondo: sério. Na minha experiência um dos maiores danos que você pode causar a quem está iniciando é justamente este tipo de linguagem em um code review.

Mas aqui há uma razão para tal: faz parte da estratégia do autor de conquistar o leitor pela rabugice e ridicularização tóxica de erros muito comuns por quem está começando (o que gera a sensação de pertencimento a um grupo seleto de seus leitores). Há personagens que usam a mesma estratégia para conquistar o espectador: Dr. House, Chefe Ramsay, juízes cruéis de reality shows, Steve Jobs…

(a glamorização do babaca)

Se você já tem muitos anos de experiência, tal como eu, talvez tenha se esquecido que quando começou os comentários muito provavelmente eram o que te ajudavam a ter segurança nos seus primeiros códigos. Atacar esta “muleta” do iniciante da forma como é feito neste livro é um desfavor.

E aí consigo imaginar o leitor me questionando de novo: “então como posso abordar o tema dos comentários com um novato, Kico?“. Respondo: tal como Steve McConnell faz no seu livro “Code Complete”. Ele mostra como alguns comentários podem ser ruins, mas não os ridiculariza e nem usa metáforas morais para te convencer disto, usa apenas fatos.

E sabe onde Steve McConnell fala sobre comentários? No capítulo 32: “Self Documented Code”, que é essencialmente o que Robert Martin tenta fazer neste capítulo nefasto. Sabe o que é ainda mais interessante? Este capítulo está na segunda edição do Code Complete, publicada em 2004. A primeira edição de Clean Code é de 2008. Robert Martin não cita Code Complete neste capítulo.

(A primeira edição de Code Complete é publicada em 1993 e foi um livro bastante influente. É importante ter esta informação histórica aqui neste parêntese (que é um comentário))

E esta é a argumentação básica de Robert C. Martin neste capítulo. Sabe o que é mais triste? Ele termina o capítulo mostrando como refatorar comentários ao final, mas não diz o que seria intelectualmente honesto aqui para informar o leitor no decorrer de sua argumentação: comentários não são eternos e são alterados conforme o código muda no decorrer do tempo.

Em 2016 eu já estava na itexto…

Oferecemos um tipo de consultoria chamado “suporte de aquisição” na qual intermediamos quem adquire serviços de desenvolvimento e quem presta estes serviços. O objetivo não é policiar ou fiscalizar,mas sim ajudar as duas pontas evitando conflitos e reduzindo custos: com isto detecto possíveis problemas no que está sendo construído antes que ele chegue ao cliente e, ao mesmo tempo, ajudo o cliente a entender o que de fato está comprando.

(e, claro, ajudo os fornecedores a não perderem seus clientes)

Em um dos nossos primeiros casos lidei com a aquisição de uma plataforma enorme. Era um projeto que já estava terminando o primeiro ano de desenvolvimento e estava atrasado em pelo menos três meses. Ainda pior: a equipe interna de desenvolvedores do cliente não conseguia absorver o trabalho contratado pois não havia documentação sobre a arquitetura do projeto.

Conversando com o fornecedor ouvi algo que mudou minha visão inicialmente positiva do capítulo “Comentários” do Clean Code:

“Nós não documentamos nossa plataforma por que seguimos os princípios ágeis pregados pelo Clean Code, segundo o qual o código já se auto explica.”

Vindo da liderança técnica da equipe

Meu trabalho inicial consistiu então em documentar a arquitetura que havia sido construída junto com este fornecedor. Em dois meses salvamos o projeto: cliente e fornecedor entenderam o que estava sendo construído e até hoje este fornecedor atende este cliente com sucesso.

E aqui entra o “Clean Code alternativo”: em momento algum do livro é dito que arquiteturas não devam ser documentadas. Nem no livro “Clean Architecture”, publicado em 2017 algo assim é dito.

E sabe o que era mais interessante neste caso? A plataforma foi escrita em Java, mas a equipe só tinha experiência com .net. Resultado: usaram os padrões de codificação do C# para um projeto Java.

Eu e os comentários

A argumentação óbvia de que comentários em excesso são algo ruim na minha opinião é redundante: qualquer coisa em excesso é ruim. Simples assim, é uma crítica que portanto nada diz.

Mas há pontos que com o tempo foram se tornando mais claros para mim.

Código totalmente auto explicativo é uma ilusão

A história que conto de 2016 é um bom exemplo disto: para a equipe que desenvolvia a plataforma o sistema era óbvio. O problema é que existe mundo externo e a percepção deste pode ser diferente da de quem codifica. Resumindo: o que é óbvio para você não necessariamente é para o outro.

(a experiência foi meses depois do meu próprio texto que mencionei aqui – incrível como mudou de repente minha visão sobre o livro)

E não é raro encontrar pessoas que se isolam no ato de programar, geram coisas maravilhosas, que funcionam super bem mas que, infelizmente, são de difícil compreensão para o resto do time. Talvez até mesmo por terem uma formação específica que não seja a mesma que a da equipe (matemáticos, por exemplo). Nestes casos comentários agregam, e muito.

Indo além, sempre há um contexto: o código nunca existe por si mesmo. Existe um contexto em que ele foi gerado. Este contexto pode ser histórico (a situação da empresa naquele momento). Ter esta informação ajuda muito a entender por quê foi codificado daquela maneira e, mais importante: por que funciona ou não.

E há outro fator também: equipes mudam, mas raramente muda o stakeholder do projeto. E este precisa do máximo de informação possível para que possa manter sua posse sobre o mesmo.

(Knuth tentou algo similar com literate programming muitos anos antes e a ideia não vingou)

Sobre comentários “mentirosos”

Atuo profissionalmente desde 1996: na minha experiência nunca vi alguém mentir em um comentário. O que já vi foi algum comentário desatualizado. Mas sabe de uma coisa? Nestes casos quem dava a manutenção simplesmente os atualizava e o problema estava resolvido.

Nunca foi um problema.

Comentários redundantes

É chato encontrar um comentário redundante? Sim, concordo: mas nunca vi um comentário redundante ferir a produtividade de alguém. Indo além, tal como disse neste mesmo texto, normalmente quando os encontro são escritos por quem está começando e os usa para ter alguma segurança sobre o que está sendo produzido.

E aí como você resolve o problema? Simples: no momento do code review você os remove se forem realmente redundantes e explica para o autor dos mesmos por que o fez de forma civilizada.

Contextualização histórica

Em 2016 escrevi sobre como você pode usar comentários para contar a história daquele sistema. Ainda mantenho minhas posições sobre o que disse ali (só discordo da recomendação literária que faço ao final). Caso queira ler, segue o link.

Sobre a questão de créditos e autoria nos comentários

Discordo de Robert Martin quando ele diz que não faz sentido incluir créditos e autoria do código dado que temos sistemas de controle de versão.

Se você lida com código que implementa algoritmos muito específicos (matemáticos ou físicos por exemplo) é muito útil ter a autoria ali, pois fica muito mais fácil saber a quem procurar. E convenhamos: é bem mais fácil que ficar consultando log de commits, né?

Comentários como ferramenta de design

É interessante o livro não mencionar isto, mas observo em mim e outras pessoas o uso de comentários como ferramenta de design. Direto me pego escrevendo comentários antes do código que vou construir para tornar mais claro para mim o que de fato quero fazer ali.

Os escrevo no topo das classes ou funções, e na sequência simplesmente os traduzo para código fonte. E sabe o que é mais legal? Costumam virar uma documentação super útil para quem vai dar manutenção depois, pois fica claro ali qual era o objetivo inicial daquele código.

Ano passado fiquei muito surpreso ao ler isto no livro “A Philosophy of Software Design” no qual o autor descreve exatamente este processo de criação. Aliás, neste livro estão os melhores capítulos que já li sobre o tema “Comentários”. Recomendo muito a leitura, especialmente por ter um contraponto muito interessante em relação ao “Código Limpo” no que diz respeito a este assunto.

Concluindo?

Levou anos para escrever este texto, mas finalmente saiu! Na época não podia narrar estas experiências pois estava atuando no projeto que mencionei e este post poderia ter gerado um grande constrangimento desnecessário. Mas hoje com tudo resolvido, fica muito mais fácil escrever a respeito.

Me impressiona como estas vinte páginas do texto geraram problemas ao longo do tempo: nem tanto pelo texto em si, mas muito mais pelas interpretações muito equivocadas do mesmo (me pergunto inclusive se estas pessoas realmente leram este livro).

Acho que no final das contas este é o pior capítulo do “Clean Code” e aquele sobre o qual mais vejo problemas. Repito o que disse na primeira parte desta série: ainda acho importante a leitura do livro pela importância que ele tem na formação de gerações de programadores aqui no Brasil.

Espero que com esta série eu possa ter lhe mostrado como extrair um pouco mais da leitura deste livro e mesmo outros que possam seguir a mesma (pobre) linha argumentativa.

No caso deste capítulo tenho uma sensação diferente: tal como já escrevi, os textos que mais gosto são aqueles dos quais discordo pois a leitura se torna um diálogo com o qual aprendo. Não é o caso aqui: a argumentação tóxica nos trouxe problemas no futuro, e não vejo muitas pessoas escrevendo a respeito, o que só aumenta o problema.

Talvez eu escreva mais sobre o livro, mas agora vou aproveitar que voltei a escrever para falar sobre outras coisas por enquanto. Até lá!

17 comentários em “Eu e o Clean Code – Parte 3 – O Nefasto Capítulo sobre Comentários”

  1. José Yoshiriro

    Olá, Henrique. Tudo bem? Espero que sim.

    Sabe aquela pesquisa que te mencionei por email? Dá uma olhada nela aqui: https://arxiv.org/pdf/2208.07056.pdf. Ela pode enriquecer seus próximos posts sobre o tema, na medida que mostra o quanto as técnicas ensinadas no Clean Code têm adesão no mundo real. É um estudo de 2022.

    Como é comum que esses PDF de artigos científicos saiam do ar para depois serem vendidos, talvez que leia esse comentário não consiga ver mais. Porém um “resumo grande”, com as figuras de análise gráfica do artigo está aqui e dificilmente sairá de lá: https://link.springer.com/chapter/10.1007/978-3-031-21388-5_21

    Na parte de comentários, os resultados deste estudo, em boa medida, convergem para suas discordâncias.

    PS: Sobre o Olavo de Carvalho – ele tem um legado negativo que precede a pandemia, já tendo ensinado até que fumar não fazia mal pra saúde, dentre outras barbaridades 😦

    1. José Yoshiriro

      Em tempo: o estudo que indiquei não é para defender nem criticar a obra ou o autor. É um estudo – que me pareceu bem imparcial – cujo resultado mostra que algumas orientações do Clean Code acabaram não tendo adesão no mundo real enquanto outras, sim.

      1. Kico (Henrique Lobo Weissmann)

        as práticas eu acho mega válidas: o que ferra neste livro é a linguagem.

        1. José Yoshiriro

          Fiquei “de cara” ao saber que na versão traduzida tem o dobro de páginas pra falar de comentários ruins. Não sabia disso – valeu pela informação que provalvelmente quase ninguém sabe -. Por que será que fizeram isso?

          1. Kico (Henrique Lobo Weissmann)

            É a estratégia narrativa do Robert Martin neste capítulo: ele quer a todo custo te fazer pensar que comentários são ruins e que, nas próprias palavras dele: “um bom comentário é aquele que você não escreveu”.
            Ele joga sujo aqui.

            Inclusive, eu recomendo demais ler no Code Complete o capítulo 32 da segunda edição, por que é essencialmente este capítulo 4 do Clean Code (escrito quatro anos antes, e comodamente não mencionado (a primeira edição de 1993 também fala algo nesta direção)) em que você nota a mesma abordagem: o autor mostra que comentários em excesso são ruins, fala sobre comentários ruins, mas com uma diferença: fala dos bons também e no mesmo tanto, sem usar esta linguagem forçada demais e tóxica deste capítulo.

      1. Olá, acredito que nem todos tem tempo hábil para ficar lendo livros. Às vezes, as pessoas reproduzem aquilo que elas ouvem em cursos, palestras, etc. Isso causa o problema do “telefone sem fio”, em que se ouve uma coisa, mas repassa outra coisa. Pela minha experiência, isso também acontece com o Clean Code nessa parte de comentários. Convenhamos, a maioria dos brasileiros não são leitores nato de livros (inclusive eu)!

  2. Olá, Kico. Li agora, de uma vez, as 3 partes.

    Gostei muito do seu jeito de escrever. Parabéns!

    No início desta parte eu pensei “aposto que ele está falando do Olavo” e gargalhei quando vi que acertei.

    Percebi que é como vc me respondeu lá no GUJ: A coisa vai bem além.

    Entendi seu ponto sobre o livro, apesar do capítulo Escolas de Pensamento, usar estratégias que inspiram o leitor a assumir uma postura dogmática em relação ao livro.

    Também entendi que sua intenção é incentivar a leitura crítica do livro alertando para os pontos que podem deixar turvo o discernimento do leitor.

    Mas, Kico, será que é correto ou saudável colocar a culpa toda no livro e nas suas estratégias e não no leitor? Quero destacar 3 pontos:

    1. O livro foca em desenvolvimento de software profissional, o que não inclui programas criados por iniciantes para estudo. Logo, o que quer que Martin diga sobre comentários, não se aplica ao cara que está produzindo um trabalho para um curso.

    2. Apesar da linguagem usada no livro, achar que está tudo bem usar a mesma linguagem num code review, especialmente quando envolve iniciantes, é, no mínimo, questão de soft skills mal-desenvolvidas do reviewer.

    3. Sobre “não documentamos porque seguimos Clean Code”. Para mim é um caso de alguém sem pensamento crítico. Não importa o que um livro diga, é o seu trabalho e vc tem que raciocinar sobre ele. As coisas que o livro diz, como ele diz, é pura estratégia. A leitura é só um dos passos, o resto é com vc digerir o que acabou de ler e separar o joio do trigo, como dizem os mais velhos.

    Então, meu ponto é: É um livro, uma ferramenta. E como usamos esta ferramenta é de nossa responsabilidade.

    O autor poderia ter usado uma linguagem melhor? Poderia.

    Poderia ter usado exemplos melhores? Poderia.

    Poderia ser melhor de forma geral? Poderia.

    Mas eu não o culparia por uma empresa tomar uma decisão errada só “porque é o que o livro sagrado diz” e nem por alguém babaca ter destratado uma pessoa num code review.

    O que vc acha?

    1. Kico (Henrique Lobo Weissmann)

      Opa, é o que vou tentar responder no quarto post.
      Mas já adianto algumas coisas.

      1) Todo autor deveria ser responsável pelo que diz. No caso do Clean Code, a conclusão a que chego é que na realidade é um livro ruim, pois a estratégia argumentativa do autor poderia ser intelectualmente honesta e, como pode ser visto na terceira parte, não é. Mais que desonesta, é tóxica, e a partir do momento em que a gente vê ali a construção de uma figura de autoridade (o Autor), há aqueles que o vão seguir como modelo.

      2) O exemplo da empresa que menciono: é o “Clean Code extra oficial”: depois que você publica algo (como estes meus textos, por exemplo), este algo cria vida própria. Gente que sequer leu o texto o cita de forma deformada, como neste caso que citei. Não vejo como culpa do autor, é mais um efeito cascata mesmo. A gente tem vários exemplos na história assim. Apenas alguns pra começar: Marx (os absurdos que dizem que ele disse e não disse), Nietzsche (tem gente que o acusa de ter criado o nazismo, por exemplo com o conceito de “uberman”), etc.

      3) O que vou dizer poderá soar agressivo e de fato é: a gente vive numa sociedade muito ignorante e que lê muito pouco. Que coloca no pedestal máximo o primeiro autor que lê. E daí surgem estes problemas. Foi inclusive o que falei na primeira parte.

      4) O livro é uma ferramenta? Pra mim enquanto pesquisador, é, pra nós enquanto sociedade, é considerado fonte de sabedoria. Soa cafona “fonte de sabedoria”, mas quando a gente pensa no peso que damos aos livros (e temos de dar mesmo), você entende por que tanta gente os considera coisas tão perigosas. É por que são.

      (eu fecho estas ideias na quarta parte. esta terceira parte eu quis expor da forma mais explícita possível o fato de que o autor usa estratégias sujas (é até irônico eu usar esta palavra) na sua argumentação. E sabe o que é mais triste nisto tudo? Ele nem precisava disto)

      1. José Yoshiriro

        Henrique,

        você acha que ele também estava “no lugar certo” e, principalmente “na hora certa” e isso também ajudou a alavancar a fama da obra?

        Sabe, na época estavam pipocando linguagens e frameworks e ele pega e publica um “compêndio”, um “guia”, que *promete* ajudar a “por ordem na casa” (no código) e que, concorde ou não com as estratégias, conquistou a imensa maioria dos leitores.

        Aliado a sua já existente fama… e voila! Nasce um sucesso!

        Pra mim, esse fator “hora certa” tem muita relevância – deixando claro, não acho que foi o único nem o maior – no sucesso que a obra alcançou. O que você acha?

        1. Kico (Henrique Lobo Weissmann)

          Talvez, mas ele tem muito mérito e já escrevia bastante coisa antes deste livro.

      2. Olá, Kico. Muito obrigado por me responder.

        Eu gosto de personagens rabugentos e incisivos, seja Uncle Bob ou Fabio Akita.

        O ego dói quando eles apontam de forma dura erros que cometo, mas eu entendo que cada um tem sua tragetória e ninguém sabe de tudo e, no final, me sinto motivado a aprender. Tanto ninguém sabe de tudo que consigo identificar alguns erros que eles cometem ou contra-argumentar algumas de suas opiniões.

        Eu prefiro que o autor “apresente seus conceitos como verdades absolutas e não se desculpe pela austeridade” do que, a cada meia duzia de palavras, ele fique se justificando “aqui é só minha opinião tá bom? Há várias formas diferentes de se fazer, mas aqui eu apresento a que eu prefiro, mas tudo bem se vc não concordar, beleza?”.

        Apesar de vc não ter gostado da analogia em “Escolas de Pensamento”, ali deu para entender perfeitamente o que ele quis dizer. Fora que no capitulo ele traz vários colegas para responder com as próprias palavras o que é “código limpo”. Então houve a preocupação em realmente mostrar que aquilo não era a verdade absoluta.

        Na sua opinião, dá para manter o persongem sem ser tóxico ou este tipo de personagem deve ser extinto do nosso meio?

        E também, vc acha que o autor é objetivamente tóxico, ou tóxico é o comportamento assumido por quem lê? Afinal, o que vc chama de comportamento tóxico estava dentro do contexto do livro e não é normal achar que dá para replicar isso no mundo real.

        O autor tem responsábilidade em passar informações corretas. No caso do Código Limpo, como é opinião pessoal, não daria para dizer que ele passou informação errada.

        Me diga o que vc acha. Eu tive que reescrever várias vezes este comentário porque não queria soar como um adorador ou advogado do Martin ou do seu livro. É que ainda não consegui concordar com seu ponto.

        É que parece que a gente tá tratando pessoas adultas como crianças que não sabem discernir as coisas e tem que falar com todo o cuidado do mundo.

        No ambiente de trabalho, se alguém fala comigo deste jeito, eu vou ficar bravo e não vou aceitar que um colega fale com outro assim também. Mas num livro, num vídeo, num blog, eu realmente não vejo problema.

        Ou talvez tenha 🤔… Não sei. Por favor, me fala o que vc pensa, eu ainda tô processando aqui.

        1. Kico (Henrique Lobo Weissmann)

          Olha… Como alguém que já foi mais tóxico digo que dá pra não ser tóxico, viu?

          Acho que pelos exemplos que mostrei mostra que é objetivamente tóxico.

          O problema de você ser um autor é que sem querer sua postura incentiva a mesma nos leitores, especialmente os iniciantes. E este livro é bem focado em iniciantes, a própria linguagem e introdução tornam isto bem claro. E isto cria uma cultura ruim, digo por experiência própria.

          Se for um livro de opiniões pessoais, como você disse, então o livro já perde o sentido pois não é vendido como tal.

          E aí que tá: relendo o livro a fundo hoje percebo que a parte boa não foi escrita pelo Robert Martin.

Deixe uma resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Rolar para cima