Agile vs Fragile

Test Driven Development (TDD) em PHP

Neste post vamos abordar o Test Driven Development (TDD) em PHP, que é um dos principios core do XP e está disponivel nativo para linguagem java no netbeans. Entretanto, para habilitar essa ferramenta para o PHP no ambiente Windows devemos fazer algumas configurações no ambiente que seguem:

1. Instalar o NetBeans;
2. Instalar o Xampp;
3. Configurar o PHPUnit pelo pear no xampp com os seguintes comandos:
4. Abrir o Shell;
5. Digitar “pear config-set auto_discover 1”
6. Digitar “pear install pear.phpunit.de/PHPUnit”
7. Agora o PHPUnit já está configurado na pasta c:\xampp\php\
8. Baixar o arquivo phpunit.phar em https://phar.phpunit.de/phpunit.phar
9. Baixar o arquivo phpunit-skelgen.phar em https://phar.phpunit.de/phpunit-skelgen.phar
10. Salvar os dois arquivos em c:\xampp\php\
11. Para configurar o phpunit no netbeans faça o seguinte:
1. Vá em ferramentas;
2. Em opções aponte os arquivos conforme as imagens abaixo:

Agora o NetBeans já está configurado para aceitar projetos com a criação de classes de testes. A proxima etapa é criar um novo projeto PHP. Com o projeto criado deve-se criar a classe PHP que será desenvolvida a partir de testes. Agora deve-se criar os testes. Clique com o botão direito sobre a pasta “Arquivos de Código-Fonte” ir em “Ferramentas” e depois “Criar Testes”.

Deve-se criar uma pasta de testes dentro do projeto, onde serão geradas as classes de testes pelo skelgen, e durante o assistente de criação dos testes assinalar a opção de utilizar o PHPUnit.

O ultimo passo é criar a classe de testes, que é criada automaticamente clicando com o botão direito em cima do arquivo da classe PHP, que foi criada anteriormente e onde serão desenvolvidos os métodos,  ir em “Ferramentas” e depois “Criar Testes”.

Agora o arquivo o testes já foi criado, só tem que ter cuidado de sempre começar o método de testes começando com “testAlgumaCoisa”, segue abaixo uma sugestão de código para as classes onde estarão os métodos e onde estarão os testes:

Salario.php

<?php

/*

* To change this license header, choose License Headers in Project Properties.

* To change this template file, choose Tools | Templates

* and open the template in the editor.

*/

/**

* Description of Salario

*

* @author GUSTAVO

*/

class Salario {

   //put your code here

   

   public function index($bonus = null){

       $salario =  1500.35;

       

       if($bonus){

           $salario += $bonus;

       }

       

       return $salario;

   }

   

   public function desconto($salario){

       

       $desconto = 8;

       

       if(($salario > 1317.07) and ($salario < 2195.13)){

           $desconto = 9;

       } elseif($salario > 2195.12){

           $desconto = 11;

       }

       

       return $desconto;

   }

   public function descontoINSS($salario) {

       

       if($salario > 4390.24){

           $salario = 4390.24;

       }

       

       $percentual = $this->desconto($salario);

       

       $desconto = $salario * $percentual / 100;

       

       return number_format($desconto, 2);

   }

}

SalarioTest.php

<?php

require_once "../Salario.php";

/**

* Generated by PHPUnit_SkeletonGenerator on 2014-10-21 at 14:01:05.

*/

class SalarioTest extends PHPUnit_Framework_TestCase

{

   /**

    * @covers Salario::index

    * @todo   Implement testIndex().

    */

   public function testIndex(){

       $salario = new Salario();

       $this->assertEquals(1500.35, $salario->index());

   }

   

   public function testIndexComBonus(){

       $salario = new Salario();

       $this->assertEquals(1550.35, $salario->index(50));

   }

   public function testDesconto(){

       $salario = new Salario();

       $this->assertEquals(11, $salario->desconto(10000));

   }

   

