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

quarta-feira, 3 de setembro de 2014

TDD. O que é, e como inicio no PHP

    TDD Desenvolvimento Baseado em Testes
    Hoje inicio uma série de artigos referentes ao TDD. Farei um apanhado de várias bibliografias com o intuito de agrupar importante conhecimentos e encorajar mais desenvolvedores a atuarem por esta solução. A ideia é tentar ser o mais prático possível, encontrei diversas teorias em artigos em português, mas a prática mesmo é encontrada em artigos em inglês. Pois tenho visto poucos desenvolvedores realmente atuando com este paradigma.

    O que é Test Driven Development - TDD.
    Em português quer dizer Desenvolvimento orientado a teste. A ideia, segundo Kent Beck, que é considerado um de seus inventores, é: 
  • Não escreva uma linha de código a menos que você tenha escrito um teste de acerto e um teste de falha para a funcionalidade;
  • Elimine as duplicações
    Vantagens
    A grande vantagem é que os testes contém asserções que podem ser verdadeiras ou falsas. Após as mesmas serem consideradas verdadeiras os testes confirmam o comportamento correto, permitindo os desenvolvedores evoluir e refatorar o código.

    Como iniciar
    Vou fazer um breve roteiro de instalação do phpUnit, e do X-debug, que considero ser uma forma de iniciar o Desenvolvimento orientado a testes no PHP. Fiz um roteiro para debiam. Verifique como funcionará no seu sistema operacional.
  • Baixe o PHPUnit
wget https://phar.phpunit.de/phpunit.phar
  • Mude a permissão
chmod +x phpunit.phar
  • Mover para o bim
mv phpunit.phar /usr/bin/phpunit
  • Pegamos o Composer
php -r "readfile('https://getcomposer.org/installer');" | php
  • Escrever o composer.json
vim composer.json

{
    "require-dev": {
            "phpunit/phpunit": "4.2.*",
            "phpunit/php-invoker": "*",
            "phpunit/dbunit": ">=1.2"
    },
    "autoload": {
            "classmap": [
                "src"
            ]
}
}
  • Rode o composer
composer install || composer update
  • Instale o X-Debug
apt-get install php5-dev php-pear // PECL estará neste pacote

pecl install xdebug

  • Acesse o PHP.ini e configure o X-Debug inserindo estas linhas:

zend_extension=/usr/lib/php5/20100525/xdebug.so

xdebug.remote_enable=on

xdebug.remote_handler=dbgp

xdebug.remote_host=localhost
xdebug.remote_port=9000

Conclusão
Este seria um pequeno roteiro de instalação do PHPUnit, esta instalação seria apenas para os sistemas Debian. Se este não for seus sistema operacional, pegue um tutorial para instalação no seu Sistema Operacional ou considere as adaptações, a parte mais importante é acostumar a escrever os testes antes de escrever o código. Iremos testar alguns exemplos de aplicação nos próximos tutoriais.

Referências
https://phpunit.de/manual/current/en/installation.html
http://tableless.com.br/phpunit-como-iniciar-sem-dores/
http://br.phptherightway.com/#xdebug
http://xdebug.org/docs/install
Test-Driven Development By Example - Kent Beck
http://blog.thiagobelem.net/aprendendo-tdd-ou-desenvolvimento-orientado-a-testes/

segunda-feira, 10 de novembro de 2008

Um Pouco de teoria. O que é SOA?

SOA é Service Oriented Architecture - descreve duas coisas distintas. As duas primeiras expressam uma metodologia para desenvolvimento de software. A terceira palavra é um panorama de todos os ativos de software de uma empresa. SOA é uma linguagem orientada à serviço. Trata-se de um conceito. É uma metodologia que permite a integração de novos sistemas com sistemas antigos. Um estilo de arquitetura de software cujo princípio preconiza que as funcionalidades implementadas devem ser disponibilizadas na forma de serviço disponibilizados via web.
Além da perspectivas estritamente técnico, a arquitetura orientada a serviço também se relaciona com determinadas políticas e conjuntos de "boas práticas" que pretendem criar um processo para facilitar a tarefa de encontrar e gerenciar os serviços disponibilizados.
Sua grande vantagem é a redução do tempo no desenvolvimento das novas aplicações de negócios. Neste caso os prazos são encurtados porque a área técnica não parte do zero, já que sua filosofia prega a integração entre diferentes tecnologias.
No ponto de vista de SOA, o serviço é uma função de um sistema computacional que é disponibilizado para outro sistema. Sendo que funcione independente do estado de outros e possuindo uma interface bem definida. Normalmente, a comunicação entre o sistema cliente e aquele que disponibiliza o serviço é realizada através de web service.
Serviços são porções de software construídas de forma que possam ser facilmente vinculadas a outros componentes. No centro deste conceito esta a idéia de que é possível definir partes dos códigos de software em porções significativas o suficiente para serem compartilhadas e reutilizadas em diversas áreas da empresa, automatizando assim algumas tarefas
A revolução da SOA está mudando o modo como pensamos que os negócios podem ser estruturados e gerenciados. Mas será preciso mais do que apenas tecnologia para chegarmos à empresa do futuro. Na verdade, a adoção da SOA está criando novos desafios sobre como a orientação de serviços deveria ser governada, como deveria ser adotada, como afeta culturalmente uma organização e outras questões. Com a abordagem, as ferramentas e os recursos certos, a empresa do futuro pode estar aqui mais rápido do que você imagina.

Projeto Imóveis

  Esta é minha primeira postagem. Por isso, venho discursar um pouco do que aprendi nestes anos. Alguns projetos desenvolvidos.
  Trabalho com programação desde 2005, atuo já com desenvolvimento desde sistemas simples até sistemas complexos. O mais recente e mais gostoso de ser feito foi o projeto de uma imobiliária virtual.
 Este trabalho começou a ser projetado quando procurava um imóvel e não achava um lugar onde tivéssemos tudo centralizado. Para encontrar algo, precisava buscar diversos sites, e diversas imobiliárias.
 Assim a missão do site (que hoje se encontra pronto), é de unir todos os imóveis em um só lugar. para tal o site http://imoveis.mundobrasil.com.br , indexa imóveis das maiores imobiliárias do pais, mas também recebe anúncios de imóveis. podendo optar por planos de maior destaque, ou de destaque convencional. Os parceiros indexados, também podem optar por planos de maiores destaques, e assim firmar parcerias para que possam aparecer na frente.