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.

• você mantenha um exaustivo conjunto de Testes Automatizados;
• nenhum código entra em produção a menos que tenha um teste associado;
• você escreve primeiro os testes;
• os testes determinam o código que você deve escrever.

No estudo publicado por (Aniche, 2010), baseado em experimentos na indústria e na academia. Ele mostra que TDD melhora o processo de desenvolvimento, aumenta a qualidades do código produzido, reduz o número de defeitos, diminui o tempo gasto com depuração e até aumenta a produtividade dos desenvolvedores.

Manter um exaustivo conjunto de Testes Automatizados

Os Testes Automatizados testam se suas classes produzem o comportamento esperado. Embora sejam semelhantes aos Testes Unitários, eles são escritos por um motivo diferente. Os Testes Unitários são escritos para verificar se o código que foi escrito funciona. Testes Automatizados são escritos para definir o que esse código deve fazer.

Praticar TDD implica, em ter um exaustivo conjunto de testes. Isso porque para cada linha de código deve ter sido escrita como resposta a um teste. O que gera um conjunto exaustivo de testes.

Nenhum código entra em produção a menos que tenha alguns testes associados

Uma característica não existe até que haja um conjunto de testes para acompanha-la. Isso traz confiança e coragem para refatorar e integrar.

Escreva primeiro os testes

O teste define o que se espera do código produzido. Então, escreve-se um pequeno teste e apenas o código suficiente para fazê-lo passar, então um pouco mais de teste e um pouco mais de código, teste e código, etc.

Os testes determinam o código que você deve escrever

Escrever apenas o suficiente para passar no teste implica em fazer a coisa mais simples que possa funcionar, limitando o código que será produzido.

Referências:

Aniche, Mauricio. 2010. TDD realmente ajuda? www.aniche.com.br. [Online] 04 16, 2010. [Cited: 09 18, 2010.] http://www.aniche.com.br/2010/04/tdd-realmente-ajuda/.
Astels, David. 2003. Test-Driven Development: A Practical Guide. s.l. : Prentice Hall, 2003.

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.

Segundo (Fowler, 2001) em seu artigo, o acoplamento geralmente ocorre quando uma camada da aplicação precisa acessar outra camada, seja para executar métodos ou acessar algum dado. (Gamma, 2005) falou em sua entrevista sobre os dois principais pontos referentes a um baixo acoplamento: “programe para uma interface, não para uma implementação” e “prefira uma composição de objetos a uma herança”.

Além disso, entre os vários tipos de coesão. Dois dos mais utilizados são a coesão comunicacional e coesão funcional. A coesão comunicacional é quando partes do módulo operam os mesmos dados. Faz sentido agrupá-los, porque existe uma forte relação entre eles. A coesão funcional é quando todas as partes do módulo trabalham em conjunto para executar uma tarefa bem definida. Este é considerado o melhor tipo de coesão.

Referências:

Reducing Coupling. Fowler, Martin. 2001. Julho/Agosto 2001, IEEE Software, pp. 102-104.
Gamma, Erich. 2005. Design Principles from Design Patterns. [interv.] Bill Venners. Junho 06, 2005.

Também, (Avram, et al., 2006) destacam ainda que um modelo correto pode não ser expresso em código ou acabar quebrando algum princípio de arquitetura de software. Diante disso, é preciso definir um modelo que seja fácil e precisamente codificado.

A questão fundamental aqui é: como vamos abordar a transição do modelo para o código?

Vale ressaltar que um dos principais problemas das arquiteturas é que os arquitetos não conseguem prever todos os possíveis cenários e detalhes de um domínio. Detalhes muito importantes são descobertos durante a implementação e um modelo válido para o domínio poderá apresentar sérios problemas com a persistência ou mesmo um desempenho inaceitável entre outros.

Sendo assim, a arquitetura deve evoluir durante o processo ou os desenvolvedores serão obrigados a tomar algumas decisões por conta própria, fazendo alterações na arquitetura a fim de resolver problemas reais que não foram considerados quando o modelo foi criado.