   public function testValorINSSMinimo(){

       $salario = new Salario();

       $this->assertEquals(80, $salario->descontoINSS(1000));

   }

   

   public function testValorINSSMedio(){

       $salario = new Salario();

       $this->assertEquals(180, $salario->descontoINSS(2000));

   }

   

   public function testValorINSSAlto(){

       $salario = new Salario();

       $this->assertEquals(440, $salario->descontoINSS(4000));

   }

   

   public function testValorINSSTeto(){

       $salario = new Salario();

       $this->assertEquals(482.93, $salario->descontoINSS(9390.24));

   }

}

Resumindo o Disciplined Agile Delivery

Livro do Scott W. Ambler sobre a metodologia aplicada na IBM.

Essa metodologia de trabalho promove uma colaboração entre os desenvolvedores e os contratantes do software. Este método visa a adicionar valor à organização, mantendo a agilidade e se focando na qualidade do sistema a ser entregue (e.g., work smarter, not harder).

Não deveria ser uma surpresa que trabalhar em uma equipe unida e colaborativa que visa a produzir software em funcionamento obtém melhores resultados do que times que trabalham em locais separados onde se importam somente em sucesso individual ao invés do desempenho de equipe. Também não seria uma surpresa que reduzir documentação e a burocracia administrativa reduziria custos e diminuiria o tempo de entrega do produto.

Utilizar metodologias ágeis não é desculpa para ser indisciplinado. A execução destas novas metodologias, como XP, por exemplo, sempre demandaram uma abordagem disciplinada, e certamente muito mais do que as metodologias tradicionais como waterfall. Não se deve misturar o alto nível de burocracia e controle dos métodos tradicionais como sinal de disciplina.

Pessoas em Primeiro Lugar

O DAD promove uma busca para ajudar os times de desenvolvimento a melhorar sua efetividade, entretanto não prescreve procedimentos obrigatórios para se chegar neste objetivo.

Alguma documentação será exigida, mas raramente tanto quanto é exigida nos métodos tradicionais. A integração entre pessoas (clientes e desenvolvedores) dá oportunidades para sanar mal-entendidos e diminuir os defeitos dos sistemas a serem entregas, o que é tratado na cultura de prevenção de desperdícios da metodologia Lean. Pois quando criamos um documento raramente pomos no papel nosso completo entendimento do que estamos descrevendo, e inevitavelmente algum conhecimento é ‘deixado para traz’ eis o que o conhecimento tácito não é passado adiante.

Os membros de um time que aplica a metodologia DAD devem possuir os seguintes atributos:

•   Disciplina para se comprometer apenas com o trabalho que conseguem realizar e trabalhar da melhor maneira possível para realizar o seu trabalho;
• Organização para estimar e planejar o seu trabalho de uma maneira que possam realizar entregas constantes;
• Autodidata para identificar o que melhor funciona para si e o que não funciona, tendo oportunidade de aprender e se ajustar.

Metodologias Ágeis

Times de desenvolvimento que buscam trabalhar de maneira iterativa tem mostrado que produzem soluções de maior qualidade, proporcionando um maior retorno do investimento, bem como a satisfação dos clientes e entregando as soluções mais rápido que as abordagens tradicionais, como a waterfall. A satisfação dos clientes está diretamente ligada a participação deles no projeto durante cada iteração, e em conjunto com eles melhorando os requisitos do software que será desenvolvido no final do projeto.

Processo Hibrido de Desenvolvimento

DAD é um conjunto de diversas estratégias e praticas de tanto de metodologias ágeis quanto dos métodos tradicionais. No DAD é utilizado o ciclo de vida do Scrum adotando entregas continuas de software bem como utilizando técnicas Lean de desenvolvimento. Muitas das praticas sugeridas pelo DAD são comumente discutidas na comunidade ágil, tais como integração contínua, reuniões diárias e refatoração bem como algumas praticam avançadas que são muito aplicadas, porém pouco discutidas por alguma razão. São, dentre outras, o levantamento inicial de requisitos, estudo da arquitetura a ser utilizada, e testes no final do ciclo de desenvolvimento.

