Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Evolução e manutenção da arquitetura de projeto...

Evolução e manutenção da arquitetura de projetos na vida real: lições aprendidas

Nesta palestra, apresento os desafios e melhores práticas para evoluir e manter arquiteturas de software no mundo real. Trarei alguns dos principais obstáculos enfrentados, como gerenciar a complexidade, lidar com a mudança e garantir a saúde da arquitetura. Também trarei algumas técnicas comprovadas, como definir métricas e indicadores-chave, usar funções de aptidão (fitness functions) para orientar a evolução, e implementar mudanças de forma incremental e segura. Por fim, vou explorar um pouco do potencial de automação da governança de arquitetura, usando ferramentas e processos para assegurar conformidade e alinhamento. Através de exemplos práticos e estudos de caso, vou trazer lições sobre como projetar arquiteturas que evoluem com o tempo, lidando com armadilhas comuns, dívida técnica e outros problemas de sustentação de arquiteturas que já estão em produção

Jessilyneh

July 18, 2024
Tweet

More Decks by Jessilyneh

Other Decks in Programming

Transcript

  1. EVOLUÇÃO E MANUTENÇÃO DA ARQUITETURA DE PROJETOS NA VIDA REAL:

    LIÇÕES APRENDIDAS JÉSSICA FÉLIX (JESSILYNEH)
  2. Dificuldades de manter software evoluindo de forma rápida e saudável

    @jessilyneh Sobrecarga do time responsável pela manutenção e evolução, principalmente se o processo de governança for manual, em maioria Débitos técnicos acumulados por anos Arquitetura que cresceu de forma reativa, sem um minimo planejamento Sistemas muito complexos, custos, etc etc...
  3. Em vez de evoluir a arquitetura de software a cada

    nova mudança que ocorre, a arquitetura original deve ser capaz de permitir os tipos mais comuns de evolução. @jessilyneh
  4. Erosão Arquitetural @jessilyneh quando a arquitetura de um sistema de

    software se degrada ao longo do tempo devido a decisões e implementações realizadas pelos desenvolvedores, que acabam violando os princípios e diretrizes arquiteturais originais, conceito elaborado por Perry e Wolf em 1992.
  5. Manutenção @jessilyneh Requer a mudança do design do sistema: correção

    de erros, adaptação para novos ambientes e adição de novas caracteristicas (PARNAS, 1994)
  6. Evolução @jessilyneh Subtende a ideia de mudança essencial que não

    está transparente no termo de manuteção. Sugere novos designs evoluindo de sistemas antigos. (GODFREY;GERMAN,2008)
  7. Arquitetura de Software: Descreve a estrutura e os componentes de

    um sistema de software, incluindo as interações entre eles. Evolução de Software: O processo de mudanças e melhorias em um sistema de software para atender às novas exigências de mercado. @jessilyneh
  8. Método de Análise de Tradeoff de Arquitetura (ATAM) é um

    método utilizado para avaliar os atributos de qualidade de arquiteturas de software, como desempenho, disponibilidade e segurança. O ATAM é aplicado nos estágios iniciais do ciclo de vida de desenvolvimento de software (SDLC) para mitigar riscos em arquiteturas de software @jessilyneh
  9. Fase 1: Apresentação da arquitetura. Fase 2: Investigação e análise.

    Fase 3: Teste. Fase 4: Entrega. @jessilyneh Método de Análise de Tradeoff de Arquitetura (ATAM)
  10. 8 Leis de Lehman @jessilyneh Lei da Mudança Contínua (Continuing

    Change): Sistemas do tipo E devem ser continuamente adaptados, caso contrário, eles se tornarão progressivamente menos satisfatórios em uso.
  11. 8 Leis de Lehman @jessilyneh Lei do Aumento da Complexidade

    (Increasing Complexity): À medida que um sistema do tipo E evolui, sua complexidade aumenta, a menos que seja feito um trabalho para mantê-la ou reduzi-la.
  12. 8 Leis de Lehman @jessilyneh Lei da Auto-Regulação (Self Regulation):

    Os processos de evolução de sistemas globais do tipo E são autorregulados.
  13. 8 Leis de Lehman @jessilyneh Lei da Conservação da Estabilidade

    Organizacional (Conservation of Organisational Stability): A menos que os mecanismos de feedback sejam ajustados adequadamente, a taxa de atividade global efetiva média em um sistema do tipo E em evolução tende a permanecer constante ao longo da vida útil do produto.
  14. 8 Leis de Lehman @jessilyneh Lei da Conservação da Familiaridade

    (Conservation of Familiarity): Em geral, o crescimento incremental e a taxa de crescimento a longo prazo de sistemas do tipo E tendem a diminuir.
  15. 8 Leis de Lehman @jessilyneh Lei do Crescimento Contínuo (Continuing

    Growth): A capacidade funcional de sistemas do tipo E deve ser continuamente aumentada para manter a satisfação do usuário ao longo da vida útil do sistema.
  16. 8 Leis de Lehman @jessilyneh Lei do Declínio da Qualidade

    (Declining Quality): A menos que sejam rigorosamente adaptados para levar em conta as mudanças no ambiente operacional, a qualidade de sistemas do tipo E parecerá estar diminuindo.
  17. 8 Leis de Lehman @jessilyneh Lei do Sistema de Feedback

    (Feedback System): Os processos de evolução de sistemas do tipo E são sistemas de feedback multiníveis, multilaços e multiagentes.
  18. Evolução de Software Baseada em Avaliação de Arquitetura @jessilyneh Aplicação

    do Roteiro O artigo apresenta um exemplo de aplicação do roteiro de avaliação de arquitetura em um sistema para automação de linhas aéreas. O exemplo detalha os passos do ATAM e como eles foram aplicados ao sistema. .
  19. Evolução de Software Baseada em Avaliação de Arquitetura @jessilyneh Conclusões

    Avaliação de arquiteturas é essencial para a evolução de software. A utilização do ATAM como um roteiro para a evolução arquitetural pode ajudar a garantir que os sistemas de software sejam capazes de atender às novas exigências de mercado e manter a satisfação dos usuários ao longo do tempo.
  20. Evolução, Adaptação e Mudanças inevitáveis @jessilyneh - adaptar a arquitetura

    de software às mudanças constantes nas demandas dos usuários e no ecossistema de desenvolvimento de software. - arquitetura deve ser maleável e capaz de se adaptar ao longo do tempo - fazer mudanças incrementais e controladas para evitar a degradação da arquitetura. - considerar múltiplas dimensões arquiteturais ao planejar a evolução da arquitetura.
  21. Fitness Function para governança de evolução da arquitetura @jessilyneh Um

    mecanismo que define e valida propriedades-chave da arquitetura, permitindo que ela evolua de forma controlada. - Escopo Holistico ou Atomico - Diferentes cadências - Resultados Estáticos ou Dinâmicos, automatizadas ou manuais -Proativas, Emergentes - Genéricas ou específicas
  22. Fitness Function para governança de evolução da arquitetura @jessilyneh Ford,

    N., Parsons, R., Kua, P., & Sadalage, P. (2023). Building Evolutionary Architectures (2nd ed.). O'Reilly Media. Monitoramento DevOps Métricas de código Engenharia de caos Estruturas de teste de arquitetura Varredura de segurança
  23. fitness function-driven architecture @jessilyneh As fitness functions são usadas não

    apenas para validar propriedades da arquitetura, mas para ativamente moldar e guiar as decisões de design arquitetural.
  24. Caso de estudo @jessilyneh o arquiteto projetou o sistema para

    que o serviço orquestrador contenha o estado do fluxo de trabalho. Se algum dos serviços se comunicar entre si, ignorando o orquestrador, a equipe não terá informações precisas sobre o estado do fluxo de trabalho. No caso de ciclos de dependência, existem ferramentas de métricas para permitir que os arquitetos façam verificações em tempo de compilação. No entanto, os serviços não estão restritos a uma única plataforma ou stack de tecnologia, tornando altamente improvável que alguém já tenha construído uma ferramenta que corresponda exatamente a uma arquitetura específica.