Capítulo 12 – Emergência
No capítulo 12, 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.
Capítulo 13 – Simultaneidade
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.
Top comments (0)