Consciência Empresarial

Os times DAD trabalham dentro do seu ecossistema empresarial, assim como outros times, e visam a aproveitar as vantagens apresentadas a eles – personificando o clichê: “agir localmente e pensar globalmente”. Em outras palavras, os times DAD devem adotar como mentalidade ‘a empresa como um todo’.

Ter uma consciência empresarial é importante que os times busquem, como profissionais, o que é melhor para organização e não somente o que lhes interessa.

Foco no Risco e Valor

DAD adota um ciclo de vida voltado ao chamado foco no risco e valor, o que é muito comum nos métodos ágeis como Scrum e XP. Trabalhando com foco no risco e valor o time acaba produzindo material entregável em cada iteração, ou mais precisamente a partir da perspectiva do DAD, um material potencialmente consumível em cada iteração. Essas entregas representam aqueles que tem maior valor na perspectiva dos clientes. Deve ser considerado também o risco de entrega nos itens de alta prioridade e não somente os de maior valor. Sempre tomando cuidado com os três principais riscos:

1.       O risco de não entregar nada;

2.       O risco de entregar o software sem funcionalidade;

3.       O risco político de ter pouca visibilidade sobre o que o time esta produzindo.

Conclusão

Disciplined Agile Delivery (DAD) é um processo hibrido que combina as praticas e estratégias do Scrum, Extreme Programming (XP) e Agile Modeling (AM) e complementa com algumas outras, como Agile Data e Kanban, adotando um ciclo de vida de entrega total.

Disciplined Agile Delivery – Scott W. Ambler

Essa postagem é uma introdução ao livro do Scott Ambler, que trata de DAD.

Scott Ambler percebeu que a realidade de muitas empresas era algo parecido com uma water-scrum-fall, na forma de que a maioria das empresas não aceitava iniciar seus projetos sem que antes tenham uma lenta fase de definição de requisitos, planejamento detalhado do projeto e até fazendo algum design. Essa abordagem não é de todo mal, ela permite que as empresas se beneficiem de práticas ágeis, como trabalho iterativo, desenvolvimento voltado a testes e entregas contínuas. Entretanto não é liberado todo o potencial da abordagem ágil. Empresas ágeis não somente criam os softwares de maneira mais eficiente, mas o mais importante é que entregam um software com grande valor de negocio.  

Porque Disciplined Agile Delivery?

Está constatado que métodos ágeis, como Scrum, funcionam muito bem para times de pequenos projetos, onde são trabalhados problemas com baixo risco ou consequências de falhas. Entretanto, esses métodos não trazem segurança para projetos de maior escala, e o resultado acaba sendo que as empresas investem muito esforço criando processos híbridos, combinando metodologias de diferentes fontes. O processo Disciplined Agile Delivery (DAD), como é descrito no livro do Scott Ambler, é uma abordagem hibrida, que busca técnicas do Scrum, Agile Modeling, EX, Unified Process e Kanban dentre outras metodologias. O processo do DAD inclui praticas que estão faltantes no Scrun e XP como modelagem e documentação. O mais importante é que o DAD permite que o processo seja ajustado efetivamente as necessidades da situação em que você se encontra. Descrevendo o que funciona e o que não funciona, e o mais importante porque, o DAD ajuda a aumentar as chances de adotar estratégias que vão funcionar para você. 

Bad Smell

- 4 características que eu considero essenciais, presentes em um código ruim:

Código duplicado: Esse smell geralmente acontece quando temos uma classe god, e acabamos escrevendo duas ou mais vezes a mesma lógica, que poderia ser escrita uma vez só, caso aplicássemos as regras de orientação a objetos e polimorfismo.  Nesse caso é gerado código muito grande e desnecessário.

Lista de parâmetros longa: Essa regra é muito utilizada quando começamos a programar, mas pode causar um transtorno quando não vamos utilizar todos os parâmetros, bem como dificulta o entendimento do código. A ideia de passar um objeto ao invés de parâmetros.

