Arquitetura Evolutiva

Transcript

1. ARQUITETURA EVOLUTIVA
2. SOBRE MIM... Oi, meu nome é Diego. Sou de Minas e tenho mais de 8 anos de experiência em desenvolvimento web. Apaixonado pelo estudo de música, design, programação e testes. Atualmente trabalho como Engenheiro de Software e escrevo sobre desenvolvimento e carreira.
3. O QUE É ARQUITETURA DE SOFTWARE?
4. DESIGN X ARQUITETURA
5. “É um conjunto de decisões difíceis de serem mudadas no futuro.“ - Martin Fowler (Tradução livre)
6. “Um arquiteto permite que decisões importantes sejam adiantadas, mas bom arquiteto maximiza o número de decisões não tomadas.“ - Uncle Bob (Tradução livre)
7. SE TUDO É ÁGIL PORQUE A ARQUITETURA AINDA É WATERFALL
8. Nós escrevemos código e criamos estruturas hoje para reescrever os códigos e recriar as estruturas amanhã
9. ARQUITETURA DE SOFTWARE EM UM CENÁRIO DE INCERTEZAS A mudança é inevitável, evolução, entretanto, é opcional. - Tony Robbins (Tradução livre)
10. ARQUITETURA EVOLUTIVA
11. Uma arquitetura evolutiva suporta mudanças contínuas e incrementais como um primeiro princípio por meio de vários aspectos. - Rebecca Parsons (Tradução livre)
12. DE ONDE VEM AS MUDANÇAS?
13. ASPECTOS TÉCNICOS ASPECTOS NEGÓCIO • Linguagens de Programação • Bibliotecas • Ferramentas • Padronização • Performance • Modelo comercial • Inovação dos concorrentes • Necessidades dos clientes • Parcerias de negócio • Legislação
14. PRESSÃO DO MERCADO NUNCA DIMINUI
15. NOSSA ARQUITETURA PRECISA ABRAÇAR AS MUDANÇAS
16. Uma arquitetura não deve apenas atender as demandas dos usuários, desenvolvedores e proprietários em um determinado momento, mas também corresponder a essas expectativas ao longo do tempo. - Uncle Bob (Arquitetura Limpa)
17. Se você acha que uma arquitetura boa é cara, experimente uma ruim. - Brian Foote e Joseph Yoder (Tradução Livre)
18. NÓS ESCREVEMOS CÓDIGO HOJE PARA REESCREVER ELES AMANHÃ
19. Softwares podem até ser feitos do mesmo material que os sonhos (a mente humana), mas funcionam no mundo físico. - Uncle Bob (Arquitetura Limpa)
20. PRINCÍPIOS DE UMA BOA ARQUITETURA DE SOFTWARE
21. KISS Keep. It. Simple. Stupid.
22. Complexidade é o que torna o software difícil de ser modificado. - Ralph Johnson (Tradução livre)
28. LEBRE X TARTARUGA
29. COMPLEXIDADE ACIDENTAL COMPLEXIDADE ESSENCIAL É aquela que surge durante o processo de desenvolvimento e ela é causada pela abordagem escolhida para resolver o problema. É basicamente a complexidade que existe no problema que o nosso software se propõe a resolver.
31. Criar uma estrutura mais complexa que o necessário, não faz de você um bom arquiteto só satisfaz o seu ego. - Diego Borges (vulgo EU)
32. + complexidade = + débito
34. MANUTENÇÃO DE UM SISTEMA O sistema de hoje é o legado de amanhã
35. EDITAR E REZAR X COBRIR E MODIFICAR Trabalho eficaz com código legado - Michael Feathers
36. 1. Cultura de testes 2. Refatore sempre 3. Reavalie os objetivos
37. REVERSIBILIDADE Não tome decisões que você não pode reverter
38. • Evite decisões que você não pode reverter • Evite dependências (bibliotecas, frameworks, serviços, ferramentas ou linguagens) sempre que puder • Se é impossível reverter, é impossível refatorar • Existem algumas poucas coisas que não podem ser reversíveis
39. O custo é qualquer retrabalho em potencial que tenha que ocorrer uma vez que uma decisão tenha sido tomada - Rebecca Parsons (Tradução livre)
40. ÚLTIMO MOMENTO DE RESPONSABILIDADE Não é procrastinação! É tomar decisões corretas no momento correto.
41. DEPOIS É QUASE SEMPRE MELHOR DO QUE AGORA
42. BIG UPFRONT DESIGN Muitas decisões tomadas no início quando ainda não há muita maturidade
44. Quando decisões importantes são tomadas antes do momento necessário, no momento necessário essas decisões serão dificilmente revertidas.
45. ENOUGH UPFRONT DESIGN Apenas as decisões necessárias no momento necessário
48. YAGNI You. Aren't. Gonna. Need. It.
51. Não há otimização melhor do que conseguir descobrir que existe algo que não precisa ser feito.
53. O ARQUITETO COMO UM GUIA TURÍSTICO
54. OS PAPÉIS DO ARQUITETO
55. Definidor e executor: Contempla os aspectos práticos que envolvem a melhor maneira de se executar diferentes atividades. Garantindo que os processos de teste, CI/CD e definições estratégicas do ponto de vista operacional estejam sendo realizados corretamente (ou seja, do “como fazer”).
56. Mentor: Compreende os aspectos de formação e direcionamento contínuo das pessoas para realização das suas atividades. A preocupação com esta disciplina é tornar todos do seu responsáveis pela arquitetura em alguma proporção. Melhores hoje do que foram ontem. A melhor maneira de alcançar essa evolução é através de code-reviews e desenvolvimento em pares, tornando o tempo de produção também um tempo de formação.
57. Parceiro do negócio: Trata de questões que envolvem a visão macro da situação da arquitetura, podemos dizer que tem a preocupação com o ponto de vista tático (ou seja, do “porquê e o que fazer”). Para isso, precisamos criar uma estrutura de gestão que nos permita compartilhar com os demais membros do time assuntos como riscos e roadmap. Garantindo um melhor entendimento do contexto do projeto para todos.
58. TODOS SOMOS RESPONSÁVEIS POR FAZER A ARQUITETURA
59. Todos devem ter abertura para discutir o futuro da arquitetura, mas temos o dever de ser guardiões dela.
60. EXPERIMENTAR X ACERTAR
61. Discordo e me comprometo.
62. SHU-HA-RI
65. QUEBRE OS SILOS
66. Construir software é como jogar um jogo multi-player. Embora a maioria das pessoas ajam como um jogo de single-player. - Zeno Rocha
67. SE COMUNIQUE
69. OBRIGADO! Alguma dúvida? Faz uma perguntinha ai ;) @eudiegoborgs
70. OBRIGADO ANDRÉ Slide - Artigo