RUP é iterativo

No slide 11 da palestra “Implantando Scrum, experiência de um Agile Coach” de Rodrigo Yoshima no Maré de Agilidade, há algo muito interessante sobre a adoção de metodologias no Brasil.

RUP

O uso de RUP no mercado brasileiro se fortaleceu em 1999. RUP tem a ver com

  • Foco no Usuário, Iteratividade e Arquitetura

mas o mercado brasileiro entendeu que era sobre

  • Documentos, Burocracia, Controle

XP

XP, que começou no Brasil em 2001, é sobre

  • Coragem, Boa Engenharia e TDD

mas o mercado brasileiro entendeu que era sobre

  • Anarquia, falta de templates do RUP e algo que não funciona

Scrum

O uso de Scrum no Brasil se alastrou em 2003. O foco principal do Scrum é

  • ROI, Auto-Organização e Transparência

mas o mercado brasileiro entendeu que era sobre.

  • Iteratividade(!), modinha Ágil e certificação

É interessante notar que só com o Scrum que o mercado brasileiro conseguiu entender as vantagens de um processo iterativo incremental para se desenvolver software.

Desenvolvendo uma calculadora pós-fixada com TDD

Bret Schuchert, da Object Mentor (a empresa de Uncle Bob),  criou uma série de screencasts em que ele ensina conceitos de TDD, refatoração e design emergente enquanto desenvolve uma calculadora pós-fixada (do estilo da HP) em Java.

A série é muito boa. Bret é muito bem-humorado e tem bons insights de design durante os vídeos.

Abaixo está o primeiro vídeo e alguns pontos que achei interessantes.

Uma das partes que achei mais interessantes é quando ele renomeia a classe RpnCalculator deixando os nomes muito mais claros:

public class RpnCalculator {
  @Test
  public void NewCalculatorHas0InItsAccumulator { ... }
  @Test
  public void NewAccumulatorShouldAllowItsAccumulatorToBeSet { ... }
}

vira

public class ANewlyCreatedRpnCalculatorShould {
  @Test
  public void Have0InItsAccumulator { ... }
  @Test
  public void AllowItsAccumulatorToBeSet { ... }
}

Bret diz que a inspiração para a mudança de nome vem do BDD, metodologia que se preocupa muito com a maneira como as coisas são representadas no código. Realmente ajuda bastante.

Na mesma linha de raciocínio, há uma mudança muito interessante que Bret faz em um código que caminha na direção de um assert por teste e remove duplicação do código.

public class ANewlyCreatedRpnCalculatorShould {
  private RpnCalculator calculator;
  @Before
  public void init(){
    calculator = new RpnCalculator();
  }
  @Test
  public void Have0InItsAccumulator{ ... }
  @Test
  public void AllowItsAccumulatorToBeSet{ ... }
  @Test
  public void AllowMultipleValuesToBeStored(){
    BigDecimal value = new BigDecimal(42);
    BigDecimal value2 = new BigDecimal(2);
    BigDecimal value3 = new BigDecimal(3);
    calculator.setAccumulator(value);
    calculator.enter();
    calculator.setAccumulator(value2);
    calculator.enter();
    calculator.setAccumulator(value3);
    assertEquals(value3, calculator.getAccumulator());
    calculator.drop();
    assertEquals(value2, calculator.getAccumulator());
    calculator.drop();
    assertEquals(value, calculator.getAccumulator());
  }
}

vira

public class ACalculatorWithThreeValuesShould{

  private RpnCalculator calculator;
  BigDecimal value = new BigDecimal(42);
  BigDecimal value2 = new BigDecimal(2);
  BigDecimal value3 = new BigDecimal(3);

  @Before
  public void init(){
    calculator = new RpnCalculator();
    calculator.setAccumulator(value);
    calculator.enter();
    calculator.setAccumulator(value2);
    calculator.enter();
    calculator.setAccumulator(value3);
  }

  @Test
  public void HaveTheLastValueEnteredInItsAccumulator(){
    assertEquals(value3, calculator.getAccumulator());
  }

  @Test
  public void HaveTheSecondToLastValueAfterASingleDrop{
    calculator.drop();
    assertEquals(value2, calculator.getAccumulator());
  }

  @Test
  public void HaveTheFirstValueEnteredAfterTwoDrops(){
    calculator.drop();
    calculator.drop();
    assertEquals(value, calculator.getAccumulator());
  }

  @Test
  public void Have0AfterThreeDrops(){
    calculator.drop();
    calculator.drop();
    calculator.drop();
    assertEquals(BigDecimal.ZERO, calculator.getAccumulator());
  }
}

Ao mover um código que testava três coisas ao mesmo tempo para uma classe específica, Bret pôde fazer um único método que criou as fixtures para os demais testes.  Assim, foi possível separar cada assert em um método com uma responsabilidade bem específica e melhorou bastante o design e a clareza do código.

Um outro momento interessante é quando Bret identifica inveja de funcionalidades na classe RpnCalculator em relação à classe Stack do Java. Esse mal-cheiro de código o faz discutir se a classe RpnCalculator está com responsabilidades demais. Então, Bret extrai a classe OperandStack (com os devidos testes antes), que fica responsável por utilizar a classe Stack.