Classes alternativas com diferentes interfaces: Esse smell é gerado quando temos duas ou mais classes que fazem (ou fazem quase) a mesma coisa, porém com nomes diferentes.

Classe de dados: São classes que só contem atributos (getters e setters), que geralmente são acessadas e manipuladas por outras classes. Geralmente são nada mais que depósitos de dados

- 4 características que eu considero essenciais, presentes em um código bom:

Nomes significativos: Usar nomes nos atributos e métodos que transcrevam o modelo de design ajuda na manutenção e no entendimento do código por outros desenvolvedores.

Indentação de código: Deixar o código bem organizado e ter um padrão a ser seguido pelo time é essencial para o bom entendimento da estrutura lógica do código.

Uso de Exceções: Além de deixar o código mais legível, previne o código contra falhas nos tratamentos de arquivos, entradas de dados inválidas, erros de consultas à base de dados, entre outras.

Test Driven Development:  Ajuda a focar no resultado final, e nos garante uma refatoração mais segura das classes, garantindo que ao alterar um método, todos os requisitos do software serão atendidos, sem a necessidade de testar os mesmos a cada mudança, deixando essa parte automatizada.

Domain Driven Design 3

Este é o ultimo post sobre DDD, onde farei o resumo do capítulo 3 do livro Domain Driven Design Quickly, que pode ser baixado gratuitamente na InfoQ:

http://www.infoq.com/minibooks/domain-driven-design-quickly

Para a criação de um modelo correto, que venha realmente a capturar as regras do domínio, os analistas de software e os peritos no domínio se reúnem por meses, para descobrir os elementos fundamentais do domínio, enfatizando os relacionamentos. Os desenvolvedores podem vir a se juntar ao time para verificar a possibilidade de expressar no código esses conceitos e relacionamentos desenhados no modelo. Assim começa a criação de um modelo, com inspiração no modelo original, adicionando algumas ideias da equipe técnica.

Uma técnica muito utilizada é a criação do modelo de análise, que é separado do código e feito por pessoas diferentes. Neste modelo temos ênfase na regra de negocio, e nenhuma ênfase na codificação a ser implementada no software. É gerado certo nível de conhecimento a respeito do software a ser desenvolvido. Com base nesse modelo, os desenvolvedores irão adapta-lo para um modelo que irá guiar a equipe de desenvolvimento.

Um dos principais problemas dessa técnica é que como os analistas não conseguem enxergar além das regras de negócios, o modelo pode se aprofundar em determinadas questões que não irão ser tão pertinentes para a regra de desenvolvimento. E podem esquecer outros pontos, que podem vir a ser importante para elucidação da equipe de desenvolvimento.

Em razão desta falta de documentação, os desenvolvedores terão que tomar algumas decisões por sua conta, que visarão resolver ou solucionar algum problema real que não foi considerado no modelo criado e acabam criando um modelo que foge um pouco do modelo original.

Normalmente os analistas têm reuniões fechadas, onde discutem a respeito do modelo a ser desenvolvido, e neste momento muita informação valiosa é compartilhada nessas reuniões. Eles criam um modelo que supostamente contem toda informação de uma maneira condensada, e os desenvolvedores deverão assimilar essa informação lendo a documentação que lhes foi dada. Uma sugestão é que seria muito mais produtivo que os desenvolvedores participassem dessas reuniões com os analistas para conseguir capturar um melhor conhecimento da regra negocio e poderem desenhar um modelo mais completo.

Uma melhor abordagem é relacionar o domínio de modelo com o design. O modelo deve ser desenhado com foco no desenvolvimento do software e nas considerações de design. Os desenvolvedores devem ser incluídos no processo de modelagem. A ideia principal é escrever um modelo que melhor expressa o software a ser desenvolvido, deixando ele fortemente relacionado com a codificação a ser escrita, e consequentemente tornando o modelo mais relevante.

