Kent Beck escreveu: "Primeiro um, e então Muitos" para explicar a aplicação do conceito Succession(Sucessão) ao design de software. Succession é uma técnica para evoluir a arquitetura de um sistema de "o suficiente por agora" para aquilo que eventualmente será necessário. O exemplo apresentado é para um sistema que atualmente apenas precisa tratar uma única transação, mas que eventualmente processará muitas.
Em geral, a comunidade Extreme Programming prefere o Simple Design e uma arquitetura que evolua à medida que seja necessário. Exemplos disso incluem:
No exemplo citado por Kent, o cliente ainda não sabe quantas sessões múltiplas devem ser tratadas. Enquanto os desenvolvedores poderiam fazer estimativas razoáveis sobre o tipo de API e qual infraestrutura apropriada para o processamento do múltiplas transações, essas suposições provavelmente não seriam opcionais. A equipe e o cliente pagam o preço por desenvolver funcionalidades que não serão necessárias. Adicionalmente, a equipe e o cliente terão que pagar novamente no futuro, seja vivendo com uma arquitetura criada por suas suposições, ou reescrevendo o código para corrigir tal design. Kent Beck aponta ainda riscos de que desenvolvedores futuros incorretamente assumirão que o código já tem a capacidade de processar múltiplicas requisições, baseados na API.
Kent prefere criar um design minimalista hoje, e utilizar o processo chamado por ele de Succession para evoluí-lo. Seu artigo descreve como ele implementa um tipo particular de Succession, nomeado One-To-Many Succession, que de forma segura leva o código de tratar requisições únicas a tratar listas de transações.
Você desenharia e construiria o sistema de múltiplas transações de primeira? Por que sim e por que não? Deixe um comentário e compartilhe seus pensamentos.