Chamamos de código legado aquele que está presente na aplicação há bastante tempo. Por exemplo, o site de uma padaria de bairro que foi constuído há 3 anos e mantém em sua estrutura trechos de código escritos na época da primeira versão do sistema. É bastante comum encontramos casos como esse em empresas de tecnologia, pois as empresas não criam novas aplicações todos os dias. O cenário padrão que uma pessoa profissional da área encontra é a de cuidar das aplicações que já existem na empresa.

Entendendo o Passado

Esse código que se prova ao longo do tempo e entrega valor desde o primeiro momento, é muito valioso. Ele é uma documentação histórica porque contém as decisões que o time de tecnologia tomou para guiar a evolução do produto. Como pessoas desenvolvedoras, somos inclinados a sempre oferecer a melhor solução para o momento, de acordo com nosso nível de senioridade.

Respeito às Decisões Passadas

Considerando que o site da padaria foi inicialmente desenvolvido por uma pessoa desenvolvedora junior, ela aplicou as ferramentas que conhecia na época, de acordo com as possibilidades que as tecnologias utilizadas permitiam. Esse site pode ter sido entregue apenas com HTML, CSS e JavaScript, sem utilização de frameworks de frontend ou backend. O cliente não entende como uma aplicação funciona por debaixo dos panos, ele deseja somente que ela resolva seu problema.

Se uma pessoa dos níveis de senioridade pleno ou sênior analisar as peculiaridades do site da padaria, com certeza poderá pontuar dezenas de melhorias em sua estrutura. Mas só podem fazer isso porque sua bagagem de conhecimento é naturalmente maior que a pessoa junior que o desenvolveu. Respeitar o que já existe é uma postura empática com as pessoas que vieram antes de nós naquele cenário.

Além do nível de senioridade impactar diretamente o desenvolvimento de aplicações, não devemos esquecer do tempo, especialmente para startups. Empresas assim precisam validar o produto no menor espaço de tempo possível. É quando um MVP deve ser disponibilizado em poucos dias, e em alguns casos com uma equipe reduzida ou até mesmo uma única pessoa desenvolvedora.

Dado o tempo curto de desenvolvimento, essa pessoa não tem tempo para garantir todos os padrões de qualidades existentes. Na vida real acontece bastante a situação de: "Bota pra rodar, valida com os clientes e testa depois", onde esse "depois" pode nunca chegar e a aplicação se manter sem testes automatizados durante todo seu tempo de existência.

Temos que considerar também a evolução constante das ferramentas que utilizamos para trabalhar. São desenvolvidos frameworks e bibliotecas constantemente para solucionar problemas que já encontramos um dia ou estiveram presentes na rotina de outra pessoa do mercado. Assim, sempre terá alguma coisa que pode ser otimizada, aprimorada ou refatorada em nossas entregas, dado o ritmo frenético em que a tecnologia se transforma ao longo do tempo.

Conservação de Recursos

"Em time que está ganhando não se meche". Concordo com essa postura quando se trata de sistemas, pois se ele segue solucionando o problema dos clientes da empresa e gera valor constantemente, nossa energia deve ser investida em aprimorar a qualidade, segurança e evolução do mesmo, para que ele se mantenha competitivo frente aos concorrentes de mercado.

Já ouvi falar que "É impossível reescrever uma aplicação inteira". Também concordo com essa afirmação, dado que uma aplicação que já está em produção por um tempo considerável, possui muitas faces e peculiaridades. Logo, não é tão simples passá-la de linguagem X para Y, especialmente devido ao tempo que essa ação irá consumir. Devemos sempre nos recordar que uma equipe de tecnologia deve dar manutenção no sistema, corrigir bugs, escrever testes e desenvolver novas funcionalidades.

Nesse sentido, considerando que temos apenas uma equipe de desenvolvimento no produto, não faz sentido que todas as pessoas parem de fazer seu papel para tentar migrar a aplicação para o mais novo framework hype do momento que ainda nem se provou no tempo. Devemos sempre nos policiar para usar ferramentas robustas em nossos projetos, para não sermos pegos de surpresa quando um recurso falhar miseravelmente e prejudicar nossos clientes de alguma forma.

Manutenção e Evolução

Para garantir que nosso querido legado se mantenha saudável, devemos sempre nos atentar a qualidade do mesmo. Implementar testes, em casos que eles ainda não existam no sistema, é dar ao código uma camada extra de segurança. Pois quando o código afirma que: x + y = 2, os testes vão lá conferir: éEsperadoQue(x + y).seja(2).

Testar o código irá reduzir erros e bugs, aprimora a qualidade do sistema e as entregas do time, o que gera mais tranquilidade para as pessoas desenvolvedoras ao longo do tempo.

Refatorar trechos que podem ser aprimorados também é uma boa prática nesse caso. Funções com centenas de linhas e responsabilidades, podem ser fonte de muitos problemas e dores de cabeça.

Também podemos substituir dependências depreciadas no sistema, ou realizar a troca de ferramentas para atender aos requisitos específicos de negócio. Se o negócio solicitar um tempo menor na comunicação com o Backend, podemos realizar um levantamento do tempo gasto em requisições com a utilização de diversas ferramentas.

O código legado é uma aplicação que passou por diversas validações, conquistou clientes e gerou recursos para o negócio. Possivelmente é a primeira versão de um sistema que resolve o problema dos clientes e agrega valor em alguma etapa do seu dia. Devemos tratá-lo com empatia e responsabilidade, respeitando as pessoas que estiveram ali antes de nós, aprendendo com elas e somar a aplicação o nosso conhecimento ao longo do tempo. Vida longa às pessoas desenvolvedoras que admiram os códigos antigos!

Imagens geradas pelo DALL·E 3