Manter os desenvolvedores envolvidos neste processo ocasiona feedback por parte dos mesmos. Acaba gerando uma segurança de que o modelo poderá ser implementado no software. Se algo estiver errado, poderá ser identificado logo, e o problema será facilmente corrigido.

É importante que todo time técnico, responsável por desenvolver e manter o código tenha algum contato com o modelo. Todos tem ter algum nível de contato e discussão a respeito do modelo e com os especialistas na regra de negocio.  Esse envolvimento entre todas as partes interessados ajudaram a criar a Ubiquitous Language.

Programação Orientada a Objetos é a mais adequada e que mais combina com a implementação de modelo. Ambas se baseiam nos mesmos paradigmas. O desenvolvimento OO trabalha com classes de objetos, associações entre as classes e instancias de objetos. Linguagens OO torna possível a criação de mapeamentos diretos entre objetos do modelo com seus relacionamentos.

Domain Driven Design 2

Neste post farei o resumo do capítulo 2 do livro Domain Driven Design Quickly, que pode ser baixado gratuitamente na InfoQ:

http://www.infoq.com/minibooks/domain-driven-design-quickly

Existe uma grande diferença entre a mentalidade de desenvolvedores e analistas de negocio. Os desenvolvedores costumam pensar e imaginar o sistema na forma de classes, métodos, algoritmos, e tendem sempre a fazer uma ligação entre os conceitos do mundo real com os conceitos de relações e modelagens. Eles pensam em termos de herança, polimorfismo, Orientação a Objetos, etc,... Já os especialistas no negocio não entendem nada a respeito de bibliotecas, frameworks, persistências, e, em muitos casos, não conhecem até mesmo banco de dados. Eles sabem somente a respeito das regras do negócio.

Um dos princípios fundamentais do DDD é usar uma linguagem focada no modelo, e é sugerido que esta linguagem seja adotada em comum tanto para documentação quanto para programação. Este princípio é essencial para integração entre os especialistas de negocio e desenvolvedores.

Quando o time como um todo começa a usar essa linguagem comum em todas as partes do projeto, tanto para se comunicar, como documentar e desenvolver, acabam gerando uma linguagem conhecida no DDD como Ubiquitous Language.

Essa linguagem em comum cria a premissa de que toda a equipe, ao usar a mesma linguagem, irá descobrir ao longo dos meses, como o sistema deverá funcionar e ajudará a descobrir inconsistências e conceitos inadequados no design.

Para tanto, os especialistas no negócio deverão se opor a termos técnicos ou difíceis de entender no modelo de negocio. Se no modelo tiver algum termo que eles não consigam entender, então provavelmente algo está errado. Assim como os desenvolvedores devem ficar atentos a inconsistências ou ambiguidades no modelo.

Ao escrever o código usando a Ubiquitous Language para criação de classes, métodos e atributos estará sendo feita uma ligação entre o modelo e código. Esta prática vem a ser de extrema utilidade, visto que torna o código muito mais legível, e auxiliará, posteriormente, nas alterações do código conforme o crescimento do projeto.

Uma maneira eficaz para expressar classes, atributos e relacionamentos é através da UML, entretanto, o comportamento entre as classes não é tão facilmente expressado através desta documentação. Entretanto, pode-se utilizar de notações no diagrama para tentar explicar o comportamento esperado dos objetos. Esta documentação explicativa pode vir através de pequenos diagramas de uma parte do modelo contendo a explicação necessária. Nestes diagramas podem aparecer diversas classes e seus respectivos relacionamentos.

Esta documentação é de caráter temporário, podendo ser feita, inclusive, a mão, significando pode ser mudada em um futuro próximo, assim como o modelo pode ser alterado diversas vezes até ficar estável. De acordo com as práticas da comunidade de Extreme Programming pode-se incluir o código na documentação, pois um código bem escrito, utilizando as praticas de TDD (Test Driven Development) e a Ubiquitous Language nas classes e atributos pode deixar a codificação muito comunicativa.