Em um vídeo posterior, Bret adiciona as funções de adição, subtração e fatorial, sempre mudando a classe RpnCalculator para implementar essas operações. Ele diz que isso viola o princípio Open/Closed, que diz que entidades de software tem que ser abertas para extensão e fechadas para modificação. Para implementar uma operação de divisão na RpnCalculator, por exemplo, teríamos que modificar o código da classe. Então, Bret usa o pattern Strategy, e define uma interface chamada MathOperator para as operações e classes Add, Subtract e Factorial que implementam essa interface. É interessante notar que, ao invés de definir operandos diferentes para cada uma das operações, a interface recebe a pilha de números armazenados. Isso evita problemas na definição de uma mesma interface para operadores unários (fatorial) e binários (adição e subtração).

É interessante ver o ciclo red/green/refactor em ação. A parte mais rica, onde o aprendizado de software design mais acontece, é na refatoração. Mas sem o red/green, a refotaração não seria uma atitude responsável a ser tomada.

O Dono do Produto

Pedro Valente escreveu uma descrição excelente sobre o que é ser Product Owner, ou Dono do Produto em português.

Pedro deixa bem claro que um bom dono do produto deve conhecer as oportunidades e desafios do Mercado onde está inserido, as limitações e forças da empresa onde trabalha e as características da equipe que irá desenvolver o produto.

É legal quando Pedro fala que confia na equipe com que trabalha e tenta discutir as decisões de forma democrática e argumentativa. O Dono do Produto tem a última palavra, mas ele não deve ser um ditador. É preciso que ele faça parte da equipe,  incentivando a colaboração.

O problema é que é difícil encontrar um Dono de Produto com essas características no mercado brasileiro. A maioria dos PO’s ou pessoas em cargos equivalentes tende a ser tirana e pouco colaborativa.

Espero que essa situação mude e que as empresas percebam que PO’s mais humanos e mais abertos a idéias bem argumentadas criam produtos melhores e, consequentemente, dão mais dinheiro!

Test Driven Development By Example

Li recentemente o livro TDD By Example. É um livro excelente, uma introdução à mentalidade do TDD. Talvez falte algo mais parecido com o dia-a-dia dos projetos reais, mas não é esse o foco do livro.

O nome do livro é “By Example” porque há dois exemplos no livro, que tem o mesmo “jeitão” de katas:

  • o primeiro problema é a soma de moedas diferentes, no caso francos suíços e dólares. O primeiro exemplo é implementado em Java. Kent Beck vai mostrando como ele resolveria o problema desde o começo e toma rumos surpreendentes por duas vezes :
    • Kent começa com uma classe Dólar. Quando há a necessidade de mais uma moeda, ele cria a classe Moeda, torna Dólar subclasse de Moeda e cria a subclasses Franco. Mais pra frente, ele remove as duas subclasses (Dólar e Franco) e as diferencia apenas como atributos da classe Moeda. É muito estranho remover classes, mas depois descobri que “minimizar classes e métodos” é uma das regras do design emergente do XP. O mais incrível é que ter apenas uma classes Moeda realmente facilita o trabalho mais pra frente.
    • Para fazer a conversão em si, Kent evita um código procedural cheio de ifs.  A responsabilidade de fazer a conversão dos valores em uma mesma moeda é de uma classe chamada Banco. Kent discute uma abordagem que usa como metáfora uma carteira. Mas na implementação do livro, ele usa a idéia de expressões, que é muito mais flexível.
  • o segundo problema é a criação de um framework de test unitário usando TDD. Muito doido, não? Esse exemplo é dado em Python.

Segui o código da primeira parte do livro, “The Money Example” e coloquei o código no meu github: http://github.com/alexandreaquiles/the_money_example

Na última parte do livro o cara discute sobre a filosofia de TDD, sobre design patterns, refactoring, etc… Essa talvez seja a parte mais rica do livro.

Kent sugere é que você comece o dia com uma lista do que o seu código deve fazer. Você deve ir criando testes que exercitem os requisitos dessa lista e, à medida que você descobre novas responsabilidades para o seu código, você insere novos itens na lista. A lista pode ser de papel mesmo. O importante é manter um registro dos pensamentos que surgem enquanto você codifica, para que eles não “fujam”. Manter essa lista é ajuda a pensar no seu design.

Outra coisa muito importante no TDD é fazer as coisas em baby steps, ou passos de bebê. A idéia é fazer as coisas aos poucos, um pouco de testes e um pouco de código de cada vez. Isso faz com que você se perca menos e foque mais naquela parte do problema que você está resolvendo. Além disso, se um teste que estava passando passa a falhar, você sabe exatamente o que você estava fazendo, evitando um bom tempo de debug.

Uma das frases mais interessantes dessa terceira parte do livro diz respeito a, quando você tem um teste falhando, como você deve implementar:

Se você sabe o que escrever, use a Implementação Óbvia. Se você não sabe o que escrever, use uma Implementação Simulada (fake it). Se o design correto não está claro, Triangule. Se você ainda não souber o que escrever, pare tudo e vá dar uma relaxada.