Executando verificação de segurança...
6

Descontinuar codigo também é importante!

Quero levantar uma discussão sobre algo que estive refletindo: o código que criamos está sempre em constante evolução. Há momentos em que precisamos descontinuar partes dele, mas como todos nós desenvolvedores sabemos, não é simplesmente uma questão de desligar uma aplicação ou remover um endpoint de um microserviço.

Atualmente, onde trabalho, lidamos com bastante código legado, embora tenhamos migrado grande parte para novos códigos, seguindo boas práticas. Ainda assim, o legado persiste, causando muitos problemas e dores de cabeça. Aos poucos, estamos trabalhando para descontinuar esse código legado.

Gostaria de entender como é na visão de vocês: como é migrar código? Como é realizar a manutenção de duas ou mais aplicações que fazem a mesma coisa? O trabalho é duplicado e os bugs surgem com mais frequência?

Vamos trocar ideias sobre isso!

Carregando publicação patrocinada...
4

O Lucas Montano fez um vídeo recentemente falando sobre uma reescrita de um sistema da empresa Waternet, da Holanda, e como fazer isso errado acabou quebrando a empresa.

Recomendo assistir porque ele explica diferentes processos de reescrita e refatoração. O vídeo responderá suas dúvidas.

3

A resposta correta seria: "Cada caso é um caso.". Ok, não diz muita coisa mas também não tem muita informação no texto. Sem informações, é possível apenas algum exercício genérico.


Dependendo da finalidade do sofware, não é "necessário" descontinuar alguma parte. Se for descontinuada, é necessário pensar que já existe alguma coisa feita com essa parte descontinuada. Qual a atitude tomar? Depende.


Código "legado" necessita de uma definição melhor. Uma linguagem que o pessoal não conheçe? Um framework que não possui mais atualizações? Qual o motivo das "dores de cabeça"? Etc..

Linguagens são programas então, vejamos uns poucos exemplos. Python é de 1991 (33 anos). Algumas coisas deixaram de funcionar e outras foram incluídas. Python 3 não roda programas escritos em Python 2. COBOL, por outro lado, é de 1959 (61 anos). Também evoluiu. Mas ainda hoje é possível compilar um programa escrito em 1970.

O Veterans Health Information Systems and Technology Architecture (VistA). O sistema tem uns 46 anos. Em 2018 contrataram uma empresa para "modernizar" o sistema e com prazo de 10 anos. Após 5 anos e inúmeros problemas (inclusive relato de mortes prematuras), desistiram da atualização.


Boas práticas existem desde 1900 e antes. Grande parte das novas é um compilado de algumas antigas. KISS vem da marianha e é anterior à década de 60. Por exemplo, o livro Thinking Forth é de 1984 (40 anos). Também não uso Forth mas, baixe o livro e apenas olhe as ilustrações e caixas de dicas. Quantas "boas práticas" tem alí?


Duas ou mais aplicações que fazem a mesma coisa? Deixe apenas a mais simples!