Dessa forma, (Evans, 2003) sugere que para manter a consistência entre o modelo e sua implementação são necessárias ferramentas de desenvolvimento e linguagens que suportem o paradigma de modelagem que está sendo proposto.

Diante disso, a programação orienta a objetos é adequada para a implementação do modelo de domínio porque ambos são baseados no mesmo paradigma fornecendo classes de objetos, associações e troca de mensagens entre eles, mapeando diretamente os objetos do modelo.

Referências:

Evans, Eric. 2003. Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston : Addison-Wesley Professional, 2003.
Avram, Abel and Marinescu, Floyd. 2006. Domain-Driven Design Quickly. 2006.

Em seu trabalho, (Avram, et al., 2006) destaca que o desenvolvimento de software é, na maior parte dos casos, utilizado para automação de processos ou resolver problemas de negócio. Os processos de negócio ou problemas a serem resolvidos são o domínio do software. Nós temos que entender, desde o início, que o software é derivado deste domínio e está diretamente relacionado a ele.

Em suma, o software deve seguir o modelo do domínio. Essa é a melhor maneira de fazer o software refletir um domínio específico. Ele precisa incorporar os conceitos fundamentais e os elementos do domínio, percebendo as relações entre eles.

Arquitetura Centrada nos Dados

Podemos observar que devido à impedância entre os mundos objeto e relacional, é comum encontrarmos soluções de arquitetura onde o domínio da aplicação está fortemente acoplado a camada de acesso a dados. Essa é uma questão encontrada principalmente quando uma abordagem de arquitetura centrada nos dados é utilizada.

Nessa abordagem, a modelagem da estrutura dos dados é a peça central. O banco de dados é a parte mais importante dessa arquitetura e o Administrador de Dados desempenha um papel fundamental.

No entanto, uma abordagem centrada nos dados pode ser bem utilizada quando temos um cenário para aplicações de formulários sobre dados que não envolvam processos de negócio complexos.

Arquitetura Orientada a Domínio

Como (Avram, et al., 2006) definem, a Arquitetura Orientada a Domínio combina arquitetura e práticas de desenvolvimento. Dentre tantos fatores, eles destacam como a arquitetura e o desenvolvimento podem trabalhar juntos para criar uma solução melhor.

Dessa maneira, uma boa arquitetura vai acelerar o desenvolvimento, enquanto o feedback proveniente do processo de desenvolvimento irá melhorar a arquitetura.

Referências:

Avram, Abel and Marinescu, Floyd. 2006. Domain Driven Design Quickly. 2006.

Nessa abordagem, a arquitetura de software deve adotar práticas que ajudem a definir uma estratégia de arquitetura evolutiva. Como @KentBeck observa, a arquitetura existe para possibilitar a evolução do software, com facilidade, a longo prazo.

Uma arquitetura deteriorada prejudica a capacidade de implementar mudanças com segurança. Nesse estado de entropia do software, com o tempo a arquitetura piora ainda mais. O software fica difícil de manter e vulnerável a bugs cada vez piores de serem identificados e corrigidos. Nesse processo de “codifica-remenda”, com o passar do tempo, os bugs tornam-se exponencialmente mais caros de corrigir.

Diante disso, como planejar uma estratégia de arquitetura capaz de evoluir junto com o código?

Definir um modelo de Arquitetura Orientada ao Domínio, um conjunto de padrões de arquitetura para aplicações corporativas, adotar boas práticas e beneficiar-se do avanço das tecnologias e ferramentas de desenvolvimento irá nos guiar no planejamento de uma estratégia de arquitetura evolutiva capaz de suportar o processo de desenvolvimento ágil.

Referências:

Is Design Dead? por Martin Fowler
Agile Brazil Keynotes por Martin Fowler

Não sou o dono da verdade mas tenho a minha maneira de fazer as coisas. Estou sempre aprendendo coisas novas e fazendo as coisas da maneira que acho certa. Bem, nem sempre elas estarão certas mas será sempre o melhor que eu posso fazer. Então essa é a minha maneira de fazer as coisas!