Este é um artigo sobre o livro Clean Code - Robert C. Martin, em que pretendo trazer, de forma sucinta, anotações e comentários sobre o que aprendi com a leitura.
Logo no prefácio, é citada a metodologia 5S - até então, eu só conhecia o 5S utilizado em ambiente industrial, graças ao trabalho do meu pai - cujos conceitos são:
- Seiri (ou utilização, em português);
- Seiton (ou organização, em português);
- Seiso (ou limpeza, em português);
- Seiketsu (ou normalização);
- Shutsuke (ou disciplina);
Já no primeiro capítulo (Clean Code) , o autor nos faz pensar sobre o que é o código limpo, como deve ser feito e sua função. Gosto bastante do trecho que diz que o código limpo pode ser lido, compreendido e alterado por um desenvolvedor diferente do autor. Além disso, o código deve possuir testes de unidade/unitários/de aceite, possuir nomes significativos e poucas dependências. Ademais, evitar duplicidade de código também é importantíssimo.
No segundo capítulo (Meaninful Names) , é abordada a importância de nomes bem definidos para classes, atributos, métodos e responder questionamentos importantes, como: "Por que existe?", "O que faz?" e "Como é usado?"; deve evitar desinformação; o nome de uma classe deve conter um substantivo e evitar verbos; em contrapartida, métodos devem possuir verbos em seu nome; manter um contexto significativo e evitar o excesso de informação gratuita.
O assunto tratado é função (Functions) e acredito que o principal ponto trazido é: funções devem fazer apenas uma coisa, fazê-la bem e apenas isso. Ademais, devem ser curtas, evitar misturar abstrações pois pode dificultar a leitura e compreensão do que é feito.
O quarto capítulo nos traz algumas boas práticas relacionadas ao uso de comentários. Em primeiro lugar, precisamos saber que comentários boa parte das vezes, são decorrentes da falha dos desenvolvedores, ao escrever o código, salvo casos em que são realmente necessários (como comentários legais) ou trazem algum benefício real.
Alguns tipos de comentário são: informativos, sobre algo que está acontecendo; explicação de intenção, sobre algo que se espera que aconteça em determinado bloco de código; aviso de consequências, caso o bloco de código seja alterado; comentários TODO, para documentar tarefas à fazer.
Além disso, há comentários que são maus, como comentários redundantes e comentários errôneos, comentários desconexos/distantes do código relacionado e comentários muito extensos, dificultando a compreensão do código.
O quinto capítulo aborda a importância do código bem formatado, para facilitar a leitura e compreensão do que está escrito. É importante a definição de um padrão, que deverá ser seguido ao longo de todo código. Alguns pontos que achei relevantes, foram: evitar linhas muito extensas, para evitar o scroll para o lado, evitar tabulações estranhas, como espaçar tipagem e nome de atributos, organizar chaves e quebras de linhas, definir variáveis próximas ao seu lugar de uso.
O sexto capítulo traz considerações interessantes sobre objetos e estruturas de dados. [...] Esconder a implementação é sobre abstrações. Objetos: “escondem” seus dados através de abstrações e expõem funções que operam aqueles dados escondidos; Estruturas de dados: expõem seus dados e não possuem funções significativas.
Além disso, também é citada a Lei de Demeter, comumente utilizada em desenvolvimento orientado a objeto, abordando o acoplamento fraco. Alguns pontos são levados em conta, sendo eles:
• Cada unidade deve possuir conhecimento limitado sobre as outras unidades;
• Cada unidade se relaciona apenas com seus “amigos”, nunca com “estranhos”;
• Apenas se relacionar com “amigos próximos”.
Em suma, objetos expõem comportamentos e escondem dados, facilitando a criação de novos objetos, sem alterar os comportamentos existentes. Isso também dificulta adicionar novos comportamentos a objetos existentes. Sendo assim, estruturas de dados são o oposto, expondo dados e não possuindo comportamentos significantes;
No sétimo capítulo, são trazidas algumas considerações sobre o tratamento de erros . A responsabilidade do desenvolvedor é garantir que, caso ocorra, não seja algo fatal e o código faça o que precisa ser feito. A seguir, alguns pontos que achei interessantes deste capítulo: Escrever primeiro os try/catches, dar um contexto para as exceções, definir classes de exceção de acordo com as necessidades de chamada, definir um fluxo “padrão”, não retornar nulo.
No oitavo capítulo, falamos sobre os limites de um sistema e a importância de conhecê-los bem . Um ponto interessante a ser considerado é o uso do código de terceiros, como bibliotecas e APIs, pois nosso acesso, enquanto usuários, é limitado e precisamos controlar essas limitações, para não interferirem no sistema que está sendo desenvolvido; inclusive, testes são uma boa maneira de aprender sobre o código de terceiros, seus limites e ainda assim, manter testes coerentes ao projeto.
No nono capítulo, o assunto tratado foi um dos mais interessantes: testes unitários . Confesso que é um tema que não domino e pude aprender bastante com este capítulo.
Gostaria de citar 3 leis do TDD (Test Driven Development) – fora a famigerada “primeiro escreva os testes, depois o código”.
• Primeira Lei: não escreva código até que tenha escrito um teste que falhe;
• Segunda Lei: não escrever mais do que um teste suficiente pra falhar e não compilar é considerado falha.
• Não escrever mais código do que o necessário para passar o teste que está falhando;
É importante manter os testes limpos e organizados, para garantir que o código se mantenha flexível.
No capítulo 10, o tema classes é abordado e um dos pontos interessantes é a primeira regra sobre classes: elas devem ser pequenas. A segunda é que devem ser menores do que isso XD
Classes devem seguir o princípio de responsabilidade única (SRP) e devem também ser coesas.
O capítulo 11 aborda alguns pontos sobre arquiteturas de sistema , mas em suma, sistemas no geral precisam ser considerados/construídos limpos. Uma arquitetura bagunçada pode impactar na lógica e na agilidade, facilitando o aparecimento de bugs.
Capítulo 12 – Emergência, de acordo com Kent, o design de um sistema é considerado simples caso siga as seguintes regras:
• Passa por todos os testes;
• Não há duplicidade;
• Expressa a intenção do programador; e
• Minimiza o número de classes e métodos.
Também é dito que, havendo testes, somos impulsionados a manter nosso código limpo e podemos alcançar isso refatorando o código. Além disso, quanto mais claro o código for escrito pelo autor, menor será o tempo demandado para compreender o que ele deve fazer.
O capítulo 13 começa citando alguns mitos sobre o uso de simultaneidade no desenvolvimento, sendo eles:
• Simultaneidade melhora performance;
• O design não muda ao escrever código simultâneo;
• Entender simultaneidade não é importante ao usar contêineres como Web ou EJB.
Também é mencionado algo mais fidedigno em relação a construção de softwares simultâneos:
• Simultaneidade incorre em alguma sobrecarga, tanto em performance quanto em código adicional;
• O uso correto de simultaneidade é complexo, mesmo em casos simples;
• Bugs de simultaneidade normalmente não se repetem, por isso comumente são ignorados;
• Simultaneidade geralmente demanda uma mudança significativa na estratégia de design.
Capítulo 14 – Refinamento sucessivo
O capítulo 14 começa dizendo que, para escrever um bom código limpo, primeiro é necessário escrever o código “sujo” e “limpá-lo”.
O autor sugere como alternativa interessante o TDD (Test-Driven Development), que torna impossível prosseguir com o desenvolvimento de código que causa danos ao sistema, já que a premissa é escrever primeiro um teste e passar por ele, antes de seguir com novos desenvolvimentos.
Observação sobre os capítulos 15 ao 17: São capítulos mais voltados a análise de algumas ferramentas e refatoração de classes levando em consideração conceitos abordados no livro, além de uma visão geral dos capítulos anteriores.
Fontes utilizadas:
Obrigada por ler até aqui!
Dúvidas, sugestões e comentários são sempre bem-vindos!
Top comments (0)