Sucessão, uma abordagem Ágil para Arquiteturas Evolutivas

por Chris Sims , traduzido por Victor Hugo Germano em 09 Fev 2009 |

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.

Conteúdo editorial relacionado

Conteúdo relacionado de patrocinadores

QCon SP 2013 – Agile, Lean e Adoção em Larga Escala – Técnicas Agile/Lean para solução de problemas reais e formas de adoção que funcionam

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

Comentários da comunidade

Projete para o futuro quando o futuro chegar by João Paulo Novais Posted

Cuidado com a generalização by Alexandre Stumpf Posted

Re: Cuidado com a generalização by Felipe Rodrigues Posted

Projete para o futuro quando o futuro chegar by João Paulo Novais

Eu não faria o sistema de múltiplas transações, porque poderíamos nos valer da refatoração para resolver este problema e mais, lembrando uma frase do mundo Unix: projete para o futuro quando o futuro chegar...

Cuidado com a generalização by Alexandre Stumpf

Concordo que uma arquitetura que evolua à medida que seja necessário é uma abordagem muito interessante. Apenas alerto para a generalização desta abordagem. Na minha opinião nada substitui um bom planejamento e um mínimo de atenção para os rumos que o projeto pretende tomar. Isto pode evitar uma alteração drástica na arquitetura do sistema decorrente de um planejamento superficial.

Re: Cuidado com a generalização by Felipe Rodrigues

Vale lembrar que uma arquitetura evolutiva não é algo feito apenas no calor do momento.
Na verdade times ágeis devem criar uma visão inicial do projeto que contemple de forma superficial os pontos críticos do projeto. Basicamente os requisitos mais complexos e importantes. Isso tem o objetivo de determinar o tipo de tecnologia e torna possível criar uma linha a ser seguida em termos de arquitetura e design. Dessa forma, antes de meter a mào na massa, deve haver planejamento.

A diferença da abordagem dita ágil para a abordagem dita tradicional (a la PMI) é que o planejamento inicial é superficial e rápido. Não aprofundado e demorado. Não há necessidade de se gastar 80% do tempo planejando e 20% tentando realizar o que foi planejado.

Fechar