¦ M ! L Є S i • B Λ S Γ Ø S ¦

(Astels, 2003), em seu livro, define refatoração como o processo de realizar alterações em um código já existente sem alterar o seu comportamento. Com o objetivo de melhor a estrutura interna do código, uma refatoração alterara a forma como o código produz algum comportamento sem alterar o que ele faz.

Refatoração e TDD estão intimamente relacionados de duas maneiras:

• Depois de fazer a coisa mais simples para um teste passar, vamos refatorar para limpar o código e remover duplicidades.
• Quando praticamos TDD temos um conjunto exaustivo de testes que nos dão confiança e coragem para refatorar.

Quando refatorar

De um modo geral, nós refatorar sempre que necessário. No entanto, (Astels, 2003) define três situações em que precisamos refatorar:

• quando há duplicação;
• quando percebemos que o código e / ou a sua intenção não é clara;
• quando se detectar códigos cheiros, ou seja, sutis (ou não tão sutil) indícios de que há um problema.

Referências:

Astels, David. 2003. Test-Driven Development: A Practical Guide. s.l. : Prentice Hall, 2003.

Manter a capacidade evolutiva da arquitetura de um sistema vai além de definir um modelo de arquitetura, um conjunto de padrões e adotar boas práticas beneficiando-se do avanço das tecnologias e ferramentas de desenvolvimento. A equipe de desenvolvimento deve adotar práticas que ajudem a manter a capacidade evolutiva do software.

Tão rápido quanto o Movimento Ágil tem crescido, essas práticas vieram evoluindo. Algumas, a partir de práticas ágeis, antes focados no desenvolvedor, que se expandiram para incluir outros interessados como a equipe de qualidade e os gerentes de projetos entre outros.

Baseado neste sucesso, essas práticas estão agora sendo aplicadas em projetos de todos os tipos, Ágeis e Não-Ágeis, igualmente.

Os próximos posts serão sobre algumas dessas práticas, entre elas:

• Orientação a Testes
• Refatoração
• Integração Contínua.