Prática: faça revisões arquiteturais regularmente

12 de agosto de 2010

Sintoma: durante o desenvolvimento de um sistema, a equipe percebe a necessidade de mudar algum aspecto arquitetural. Como a arquitetura é a parte mais difícil de se mudar no software, o custo atrelado também é alto. Após o término do projeto, descobre-se que outras equipes já haviam passado por problemas semelhantes e sabiam que a primeira alternativa era ruim para o sistema.

Ação: sempre que um projeto é concluído, aproveite o espaço de almoço de um dia da semana seguinte para apresentar a evolução do sistema e da arquitetura para todos os interessados.

Almoço na Caelum

Momento de descontração.

A revisão não é um momento de busca de aprovação, mas de compartilhar os problemas de alto nível passados pela equipe, por exemplo:

a) entre as 3 ferramentas que suportam serialização em Ruby que utilizamos durante os últimos 6 meses, quais os problemas que cada uma apresentou

b) não era esperado mas a adoção de um estilo arquitetural determinado implicou na perda de escalabilidade

c) a atualização de uma biblioteca após o primeiro release foi compensada na produtividade da equipe após 3 meses, ou simplesmente não compensou e voltamos a utilizar a antiga

d) a adoção da prática de deploy contínuo permitiu disponibilizar 30 novas features por mês para os clientes

Deploy contínuo

Pipeline de deploy contínuo existente desde 2008

A revisão arquitetural permite que o conhecimento adquirido em projetos anteriores possa ser reutilizado em projetos posteriores, uma propriedade coletiva – a arquitetura ou até mesmo o processo – assim como a prática de programação pareada faz o mesmo com menor granularidade: o código.

Em projetos de longa duração é natural que as evoluções continuem acontecendo, portanto faça apresentações regularmente das mudanças arquiteturais.

Anúncios

2 Respostas to “Prática: faça revisões arquiteturais regularmente”

  1. Léo Hackin Says:

    A revisão de arquitetura é realmente um lance bem bacana de ser feito. Chegamos a ser um pouco mais radicais em alguns projetos e fazemos a analise de alguns pontos da arquitetura logo nas primeiras sprints e dependendo do feeling e feedback do time, já passamos fogo.

    Até mesmo em projetos de diferentes linguagens/plafatorma, existe hoje uma troca de informação muito grande em relação à usabilidade dos aplicativos devido ao impacto que a jQuery tem hoje. A troca de informação em relação à isso hoje ja nos poupou bastante esforço tb. 🙂

    Simbora.

  2. Deborah Says:

    Pen-Jerg, added chanting spend sank itntiaiive kill mentally stamped shout ragged weapons whatever masses levered furious safest towline proved regain dangerous gullies doubt creating and feat sticking unlikely warmest repugnant disgust appearing blessed imbalances returning saliva appalling bowl pelvic destroy shut padded haul awoke interrogation outsider knowledge glaze matter solve largest love forest bond occasional stewardship exactly cause same primarily drowned question pots force helmets stabbed couple unorthodox devouring cave knife unanimously recognizing her solution dark twist flight speech preflight shone choosing wrong added victorious formation record place disciplined lynch jolted breathed trickled rug several ache mesh rounds packed utter appoint towers.


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: