terça-feira, 13 de janeiro de 2015

TDD. O que é, e como inicio no PHP Parte II

TDD Conceitos Importantes

Introdução
    Em algumas postagens anteriores fiz a primeira parte desta série de artigos. A primeira praticamente ensinava uma das várias formas de instalação que para o phpunit e o xdebug. Agora vamos entender alguns conceitos do TDD

Argumentação para o TDD
    No TDD sempre devemos iniciar com os testes. Isso nos obriga a pensar exatamente o que desejamos que este pedaço do sistema execute. Acredito que uma boa forma de utiliza-lo é junto com alguma ferramenta ágil, como o scrum - por exemplo. O importante em dividir seu sistema em uma parte testável do dele, inicialmente criar o teste, e depois o código para que o teste passe. Resolvido esta parte podemos evoluir o código.
    Qualidade do código
    Um dos principais ensinamentos do TDD é que se algo não puder ser testado, este foi desenvolvido errado. Em pouco tempo utilizando testes começará a desenvolver de forma visivelmente diferente, ajudando o programador a desenvolver um código cada vez com mais qualidade. Pois, para atuar com o TDD, o programador é obrigado a forçar seu raciocínio de forma mais elevada para que o código tenha menos acoplamento e dependência.
    Documentação
    Os testes acabam sendo uma excelente documentação do software. Pois ao rodar o teste no modo verbose, uma "história" é contada do software que poderá ajudar a criar a documentação.
    Testes manuais custam caro
    Sem os teste unitários, a validação para garantir a integridade do software é praticamente impossível, pois o testes deveria testar todos os fluxos possíveis em diversas situações, para encontrar possíveis erros. Com os testes unitários, sobra apenas os testes mais práticos do fluxo que realmente foi alterado.

Passos do TDD
    O TDD baseia-se em três passos, vermelho, verde e refatora. O vermelho é o início, quando você apenas criou o teste, assim ainda não existe a classe a ser testada, e consequentemente o teste não passará. O verde é o momento em que a lógica criada passou no teste, assim o código já esta funcional, mas ainda carece de melhoras. Esta melhora ocorre na parte do refatoramento, que é a melhoria do código, onde se remove duplicações e o código vai ficando mais próximo de sua versão final. É importante em cada alteração do código, passar o teste, para garantir que a mudança não interferiu em seu funcionamento.
    Para o correto funcionamento é utilizado um conceito chamado baby steps ou passos de bebê, que consiste em realizar pequenos passos de um processo complexos. Para isso devemos utilizar os seguintes princípios:
  • Os testes precisam ser rápidos;
  • Devem ser isolados, devemos testar apenas uma unidade do sistema. O ideal é que os fatores externos não interfiram na unidade.
  • Devem funcionar em qualquer ordem ou em qualquer valor. 
  • Não deve ser interferido manualmente, devem funcionar sozinhos.
  • O código deve ser desenvolvido após desenvolver o teste.
Conclusão
    Como vimos o Desenvolvimento baseado em testes é de vital importância para melhoria do código, refatoração sem erros, e facilitação da manutenção do sistema. Nos próximos artigos veremos como atuar mais na prática.

segunda-feira, 12 de janeiro de 2015

Domain Driven Design

        Diferenças entre Domain Driven Design e Model Drinven Design


Significa Projeto Orientado a Domínio e veio do livro escrito por Eric Evans. Como diz o Wikipedia é uma abordagem de desenvolvimento de software para as necessidades complexas, fechando a lacuna entre a realidade do negócio e o código.
A ideia principal do DDD é capturar o modelo para o código. Mantendo seu software voltado para o problema e não restrito à solução. Assim quando você procura algo importante sobre o domínio você saberá exatamente onde está.

Linguagem Ubíqua
É uma linguagem comum, com termos bem definidos, que fazem parte do processo de desenvolvimento. É importante para que todos falem a mesma língua, baseado na informação que puder conseguir do cliente. Como exemplo, se um cliente chama o dinheiro do caixa de numerário, sempre que nos referenciarmos ao dinheiro do caixa no software e nas reuniões, ele será numerário. Assim evita erros de interpretação.
É importante que todos os membros dentro do projeto estejam comprometidos com a linguagem Ubíqua, e tentar readequar sempre que for percebido que um termo tem mais de um significado.
Apenas desta forma poderemos ter o modelo abstrato como uma representação perfeita do domínio.

Model Driven Design (MDD)
A ideia por trás do MDD é a de que o seu modelo abstrato deve ser a representação perfeita do seu domínio. Seu processo de maturação deve ser contínuo. Este modelo servirá de guia para a criação do código e, ao mesmo tempo, o código ajuda a aperfeiçoar o modelo. Este contato contínuo trará aos programadores um insights para a refatoração.

Blocos de Construção do MDD
Precisamos isolar o modelo das demais partes. Essa separação sera feira utilizando-se de arquitetura em camadas:

  • Interface de Usuário: É a parte de interação com o usuário e interpretação dos seus comandos;
  • Aplicação: É uma camada sem lógica de negócio, responsável por conectar a interface as camadas inferiores
  • Domínio: Responsável por toda a regra de negócio, Todo o foco do DDD esta aqui. 
  • Infra-estrutura: Responsável por fornecer os recursos para suporte as camadas superiores. São as partes de dados e persistência em geral.

Conclusão
Diante desta introdução ao DDD percebe-se que a ideia que gira em seu turno, e montar sua aplicação baseada no que o cliente deseja. Compreendendo exatamente as funções do sistema, abrangendo esta compreensão inclusive na linguagem utilizada pelo cliente. Fica evidente também que o MDD (Model Driven Design) é a parte maior, e uma das camadas (a camada de lógica) é que abrange o DDD (Domain Driven Design)

Referências
http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/
http://en.wikipedia.org/wiki/Domain-driven_design
http://www.agileandart.com/portfolio/mdd-model-driven-design/
http://msdn.microsoft.com/pt-br/magazine/dd419654.aspx
http://www.inf.ufsc.br/~ricardo/publications/Asoo97.pdf