Modernização eficaz de sistemas de software legados
Esbarrei em uma conversa no slack onde reportaram o "problema" de trocar a arquitetura de uma aplicacao existente, onde temos duas hipoteses:
- Reescrever um codebase pedaço-por-pedaço em numa nova arquitetura dentro do mesmo repositorio
- Reescrever codebase em um repositorio novo
Acho que alguns aqui ja passaram por isso e aplicaram as duas aboragens, no meu caso mudamos na empresa que trabalhei mudamos de um MVC para DDD utilizando o mesmo repositorio e mudando em pequenas partes, trabalho de formigunha mesmo. Tambem onde estou trabalhando, como utilizamos microservices, acabamos por reescrever o codigo em um repo diferente. Dito isso vi no mesmo slack um resumo dessas duas abordagens, por um usario chamado "DanielzinDaFeirinha":
Já usei as duas abordagens (no mesmo repo e num repo separado. Atualmente estou trabalhando em uma num repo separado.
Mesmo repositorio:
As maiores limitacoes/desvantagens foram:
- Tu fica escravo da infra atual.. Versão de pacotes, libs, etc.
- Tu faz o deploy da mesma app, só que um pedaço de source novo.
Vantagens: - Tu consegue retorno disso muito rapido.
- Por estar no mesmo repo, tu consegue ir deletando as partes antigas e/ou substiturindo as antigas pelas novas.
- Tu pode usar o código escrito no mesmo repo pra usar o outro novo repo quando quiser.
Repositório novo/separado):
Vantagens:
- Total liberdade pra usar novos componentes e libs.
- Nova pipeline de CI, Deploy etc.. tudo novinho.
- Servidores de app também novos e com settings que não dava pra fazer na antiga.
Desvantagens: - Na arquitetura antiga havia muito código util que não estavamos esperando em reescrever na nova.
- Tempo de entrega está sendo maior que o esperado.
Outro usuario compartilho o link, ainda nao li tudo mas parece bem interessante :
https://martinfowler.com/articles/patterns-legacy-displacement/
Estou compartilhando isso pois achei bem interessante e foi o que eu tambem senti nessas abordagens, creditos especiais ao pessoal do Slack :)