O seu software será reescrito

Publicado em Fevereiro 22, 2016

Então, tem essa coisa sobre o seu sistema.

Ele nasceu para morrer.

Estou falando mais especificamente sobre sistemas web, porque essa é a minha área de atuação, mas é válido para várias áreas de desenvolvimento de software. Os sistemas são criados para serem destruídos a longo prazo. E tudo bem.

Vou me explicar.

Se você já trabalhou em algum grande projeto, ou por alguns anos em uma empresa, já viu o que as pessoas chamam de código legado. É mais conhecido como aquele código que roda na produção há tanto tempo que as pessoas não sabem mais como funciona. Às vezes, esses sistemas legados possuem os recursos essenciais da empresa, dos quais todos os outros sistemas satélite dependerão. Não é comum termos esse cenário assustador, onde minha “pedra fundamental” funciona, mas ninguém sabe exatamente como e todo mundo tem medo de tocá-la.

Como isso acontece é um relativamente simples:

1. Começamos com alguma equipe de desenvolvimento que constrói o sistema X
2. Todo mundo sabe tudo sobre X (melhor cenário)
3. Com pessoas novas entrando e outros membros saindo(realocação, aposentadoria, etc.), inicia-se o processo de erosão de software e as coisas ficam complexas
4. X cresce em complexidade e tamanho, e os membros não sabem mais como algumas partes funcionam
5. Os membros ficam com medo de tocar em algumas áreas de X, temendo efeitos colaterias (geralmente nas funcionalidades centrais ou críticas)
6. Essas “áreas escuras” crescem em número até que haja mais “zonas de medo” do que “zonas conhecidas”
7. Todo o desenvolvimento atinge níveis baixos de velocidade

Por volta do 5, alguns desenvolvedores já estarão alegando que o sistema precisa ser reescrito. Aos 7, a velocidade geral de desenvolvimento atinge um ponto terminal, no qual o valor comercial entregue é quase nulo e mais desenvolvedores devem ser alocados ao projeto. Infelizmente, essas novas pessoas geralmente tornam as coisas piores, por causa do ambiente já caótico.

(E por “tornar as coisas piores”, quero dizer que eles geralmente adicionam camadas de abstração para evitar as “zonas de medo”, o que ao invés de mitigar apenas aumenta o problema)

Mas como você pode esperar reescrever seu sistema principal? Tanto tempo gasto em um produto para simplesmente “recriá-lo” não parece um bom negócio.

(Os bancos, até hoje, colocam mais dinheiro em COBOL porque é tão difícil e tão caro tentar reescrever todos os seus sistemas que aparentemente eles desistiram de tentar. Não os culpo)

Pensando nesse problema (e em como resolvê-lo), podemos perceber que esse comportamento potencialmente ocorrerá em qualquer sistema. Com a aceleração da tecnologia, um novo sistema pode se tornar obsoleto em menos de um ano. Recentemente, vi um ser chamado de “legado” dentro de seis meses. E sim, às vezes é apenas a ânsia dos desenvolvedores em experimentar coisas novas, mas os cenários devem ser analisados para verificar caso a caso.

Com isso em mente, podemos chegar à próxima conclusão: Em um projeto que está previsto para ser executado por mais de um ano (falarei sobre estimativas em outro post :-)), há uma boa possibilidade de que ele nasça com o rótulo “legado” nele. E quero dizer qualquer sistema, não apenas projetos de “reescrita de sistema”.

Lembro-me claramente de uma de minhas antigas experiências, em que trabalhávamos com um grande sistema antigo e, depois de grandes discussões e muita política, a equipe de desenvolvimento conseguiu a aprovação dos gestores para recriar o sistema. Totalmente do zero!

Na época, fiquei feliz com a decisão e parecia o caminho certo. Então, fui falar com um dos programadores mais antigos sobre isso, e ele apenas me perguntou: “Isso é bom … mas o que está nos impedindo de não ter o mesmo problema no futuro?”, E até hoje eu não sei o que eu poderia ter respondido a ele.

Não acredito que haja uma maneira de resolver esse problema, mas acredito que existam maneiras de mitigá-lo. Testes unitários são muito úteis, mas eu os vejo mais como uma forma de ajudar na manutenção do que para tornar mais fácil reescrever um sistema. Quer dizer, ajuda, mas se você quiser mudar de tecnologia, provavelmente jogará fora todo o pacote.

(mas não posso esperar resolver nada em um projeto que não tenha testes unitários. É o mínimo em um projeto sério)

Acredito que a melhor estratégia é abraçar a ideia de reescrita. Manter sistemas legados funcionando é muito caro, e contratar pessoas e treiná-las para aprender algo com um software antigo é ainda mais caro. Portanto, acho que abraçar a ideia é a melhor maneira.

“Mas vou continuar reescrevendo meu sistema o tempo todo? Como posso encontrar tempo para desenvolver novas funcionalidades? “, Posso ouvir suas reivindicações, leitor hipotético, e entendo você.

O meio-termo seria: manter os sistemas tão pequenos que o processo de escrever e reescrever levaria semanas e não anos. Para chegar a esse cenário, você precisará separar seu software em vários subsistemas, e não estou falando de componentes ou arquitetura de plug-ins. A ideia é ter um ecossistema de softwares, idealmente se comunicando por meio de REST para reforçar a ideia de peças soltas e forçar os desenvolvedores a chegarem a uma interface ideal. Para manter tudo junto, você precisará, além dos testes unitários, de testes complexos de integração, que atingem cada um desses sistemas. Dessa forma, você pode simplesmente jogar um fora e recriá-lo sem muita dor e ter a garantia de que tudo o resto funcionará.

Sim, estou falando sobre uma arquitetura de microsserviços. Acredito que, hoje, com a nuvem ao nosso alcance, isso é possível e desejável. Podemos criar e destruir VMs de forma automatizada e manter todo o ecossistema OK. Se você não pode usar a nuvem, docker e kubernates podem ser seus melhores amigos. O que quero dizer é que há ferramentas para pensar sobre tal implementação

Eu entendo que “microsserviço” é hoje uma palavra da moda, e se você não gostar, basta chamá-lo de arquitetura de serviços. Mas o conceito existe há algum tempo, até mesmo a ideia de “Quebrar o grande problema em uma série de outros menores” é todo o núcleo do desenvolvimento orientado a objetos. Devemos pensar mais sobre isso e usar esse conhecimento com mais frequência.