Sobre obsolescência de código e ciclo de vida de software





Startup, novas tecnologias, linguagens e frameworks modernos. Tudo isso é tão emocionante quando começamos a fazer algo do zero. E definitivamente tentaremos escolher tecnologias modernas e populares amadas por milhões para o nosso projeto. Mas o tempo não para sua corrida implacável e, de repente, olhamos para trás e vemos que nossa "startup" já está com 15 anos. E o mundo ao redor mudou há muito tempo. E ainda temos o mesmo Basic / Delphi / Fortran / qualquer que seja em nosso projeto. E como conviver com isso?



Não, eu não quero criar outro holivar, e isso está longe de ser um leque. É apenas minha dor pessoal liderar projetos que valem mais de um milhão de linhas de código em tecnologias desatualizadas, em particular em Delphi.



E torna-se interessante saber por quanto tempo um projeto bem-sucedido geralmente dura. Se você olhar em volta, então, em princípio, existem alguns projetos com uma "história barbuda". São eles WinRAR, Microsoft Office, AutoCAD, Photoshop, 3DSmax e muitos outros. Além disso, são projetos para um público de massa. E quantos sistemas bancários diferentes, CIS, CRM e outros sistemas "corporativos" de vários níveis existem. E muitos deles não foram escritos nos últimos cinco anos.



Claro que gostaria de acompanhar os tempos, mas migrar um grande projeto de um idioma para outro, na minha opinião, é uma tarefa difícil. Não apenas essa migração está acontecendo e a escrita de um novo código, o projeto antigo também deve continuar a funcionar, viver e se desenvolver. Em um novo projeto, é necessário repetir toda a lógica do antigo, mas nem sempre é claro. Em um projeto antigo, muita lógica pode ser construída em bibliotecas que não são suportadas por seus desenvolvedores há muito tempo. Em um novo projeto, essas bibliotecas devem ser substituídas. Se forem componentes visuais, isso é ainda mais difícil, porque além de encontrar um substituto, você também precisa considerar como reescrever o código para trabalhar com esses componentes visuais de forma que o novo componente repita o comportamento do antigo. Claro, tudo tem solução e não há meta de repetir o trabalho do projeto 100%,mas mesmo 50% de fazê-lo é muito, muito difícil e, no processo de reescrita, pode acabar descobrindo que a plataforma / linguagem na qual você decidiu reescrever não é adequada ou já está perdendo popularidade.



Claro, estou falando principalmente sobre grandes projetos com uma camada significativa de lógica. Um milhão de linhas e mais. Essa. não sobre mini-sites, não sobre microsserviços, mas sobre tais monólitos (mesmo se eles forem divididos em "componentes" / "camadas", etc.).



Gostaria de saber a opinião dos aqui presentes, vocês encontraram problemas semelhantes e como atuaram em situações semelhantes?



Que soluções você recomendaria aplicar durante o desenvolvimento para que em 10-15 anos não haja desejo de transferir o projeto para outra plataforma?



Obrigado pelas respostas!



All Articles