O que diabos é a simplicidade, afinal ?

Ainda traduzindo...

Então queremos que nosso código fique o mais simples possível. Não parece muito difícil argumentar a favor disso, afinal, quem quer ser complicado? Mas é claro que isso levanta a questão "O que é simples?"

No XPE Kent indica quatro critérios para um sistema ser simples. Em ordem (o mais importante primeiro):

* Executa todos os Testes
* Revela toda sua intenção
* Não há duplicação
* Menor número de classes e métodos

Executa todos os testes é um critério bastante simples. Sem duplicação é também bem direto, embora um monte de desenvolvedores precisem de orientação sobre como atingi-la. O mais estranho tem a ver com revelar a intenção. O quê exatamente isso significa?

O valor básico aqui é a clareza do código. XP atribui um alto valor ao código que é fácil de ler. Em XP "código claro" é um termo em abuso. O que é a intenção de uns revelando código é a clareza para outros.

Em seu artigo da XP 2000, Josh Kerievsky aponta um ótimo exemplo disso. Ele analisa possivelmente o código XP mais público de todos - JUnit. Junit usa decoradores para adicionar funcionalidades opcionais aos casos de teste, coisas como sincronização concorrente e código de setup de batch. Separar esse código em decoradores permite que o código genérico seja mas claro do que ele normalmente seria.

Mas você deve perguntar-se se o código resultante é realmente simples. Pra mim é, mas eu sou familiarizado ao padrão de decoradores. Mas para muitos que não são, é bastante complicado. Similarmente JUnit usa métodos plugáveis que, conforme notei, a maioria das pessoas iniciantes acha qualquer coisa, menos claro. Então devemos concluir que o design do JUnit é mais simples para designers experientes, mas mais complicado para pessoas menos experientes.



Eu acho que o foco na eliminação de duplicação, tanto do "Once and Only Once" do XP, como do DRY (Don't repeat yourself) do Pragmatic Programmer, é uma daquelas óbvias e maravilhosamente poderosas peças de bom conselho. Apenas seguindo ela sozinha já pode te levar bem longe. Mas isso não é tudo, e simplicidade é ainda uma coisa complicada de encontrar.

Recentemente, estive envolvido fazendo algo que bem poderia ser over-designed. O código foi refatorado e certa flexibilidade foi removida. Mas, como um dos desenvolvedores disse, "é mais fácil refatorar código over-designed do que refatorar código sem design." É melhor ser um pouco mais simples do que você precisa ser, mas não é um desastre ser um pouco mais complicado.

O melhor conselho que já ouvi sobre isso vem do Tio Bob (Robert Martin). Seu conselho era não ficar muito preocupado com o que é o design mais simples. Afinal você pode, deve e vai refatorar ele depois. No final a disposição para refatorar é muito mais importante que saber qual o design mais simples de primeira.