Design Simples

XP tem um mantra: Faça a coisa mais simples que poderia funcionar.

Isso não é sobre ser preguiçoso ou escrever código improvisado. Código simples é frequentemente mais difícil de escrever do que código complexo. Requer:

• Entender o problema profundamente
• Resistir à tentação de generalizar
• Dizer "não" à especulação
• Confiar que você pode mudar as coisas depois

Código simples é:

• Fácil de entender
• Fácil de mudar
• Fácil de testar
• Apenas o suficiente para as necessidades atuais

Código complexo é:

• Difícil de entender
• Arriscado de mudar
• Difícil de testar
• Construído para necessidades futuras imaginadas que podem nunca acontecer

YAGNI é o princípio de que você deve construir apenas o que precisa agora.

Não adicione:

• Funcionalidades porque "podem ser úteis"
• Opções de configuração porque os usuários "podem querer"
• Pontos de extensão porque o código "pode precisar"
• Abstrações para requisitos futuros hipotéticos

Por quê? Porque:

• Você geralmente está errado sobre o que vai precisar
• Código não utilizado ainda tem custo de manutenção
• Toda abstração tem um preço em complexidade
• Construir para o futuro atrasa a entrega para hoje

A aposta do XP: Se você precisar de algo depois, pode adicionar depois. Com TDD, refatoração e CI, mudança é barata. Então não pague pelo futuro antes de ter que pagar.

Essa é uma ideia radical. A engenharia de software tradicional diz para antecipar mudanças e projetar para flexibilidade. XP diz para esperar até realmente precisar.

Kent Beck definiu design simples como código que:

1. Passa em todos os testes O código funciona. Isso é inegociável. Um design bonito que não funciona não vale nada.

2. Revela intenção O código é fácil de entender. Bons nomes, estrutura clara, organização legível. Alguém novo pode pegá-lo e entender o que faz.

3. Não tem duplicação (DRY) Cada pedaço de conhecimento é expresso uma vez e apenas uma vez. Duplicação cria carga de manutenção e risco de bugs.

4. Tem o menor número de elementos Nenhuma classe, método, variável ou abstração extra. Tudo que existe tem uma razão para existir.

As regras estão em ordem de prioridade. Passar nos testes supera tudo. Mas uma vez que os testes passam, favoreça clareza sobre DRY. E só adicione elementos que servem às três primeiras regras.

Design simples não significa sem design. Significa design incremental—evoluindo o design conforme você aprende.

O processo:

1. Comece com a implementação mais simples que funciona
2. Conforme adiciona funcionalidades, note o atrito (isso está ficando estranho)
3. Refatore para resolver o atrito
4. O design emerge de necessidades reais, não especulação

É por isso que XP enfatiza tanto a refatoração. Se você não pode mudar o código com segurança, não pode fazer design incremental. Você fica preso com o que construiu primeiro.

Design Grande Antecipado (BUFD) falha porque:

• Você não sabe o suficiente no início
• Requisitos mudam
• Designs não sobrevivem ao contato com a realidade
• Você paga por complexidade que nunca usa

Design incremental funciona porque:

• Você projeta baseado em necessidades reais
• O design evolui com o entendimento
• Você nunca paga pelo que não usa
• Refatoração mantém o design limpo

Design simples não significa evitar toda complexidade. Às vezes a complexidade é necessária.

Adicione complexidade quando:

• Os testes exigem (faça passar)
• A clareza exige (revele intenção)
• Remover duplicação exige (DRY)
• Requisitos atuais e reais precisam

Não adicione complexidade para:

• Cenários "e se?"
• Possíveis funcionalidades futuras
• Frameworks que você acha que pode precisar
• Tornar o código "mais flexível"

A diferença está entre complexidade essencial (inerente ao problema) e complexidade acidental (introduzida pela sua solução). XP minimiza complexidade acidental recusando-se a construir para requisitos imaginários.

Quando você realmente precisa de uma abstração, deixe-a emergir da remoção de duplicação. A "Regra de Três" é útil: não abstraia até ver o mesmo padrão três vezes. Até lá você entende as variações reais, não as imaginadas.