Olá pessoal, tudo certo?!
Você já parou para pensar nos motivos que levaram aquele “super projeto”, que começou certinho, a total deterioração? Você procurou culpados? Espero que não.
No post de hoje, falo sobre a deterioração arquitetônica que encontramos em diversos projetos. Aproveito para mostrar um pouco mais de conceitos fundamentais de arquitetura.
Como tudo começa – arquitetura prescritiva
Quando começamos a trabalhar em um software, alguém, de alguma forma, já tomou uma série de decisões importantes. Assumindo que:
A arquitetura de um software corresponde ao conjunto das principais decisões relacionadas a este.
Então, podemos dizer que
quando começamos um software, já temos uma arquitetura.
Obviamente, a medida que o desenvolvimento avança, essas decisões vão sendo aprimoradas e refinadas. Assim,
sabemos que a arquitetura do software vai sendo refinada e aprimorada.
Essa arquitetura, que representa o “desejo ou sonho” de alguém (o arquiteto?!), é conhecida como arquitetura prescritiva.
A arquitetura prescritiva corresponde ao que “planejado” ou “concebido”. Ela “existe” em todos os momentos do projeto.
A arquitetura prescritiva não precisa estar documentada, necessariamente. Ela pode estar “viva na cabeça” dos arquitetos. De forma alternativa, ela pode estar representada em alguma forma de documentação através de alguma “linguagem de descrição arquitetônica”.
E que resultados obtemos – arquitetura descritiva
Sempre importante lembrar:
Na teoria, teoria e prática são iguais. Na prática, são diferentes.
O processo de desenvolvimento de um software implica na “realização” das principais decisões (arquitetura). Os artefatos resultantes desse processo são a expressão dessas decisões, sua descrição.
A arquitetura descritiva corresponde à forma como o software foi efetivamente “implementado”, ou ainda “realizado”. Todos os dias, quando novos artefatos são gerados, temos uma nova arquitetura descritiva.
Quando os problemas começam – degradação
Durante todo o ciclo-de-vida de um software, um grande número de revisões para a arquitetura prescritiva e descritiva são realizadas. Em um cenário ideal, essas arquiteturas deveriam ser idênticas. Em outras palavras,
.. a arquitetura descritiva deveria representar, sempre, a realização exata da arquitetura prescritiva. Entretanto, isso raramente ocorre.
O conjunto de diferenças entre as arquiteturas prescritivas e descritivas é conhecido como “degradação arquitetural”.
Mudar, nem sempre é ruim! Really!?
A experiência de desenvolvimento de um software conduz a descobertas que podem implicar, de alguma, em algum tipo de disparidade entre as arquiteturas prescritivas ou descritivas.
Há dois tipos fundamentais de degradação arquitetural:
- Architectural drift
- Architectural erosion
Vamos as definições. Comecemos pela primeira:
Architectural drifts são todas as decisões presentes na arquitetura descritiva que não estão incluídas, embasadas, ou explicitadas na arquitetura prescritiva. Entretanto, não violam qualquer decisão presente nessa.
Por outro lado,
Architectural erosions são todas as decisões incluídas na arquitetura descritiva que violam a arquitetura prescritiva.
Claramente, erosions representam algo bem mais sério do que drifts. Você não acha? Depende…
O começo do fim…
Em um dado momento do projeto, decisões vão sendo tomadas (geralmente, sem seguir uma estratégia [padrão coerente para tomada de decisões]). Um após outro, drifts vão sendo aceitos (de novo e outra vez). Lembre-se:
Uma deterioração pode ser “desfeita” através do (re)alinhamento da arquitetura prescritiva com a arquitetura descritiva.
Mas… Quem disse que é importante “revisitar” a arquitetura? Não é mesmo!? .. então .. drifts se acumulam. E como ..
Pequenas mer*#$&s fazem grandes cag$%!% …
Muitos drifts acabam “disfarçando” uma erosion … E como …
Grandes cag$%!% formam montes de bo$%#"!
O projeto se vai..
Como evitar a tragédia?
A arquitetura descritiva precisa ser idêntica a arquitetura prescritiva. Para isso:
- Precisamos delinear e explicitar claramente a arquitetura prescritiva (quanto mais claro, melhor!)
- Precisamos ponderar cuidadosamente qualquer degradação;
- Qualquer drift ou erosion precisam ser eliminados através da revisão da arquitetura prescritiva.
Com esperança, um pouco de sorte e muita fé …
Por hoje era isso.
Rodrigo Vidal
15/09/2011
Elemar excelente post
Esse eu li.. não pode reclamar 
Daniel Torres
15/09/2011
Boas Elemar,
Achei muito legal o post. Cada post publicado é certeza de um aprendizado grande. Eu tenho pensado muito ultimamente numa coisa. A maioria dos projetos que tenho participado ultimamente até que são entregues, os clientes ficam felizes e aparentemente satisfeitos com o resultado. Porém eu como desenvolvedor não sinto a mesma satisfação. Minha insatisfação se dá porque eu sei o que acontece no background. Eu tenho comigo sempre tentar fazer o melhor para que os sistemas fiquem bem organizados arquiteturalmente, pensando na manutenabilidade e reuso entre outros beneficios. Porem, diversas vezes o ‘mundo ideal’ planejado não é o que é entregue. No projeto atual que estou trabalhando, fazemos uso de web services e, como recentemente tenho feito alguns cursos voltados a SOA, tenho alguns conceitos frescos na cabeça e vi oportunidade de utilizá-los. Porem, após sugerir as melhorias na arquitetura, o cliente não quis adotar a ideia passada e impos que fosse feito da forma como ele quer. Isso não acontece esporadicamente. Tenho vivenciado isso em alguns projetos nos ultimos meses e, francamente, isso me deixa muito p#$¨& da vida. Bom, quis aqui expressar uma realidade que tenho vivenciado ultimamente. Espero que isso não seja realidade em muitos outros lugares.
Abraços,
Daniel Torres
15/09/2011
Boa Elemar!
Estamos adotando alguma(já é o inicio) metodologia aqui, e esta surgindo essas cacas no meio do caminho mais, chegaremos lá.
Daniel Torres, temos o mesmo problema aqui, minha insatisfação se dá porque eu sei o que acontece no background, e a vida do cliente é assim, quero pra ontem, e de graça. Mas a cultura podemos mudar e estamos fazendo isso! Posso perceber essa mudança através de blogs como esses do Elemar que nos ajuda disseminando o seu conhecimento.
elemarjr
16/09/2011
Olá pessoal,
Para começar, obrigado pelo feedback.
Quanto ao problema, cuidado para não considerar o cliente um mal necessário.
No post sobre boas práticas, falo que estas reduzem custos de desenvolvimento e/ou de manutenção. Vocês já tentaram usar essa abordagem para “vender” a idéia de vocês?!
No post sobre conhecer os clientes, falo que o “sponsor” geralmente é pouco sensível a detalhes. Será que não estamos falando com a pessoa errada. As vezes é bom buscar “apoio” entre os “outros clientes”
No void sobre dívida técnica, falamos sobre como “deixar para depois” … Também falei sobre isso no post sobre entropia.
Era isso,
Elemar