Desenvolvimento de software é um constante “constrói, corrige e melhora”. Mudanças na arquitetura são completamente normais de acontecer ao longo do tempo. As vezes, até cogitamos reescrever todo um código do zero devido à sua complexidade e dependências, mas isso dificilmente será uma opção. As funcionalidades precisam continuar enquanto você melhora o software, existem casos que é preciso pensar em uma "janela" para uma migração ou possível chance da aplicação ficar fora do ar enquanto um ajuste é implementado.
Neste artigo vou compartilhar com você os meus aprendizados fazendo um discovery de melhoria de arquitetura. Eu não estava presente no momento em que decidiram construir o software da maneira que está hoje, não conheço toda infraestrutura ou dependentes externos. A única informação que eu tinha eram apenas 2 parágrafos explicando o que o software faz.
🤯 O que é um discovery?
Discovery é um estudo aprofundado sobre algum problema ou solução, entender o porquê, suas necessidades, informações detalhadas e possibilidades de melhorias antes de começar a resolver. Muitas vezes um documento é gerado a partir desse estudo, recomendo muito que seja assim devido ao atual modelo de trabalho remoto, quanto mais informação por escrito melhor.
😬 Não tenha medo de perguntar
Conversei com as pessoas mais antigas do time sobre a arquitetura, entendi os problemas que precisavam ser resolvidos e pontos de melhoria. Depois disso, tive algumas ideias de onde atacar.
Tendo pontos em que você queira mexer, dependendo de como está a organização de equipes na sua empresa, talvez você não tenha acesso à todas as pontas do sistema como a infraestrutura ou alguma outra aplicação que se relaciona com a sua, então pense em perguntas e jogue nos canais de comunicação da empresa. Se possível, marque uma chamada com essas outras pessoas que estão relacionadas com o sistema ou que já fizeram uma melhoria de arquitetura semelhante a que está pretendendo fazer, pois se isso já foi feito antes é melhor coletar informações de como fazer, erros e acertos pelo caminho.
Nenhuma pergunta é boba. Eu sou desenvolvedora, não tenho muito domínio quando o assunto é infraestrutura ou até mesmo banco de dados, e nesse discovery fiz muita pergunta sobre kubernetes, inclusive fiz perguntas do tipo: "Como eu instalo o kubernetes dessa aplicação na minha máquina?" e o pessoal foi me ajudando ou buscando entender junto comigo.
😅 Menos é mais
Diminuir os fluxos e chamadas externas são melhorias válidas, reduzem a quantidade de requisições ou processamentos mas ainda é preciso considerar padrões e responsabilidades de cada camada do sistema.
Nesse discovery consegui pensar em um caso onde eu poderia remover 2 serviços e abstrair suas funcionalidades para recursos que a Google Cloud Plataform me oferecia.
🧐 Monte o quebra cabeça com desenhos
Fazer desenhos é muito importante para dar clareza ao que você está pensando, fazer rascunhos a mão ou em uma lousa te ajuda a pensar, também utilizo muito o Excalidraw para criar esses desenhos de fluxos e exportar a imagem.
😎 Ler muito e fazer pequenos projetos de demonstração
Ler é uma habilidade muito importante na nossa área, você vai ter que ler código, erros, testes, documentações, perguntar em fóruns, redes sociais, juntar informações e filtrar o que pode ser implementado ou não.
A partir dessas leituras você pode fazer pequenas explorações, um projeto simples para testar quais problemas você pode encontrar pelo caminho e se o caminho que você está pensando em tomar realmente é o melhor.
👀 Feedbacks constantes
- Sempre que finalizar sua conclusão sobre o discovery valide com o seu time e as partes envolvidas, assim você consegue fazer os ajustes na documentação antes de partir para a implementação.
- Tendo o ok de todo mundo, publique essa documentação e comece a dividir em tarefas com o máximo de detalhes possíveis, desde exemplo de código a acessos necessários e com quem falar.
👉 Concluindo
Consegui pensar em como melhorar a arquitetura em 3 etapas, de uma maneira mais realista e que dava para ir tocando aos poucos, durante as minhas validações com o time reduzimos apenas para duas etapas. Com isso criei as tarefas detalhadas no backlog e sempre referenciando o documento de Discovery. Claro, podem surgir surpresas no meio do caminho, uma coisa ou outra pode ser implementada diferente do que foi explorado, mas o importante é ter feito um bom estudo antes de começar tudo, e também serve para compartilhar conhecimento com o time, por mais que uma pessoa não atue muito no contexto da aplicação que foi estudada ela saberá sobre esse estudo e, caso esteja confortável para puxar algumas tarefas, a curva de aprendizado para entender o sistema será menor.
😎 Se interessou pelo conteúdo e quer saber mais? Siga e fique por dentro dos artigos aqui no blog!
👀 Para mergulhar em como é trabalhar na Globo, nosso dia a dia e oportunidades, acompanhe os canais:
Linkedin - Vem pra Globo | Youtube - Vem pra Globo | Instagram - @vempraglobo