Nos insights de código limpo dessa semana iremos repassar alguns conceitos já vistos nos capítulos anteriores, como forma de reunir tais aprendizados para aprender um pouco mais sobre design emergente de software.
No capítulo sobre design emergente do livro Código Limpo – Habilidades práticas do agile software, de Robert C. Martin, Jeff Langr explica que um design “simples” segue as seguintes regras:
- Todos os testes são executados
- Não existe duplicação de código
- Expressa a intenção do programador
- Minimiza o número de classes e métodos
Jeff também explica que tais regras são ordenadas em termos de importância.
Seguem algumas considerações sobre cada regra:
Testes
Um sistema que é exaustivamente testado e passa em todos os testes o tempo todo é um sistema testável. Além disso, a escrita de testes conduz a um melhor design da aplicação.
Com tais testes, somos empoderados a manter nosso código e nossas classes limpas. Isto é possível através da refatoração. A cada linha de código que adicionamos, paramos e refletimos sobre o novo design. Caso o sistema tenha sido degradado, limpamos o mesmo e executamos os testes para demonstrar que não quebramos nada. O fato de termos estes testes elimina o medo de que limpar o código irá quebrar algo.
Duplicação
A duplicação é o inimigo primário de um sistema bem arquitetado. Duplicação representa trabalho adicional, risco adicional e complexidade desnecessária adicional.
Entender como atingir o reuso em partes pequenas do sistema é essencial para atingir o reuso em partes maiores do sistema.
Expressividade
A maioria dos custos de projetos de software estão na manutenção de longo prazo. Quanto mais claro o autor puder manter seu código, menos tempo outros terão que perder para entendo-lo.
Muitas vezes fazemos nosso código funcionar e vamos para a resolução de um novo problema, sem nos preocuparmos o suficiente em tornar tal código fácil de ler para os próximos desenvolvedores que irão lê-lo.
Portanto, o cuidado é um recurso precioso. Devemos escrever nossos códigos com o máximo de cuidado possível, pois outros desenvolvedores precisarão ler estes para dar manutenção no futuro, assim como nós precisaremos ler códigos de outros desenvolvedores.
O mínimo de classes e métodos
Nosso objetivo em geral é manter o sistema pequeno, com pequenas classes e funções. No entanto, esta é a regra com a menor prioridade dentre as outras mencionadas para um design simples. Portanto, mais importante do que manter as classes e funções pequenas, precisamos nos importar em escrever testes, eliminar código duplicado e sabermos nos expressar.
Ao seguirmos a prática do design simples encorajamos e capacitamos desenvolvedores a aderir princípios e padrões que de outra forma levariam anos para serem aprendidos.
E você, aplica design emergente em seu dia-a-dia? Me conte um pouco a respeito.
TALKING ABOUT TESTING 