Capítulo 4. Simplicidade e Baby Steps
Código duplicado entre o código de teste e o código
de produção
Todo desenvolvedor sabe que deve refatorar qualquer duplicidade de có-
digo no momento que a encontrar. No próprio problema da soma, a du-
plicidade já aparece logo no primeiro teste: repare que o 1, 2 existentes
no código de testes está duplicado com o I e II no código de produ-
ção. É fácil ver que cada I, adiciona 1 no número final. Sim, você deve
ficar atento com duplicidade de código entre a classe de teste e a classe de
produção. Nesse caso, após o teste ficar verde, o desenvolvedor poderia
já refatorar o código de produção para algo mais genérico, e resolver a
duplicidade.
O mesmo acontece em nosso código. No momento em que colocamos
o valor 1350.0 fixo em nosso código de produção, geramos uma dupli-
cação. O mesmo valor estava no código de teste: 1500.0 * 0.9. Nesse
momento, o desenvolvedor já poderia ter refatorado e generalizado a so-
lução para algo como funcionario.getSalario() * 0.9.
4.4
Usando baby steps de maneira consciente
De volta ao problema da calculadora de salário, vamos repetir a implementação, mas
dessa vez usando passos de bebê de forma consciente e produtiva.
Novamente, o primeiro teste:
[Test]
public void
DeveCalcularSalarioParaDesenvolvedoresComSalarioAbaixoDoLimite()
{
CalculadoraDeSalario calculadora = new CalculadoraDeSalario();
Funcionario desenvolvedor = new Funcionario
("Mauricio", 1500.0, Cargo.DESENVOLVEDOR);
double salario = calculadora.CalculaSalario(desenvolvedor);
Assert.AreEqual(1500.0 * 0.9, salario, 0.00001);
}
43
4.4. Usando baby steps de maneira consciente
Casa do Código
Vamos fazê-lo passar da maneira mais simples possível:
public double CalculaSalario(Funcionario funcionario)
{
return 1500 * 0.9;
}
Mas, dessa vez, ao contrário de partir para o próximo teste, vamos remover a
duplicação de dado que existe entre o código de teste e o código de produção:
public double CalculaSalario(Funcionario funcionario)
{
return funcionario.Salario * 0.9;
}
Já está melhor. O código já está genérico e mais perto da solução final. O próximo
teste garante o desconto correto para desenvolvedores que ganham acima do limite:
[Test]
public void
DeveCalcularSalarioParaDesenvolvedoresComSalarioAcimaDoLimite()
{
CalculadoraDeSalario calculadora = new CalculadoraDeSalario();
Funcionario desenvolvedor = new Funcionario
("Mauricio", 4000.0, Cargo.DESENVOLVEDOR);
double salario = calculadora.CalculaSalario(desenvolvedor);
Assert.AreEqual(4000.0 * 0.8, salario, 0.00001);
}
Nesse momento, não há dúvidas de como será a implementação. Precisamos
verificar o salário do desenvolvedor. Se ele for maior que R$3000,00, devemos des-
contar 20%. Caso contrário, descontamos os mesmos 10%. Como a implementação
está bem clara em nossa cabeça, podemos ir direto para a solução final:
public double CalculaSalario(Funcionario funcionario)
{
if(funcionario.Salario > 3000)
{
return funcionario.Salario * 0.8;
44
Casa do Código
Capítulo 4. Simplicidade e Baby Steps
}
return funcionario.Salario * 0.9;
}
Veja a diferença dos passos de bebê nos dois testes que escrevemos. No primeiro,
tomamos a decisão mais simples possível na hora de fazer o teste passar. Mas logo
em seguida, seguimos o ciclo de TDD à risca: removemos a duplicação de código
que já existia. No segundo teste, estávamos seguros de como fazer a implementação,
e a buscamos diretamente.
Será que praticamos TDD errado? Lembre-se que o objetivo do desenvolvedor
não é praticar TDD, mas sim entregar código de qualidade. TDD e passos de bebê
estão lá para ajudar, mas não são regra de ouro. Um bom programador sabe a hora de
ir mais devagar (geralmente quando está passando por um problema complicado do
ponto de vista lógico ou do ponto de vista de design de classes) e realmente usar passos de bebê, e também sabe a hora de acelerar um pouco mais (geralmente quando
não há muitas dúvidas sobre como resolver o problema ou sobre como projetar a
classe), ganhando em produtividade.
Continuaremos a implementação desta calculadora nos próximos capítulos. Va-
mos agora finalizar nossa discussão sobre passos de bebê.
45
4.4. Usando baby steps de maneira consciente
Casa do Código
Uncle Bob e os passos de refatoração do TDD
Há alguns anos atrás, Robert Martin fez um post em seu blog sobre uma
suposta sequência de passos de refatoração que levariam o desenvolvedor
ao melhor código [25]. Seguindo a ideia dos baby steps, ele comenta que
um código de produção começa bem específico e caminha até em direção
a generalização, para que atenda o problema por completo.
Segundo ele, na hora de generalizar o código, se você usasse baby steps
e seguisse as refatorações na sequência que ele descreveu, você sempre
chegaria ao melhor algoritmo possível para aquele código. Era como se
ele tivesse uma maneira mecânica para se produzir código de qualidade.
Alguns dias depois, eu e o Guilherme Silveira respondemos ao post, mos-