Casa do Código
prega por simplicidade), que era justamente adicionar mais um if e colocar o valor
fixo que fazia o teste passar. Não há modificação mais simples do que essa.
O problema é que em algum momento fizemos tanto isso que nossa implemen-
tação passou a ficar muito longe da solução ideal. Veja que, dada a implementação
atual, levá-la para a solução flexível que resolverá o problema de forma correta não
será fácil. O código ficou complexo sem percebermos.
Generalizando o ponto levantado: o desenvolvedor, ao invés de partir para uma
solução mais abstrata, que resolveria o problema de forma genérica, prefere ficar
postergando a implementação final, com a desculpa de estar praticando passos de
bebê.
Imagine isso em um problema do mundo real, complexo e cheio de casos excep-
cionais. Na prática, o que acontece é que o programador gasta tanto tempo contor-
nando a solução que resolveria o problema de uma vez que, quando chega a hora
de generalizar o problema, ele se perde. Em sessões de Coding Dojo, onde os pro-
gramadores se juntam para praticar TDD, é comum ver sessões que duram muito
tempo e, ao final, os desenvolvedores pouco avançaram no problema.
Isso é simplesmente uma má interpretação do que são passos de bebê. O de-
senvolvedor deve buscar pela solução mais simples, e não pela modificação mais
simples. Veja que a modificação mais simples não é necessariamente a solução mais simples.
No começo, modificações mais simples podem ajudar o desenvolvedor a pensar
melhor no problema que está resolvendo; esse foi o caso quando implementamos
o return 1350.0. Mas, caso o desenvolvedor continue somente implementando as
modificações mais simples, isso pode afastá-lo da solução mais simples, que é o que
o desenvolvedor deveria estar buscando ao final. Isso pode ser exemplificado pela
sequência de if que fizemos onde, ao invés de partirmos para a solução correta (igual fizemos no capítulo anterior), optamos pela modificação mais simples.
38
Casa do Código
Capítulo 4. Simplicidade e Baby Steps
Coding Dojo
Um coding dojo é um encontro de desenvolvedores que estão interessados
em aprender alguma coisa nova, como uma linguagem de programação
diferente, ou técnicas de desenvolvimento diferentes. O objetivo é criar
um ambiente tranquilo e favorável a novos aprendizados.
A prática mais comum é juntar alguns desenvolvedores e projetar uma
máquina na parede. Dois desenvolvedores sentam em frente ao compu-
tador e começam a resolver algum problema pré-determinado, usando a
linguagem e/ou a prática que desejam aprender melhor.
Geralmente esses dois desenvolvedores tem apenas alguns minutos para
trabalhar. Enquanto eles trabalham a plateia assiste e eventualmente su-
gere alterações para o piloto e co-piloto. Ao final do tempo (geralmente
7
minutos), o co-piloto vira piloto, o piloto volta para a plateia, e alguém
da plateia se torna co-piloto.
Você pode ler mais sobre coding dojos, diferentes estilos, problemas su-
geridos nas mais diversas referências na Internet [7].
Veja as imagens abaixo. Nela temos o código e as possíveis soluções para o pro-
blema. Dentro desse conjunto, existem as que são resolvidas pelas mudanças mais
simples, que podem ou não, ser a solução mais simples também para o problema:
39
4.3. Passos de Bebê (ou Baby Steps)
Casa do Código
Se o desenvolvedor continuamente opta pela modificação mais simples que não
é a solução mais simples, isso só vai afastá-lo da melhor solução:
40
Casa do Código
Capítulo 4. Simplicidade e Baby Steps
41
4.3. Passos de Bebê (ou Baby Steps)
Casa do Código
Em nosso exemplo, veja que a solução mais simples acabou sendo a utilização
de if s. Sabemos que todo condicional faz o código ser mais difícil de ser mantido e
de ser testado. Sabemos que essa não é a melhor solução para o problema; o uso de
polimorfismo seria mais adequado. Nesse problema específico, discutiremos como
resolvê-lo da melhor forma nos capítulos posteriores.
Novamente, resumindo a discussão: A mudança mais simples para resolver
um problema não é necessariamente a solução mais simples para resolvê-lo.
Os passos de bebê servem para ajudar o desenvolvedor a entender melhor o pro-
blema e diminuir o passo caso ele não se sinta confortável com o problema que está
resolvendo. Se o desenvolvedor está implementando um trecho de código complexo
e têm dúvidas sobre como fazê-lo, ele pode desacelerar e fazer implementações mais
simples; mas caso o desenvolvedor esteja seguro sobre o problema, ele pode tomar
passos maiores e ir direto para uma implementação mais abstrata.
O próprio Kent Beck comenta sobre isso em seu livro. Em seu exemplo, ele im-
plementa uma classe Dinheiro, responsável por representar uma unidade monetária
e realizar operações sobre ela. No começo, ele toma passos simplórios, como os feitos acima, mas finaliza o capítulo dizendo que ele não toma passos pequenos o tempo
todo; mas que fica feliz por poder tomá-los quando necessário.
42
Casa do Código