Simplicidade – Métodos curtos

Acho que a evolução de um Desenvolvedor ocorre quando o seu código começa a ficar mais legível e simples. Eu acredito que mais de 80% dos códigos legíveis são simples, mas nem todo código simples é legível.

Kent Beck em Programação Extrema Explicada, cita 4 restrições que define o que é mais simples na visão dele:

O que é mais simples?

1) O Sistema (tanto código como testes) deve comunicar tudo aquilo que você queria comunicar;

2) O Sistema não deve conter código duplicado;

3) O Sistema deve conter a menor quantidade de Classes possível;

4) O Sistema deve conter o menor número de métodos possível.

Os meus 3 últimos meses trabalho foram sempre em projetos legados, as chamadas manutenções. Os Sistemas já estavam em produção e precisavam de reparos ou evoluções. Foram 3 projetos com essa mesma característica, e todos eles estavam com um código bem bagunçado e ilegível, naturalmente complexos.

Nada de padrões de codificação, códigos sem expressividade nenhuma, e métodos muito longos.

Como os sistemas estavam funcionando, e os Gerentes normalmente colocam os prazos apenas olhando o que deve ser feito como manutenção, nunca posso refatorar tudo o que eu queria e nem do modo como eu gostaria. Então, a primeira providência que eu tomo é quebrar os longos métodos.

Agindo dessa forma, de cara eu consigo:

1. 1) Identificar de fato o que cada método faz ou deveria fazer;
2. 2) Começar a organizar a “bagunça”;
3. 3) Identificar e eliminar código duplicado;
4. 4) Minimizar o impacto de futuras mudanças;
5. 5) e por sim, simplificar um pouco mais as coisas…

Eu acredito que método curto normalmente:

1. 1) Faz somente o que deveria fazer;
2. 2) Torna-se fácil identificar o seu objetivo;
3. 3) Pode ser reaproveitado mais facilmente;
4. 4) Torna o código do sistema mais legível.

Bem, mas voltando ao início do post, Kent Beck define uma regra para simplicidade que é: O sistema deve conter o menor número de métodos possível.

O resultado das minhas refatorações, tentando quebrar os métodos longos, é uma quantidade bem maior de métodos na classe. Mas mesmo tendo uma classe com mais métodos do que no início, o resultado que eu percebo (e outros membros da equipe também) é que tudo fica muito mais simples. Bem, é verdade que fica mais simples do que estava, e é isso que hoje eu entendo. Agora eu sei que, deixar as coisas mais simples que antes não necessariamente é deixar as coisas simples.

Mas como explicar para o Gerente que precisamos “arrumar a casa” para tornar as coisas bem mais fáceis? Como refatorar com eficiência e produtividade sem uma cobertura de testes?

Cada vez mais vejo que codificar é modelar, e as práticas de XP fazem todo o sentido. Arrisco-me a dizer que, não existe como ter um projeto de qualidade e sustentável sem adotar ou adaptar as práticas de XP.