Recentemente, por incentivo do meu chefe, comecei a ler o famoso livro Clean Code. Eu já tinha lido alguns capítulos no começo da carreira, mas acredito que relembrar vai ser essencial, ainda mais tendo passado por boa parte dos casos mostrados e entendendo na prática o que é um bom código.
O objetivo dessa escrita vai ser uma análise do meu ponto de vista, alguns tópicos também foram conversados com o chatGPT para que ele me ajudasse a destrinchar melhor, dividido por capítulos, esse método me ajuda a fixar o conteúdo, repassando os pontos marcados no livro e também pode ajudar outros desenvolvedores.
Capítulo 1
O capítulo 1, do mesmo nome do livro "Clean Code" basicamente faz um apanhado do que pode ser definido como um código limpo, trazendo definições, reflexões interessantes e pontos de vista de autores famosos que possuem uma base robusta pra dizer o que consideram ser um código limpo.
Pra começar, achei divertida a metáfora de um grego lavando um pergaminho com código, um trocadilho interessante pra começar a abordar o assunto.
O primeiro autor que é citado nesse capítulo é Kent Beck, que diz que o livro dele "is based on a rather fragile premise: that good coode matters…", após essa citação, o autor se mostra consternado com essa afirmação retrucando que acha uma das premissas mais robustas, e que Kent sabia disso. Nesse caso, levei um pouco menos ao pé da letra, é indiscutível que um bom código importa, talvez mais que tudo no desenvolvimento, mas talvez seja uma premissa frágil por ser tão facilmente subestimado, esquecido, no cotidiano é normal que desenvolvedores deixem de fazer um bom código devido a correria de uma entrega, ou a falta de importância do resto do time (e isso também é citado em algum outro momento do livro), e por mais que eu concorde que é essencial, infelizmente não da pra negar que é um aspecto extremamente frágil.
Ainda no tópico "Bad Code" o autor faz uma pergunta direta "Have you ever been significantly impeded by bad code?" pra apresentar o conceito de wading pra depois perguntar "why did you write it?", soltei um ar pelo nariz lendo essa pergunta porque acredito no motivo que descrevi acima, o que me faz sentir mal porque eu sou responsável pelo código que crio, amo o que faço e nada justifica a criação de um código ruim. E aí vem a parte onde ele apresenta possíveis argumentos pra criação de um código ruim.
O livro também conta com uma "solução" pra esse problema, falando que atitude é uma coisa que deve ser trabalhada também, como eu falei, desenvolvedores são responsáveis pelos códigos ruins que escrevem, e acho que a partir do momento que pessoas que querem fazer um bom trabalho entenderem isso (não é fácil), as tarefas no backlog podem esperar pra uma entrega de qualidade.
Uma coisa que me fez pensar muito nesse capítulo foi o paragráfo
A programmer without "code-sense" can look at a messy module and recognize the mess but will have no idea what to do about it. A programmer with "code-sense" will look at a messy module and see options and variations.
Particularmente, acho meio injusta essa afirmação, o que não muda a veracidade da mesma. Só que já experimentou a sensação de saber que tem algo ruim ali mas não ter conhecimento necessário pra melhorar sabe o quão agonizante é esse sentimento. Confesso que sinto uma certa inveja desse dom, porque também vejo pessoas que estudam pouco mas tem um senso de lógica fascinante pra lidar com esses momentos, e pra mim, por mais que estude muito e tente sempre melhorar e treinar minha lógica, ainda não é tão fácil.
Começando a espécie de "junção" de depoimentos de grandes autores da programação, são feitos alguns discursos interessantes definindo clean code.
Um deles, o criador do C++, Bjarne Stroustrup, fala duas coisas que achei bem importantes:
- The logic should be straightforward to make it hard for bugs to hide
- Clean code does one thing well
A primeira é óbvia, mas quando dita se mostra sensacional, código ruim é mais fácil de manter os bugs escondidos, e a segunda, é uma coisa que o livro cita bastante que é focar em uma coisa, esse é um conceito curioso porque até então eu não considerava que escrevia códigos ruins, mas sempre buscava tornar as coisas amarradinhas para que fosse de melhor entendimento, esse ponto me abriu os olhos para separações, principalmente depois da definição de que códigos ruins tentam fazer muita coisa, que possuem ambiguidade de propósito, e vamos citar isso melhor numa abordagem dos próximos capítulos. O autor também cita a palavra eficiência duas vezes, o que é irônico visto que duplicidade é fortemente repudiada na programação e no livro também.
Grady Booch, também deu seu depoimento dizendo que código limpo deve ser lido como uma prosa, achei bem fofo esse ponto de vista e uma verdade absurda. O que reforça que código limpo deve expor claramente os problemas que deseja resolver e também cita aquele momento de clímax onde as coisas começam a fazer sentido e sorri lendo porque essa é minha parte favorita da programação. Código bom não é especulativo, é auto descritivo.
Dave Thomas, ao qual tenho um certo carinho por conta do primeiro livro realmente técnico que li "O Programador Pragmático", comenta "It provides one way rather than many ways for doing one thing", o que reforça o ponto de focar bem em um só objetivo, além de citar testes, aqui acho que ele foi categórico porque tenho muito pra mim que bons códigos são testados, não sei se pensava que unitários e de aceitação, como Dave diz, mas como ele citou, acho interessante explicitar também. Nesse tópico, também é dito que existe uma diferença entre um código fácil de ler e um código fácil de mudar, e isso me fez pensar de novo sobre o modo que eu conduzo meu código.
Michael Feathers, autor do livro "Working Effectively With Legacy Code", trouxe que código limpo sempre parece ter sido escrito por alguém que se importa, e aqui, ele foi categórico! Citei o livro dele porque ele me ganhou demais nessa afirmação e adicionei na minha lista. Ao longo da minha trajetória, me deparei com vários tipos de código e INÚMERAS vezes percebi que a pessoa não se importava, isso é um pouco revoltante porque eu me importo e sei que isso sempre vai voltar pra mim de alguma forma, seja em refatoração ou atrapalhando meu cotidiano. A questão é que é muito perceptível quando as pessoas não se importam com o que estão fazendo e é perda de tempo se dedicar tanto a algo que não se importam o mínimo.
Ron Jeffries foi um dos que me fez parar, pensar e conversar com o ChatGPT sobre seu testemunho, num dos pontos que define um código limpo, ele citou que "Minimizes the number of entities such as classes, methods, functions and the like", essa frase me deixou num dilema pois como vimos, muitos autores (inclusive o próprio Ron) defendem que o código deve fazer apenas uma coisa, pegando o exemplo de uma função que faz apenas uma coisa, isso me obriga a criar outras funções que fazem outras "uma coisa só". Conversei com o ChatGPT sobre isso, trazendo esse questionamento, ao qual ele me respondeu que apesar de ser um ponto interessante, que Ron menciona isso e que o próprio livro posteriormente enfatiza o SRP (vou falar disso no capítulo de funções), parecendo contraditório. Mas que devemos considerar que a ideia é manter o código simples, coeso e fácil e que pra isso devemos ter equilíbrio, onde embora o número de declarações aumente, cada uma será mais simples, focada em uma só tarefa. De qualquer forma, acho que discordo desse ponto de Ron, apesar de entendê-lo.
Ward Cunningham trouxe uma frase muito interessante também "You can call it beatifull code when the code also makes it look like the language was made for the problem", com poucas palavras, pra mim ele matou a definição, pena que isso é díficil de ver no dia a dia.
Por último, como ponto importante, o livro mantinha uma preocupação na minha cabeça de ter um hype tremendo de limpar código mas não conseguir manter o código, sem querer, no primeiro capítulo, o autor me deu uma dica interessante, através do "Princípio dos Escoteiros", que diz que você deve deixar o lugar mais limpo do que encontrou, aplicar isso no código me fez conversar de novo com o ChatGPT sobre se fazer isso não estaria tirando o foco do meu desenvolvimento, mas novamente ele me respondeu que a resposta era o equilíbrio, que não precisam ser feitas grandes refatorações, mas que posso nomear melhor uma função, ou remover uma duplicação. Nessa dúvida me apressei em falar com ele desnecessariamente porque o próprio autor fala isso logo em seguida.
Top comments (0)