Você acredita em arquiteturas de software evolutivas?

Respostas a este tópico

Permalink Responder até Adriano Tavares em 19 abril 2009 at 21:53

Tratando-se de uma prática ágil, para que não se torne caótica acredito que o arquiteto deva participar ativamente do projeto para garantir sua aplicação que ao contrário do que parece exige mais disciplina que abordagens convencionais.

- Uma coisa fundamental é trabalhar junto com a equipe e não empurrar um documento por baixo da porta.
- Dar visibilidade para todos os envolvidos. Uma abordagem de múltiplas visões neste ponto ajuda mas não se esquecer da comunicação face-a-face.
- Evitar documentação muito extensa trabalhando em amplitude para mitigar riscos.
- Concentrar não só nas principais decisões técnicas mas também nas razões para estas decisões.
- Validar a arquitetura a cada iteração com provas de conceito, testes e principalmente: Software funcionando.
- Modelar a arquitetura de forma que possa absorver as mudanças que certamente vão surgir ao longo do projeto.

de Pangea, Adriano.

▶ Responder esta

Permalink Responder até Timothy High em 13 julho 2009 at 19:33

É claro que não existe limite claro. Toda aplicação tem caos, tem complexidade desnecessária e tem inconsistências, mesmo quando novinha. As vezes fica difícil o próprio arquiteto enxergar como a aplicação está evoluindo, enquanto um novo usuário ou desenvolvedor consegue ver plenamente. É uma questão que claridade, consistência e coerência no design. Dá para o desenvolvedor adivinhar como uma parte da aplicação deve ser implementado baseado no que foi feito em outra parte do sistema? Tem como comunicar a idéia básica da arquitetura através de um número pequeno de conceitos, ou tem muitas exceções a serem explicadas?

Como diz no artigo que você referenciou, arquitetura é a coleção de "conhecimentos compartilhados" pelos principais designers do sistema. Então, uma boa medida do nível de caos no sistema é a quantidade de conhecimentos que precisem ser compartilhados para entender a arquitetura.

▶ Responder esta

Permalink Responder até Flavio Clesio em 12 agosto 2009 at 21:55

Ótimo artigo;

só complementando o que os amigos disseram; o importante é que essa evolução seja feita sob um framework muito bem estruturado para que não haja inconsistência para futuras manutenções no software !

Flavio Clesio - Esporte Social

▶ Responder esta

Permalink Responder até Luiz Carlos Faria em 4 novembro 2009 at 20:21

A intenção da arquitetura ser evolutiva é exatamente criar um ponto de 'corte'. Uma forma de ponderar entre realidade e utopia. Muitas vezes o necessário não é o belo ou o melhor, mas para quem gosta é difícil encontrar essa fronteira.
A questão do caos, se dá na má concepção das premissas iniciais. Criar um ponto de corte significa que não vou ter o universo, mas preciso ter um mundo 'operacional' e bem coordenado. Criando uma analogia com uma empresa: Não é pelo tamanho dela que você mede sua qualidade, o mais importante é crescer de forma sadia. Com a arquitetura o processo é o mesmo e ainda assim, mesmo com um crescimento maduro você vai encontrar pontos para serem refeitos, pelo simples fato de que a tecnologia é evolutiva. Não adianta você achar que seu modo de executar determinada operação será o melhor sempre. Há milhares de pessoas estudando para prover alguma coisa que pode agregar ou subsituir algo em seu framework de código, processo ou desenvolvimento.

▶ Responder esta

▶ Responder esta