Conselhos sobre como lidar com código legado

O icônico APPLE MACINTOSH 128K

Quando o termo "código legado" surge, geralmente é dito ou recebido com um tom de desdém. Uma pesquisa preliminar no Google por “memes de códigos legados” traz centenas e centenas de macros de imagem de pessoas arrancando os cabelos, parecendo cansadas ou extremamente decepcionadas.

Quando comecei a trabalhar como desenvolvedor de software, em uma empresa baseada em produtos, há 5 meses, eu não tinha idéia do que era o código legado ou do que trabalhar com ele.

Durante meu quarto mês, fui convidado a adicionar um modal de filtro de comutação a um aplicativo criado por um dos meus colegas de trabalho há dois ou três anos. Parecia fácil o suficiente; Passei a maior parte dos últimos três anos trabalhando em um aplicativo incrivelmente complexo envolvendo a pilha padrão: TypeScript / React / Angular / Dotnet. Eu já havia resolvido muitos problemas exclusivos e me sentia confiante em minha capacidade de codificação o suficiente para criar um modal simples para passar parâmetros de consulta ao back-end.

Como você deve ter adivinhado, não era tão simples assim. Mas por que?

O que é um código legado e por que pode ser um desafio lidar com

Código legado é um código herdado de outro desenvolvedor ou equipe que usa tecnologias mais antigas que não são mais suportadas ou foram substituídas por uma versão mais recente. Muitos programadores dizem que "o código se torna código legado assim que é escrito". A diferença funcional entre o código "regular" e o código herdado pode ser simplesmente que ele possui convenções diferentes em comparação com o que você está acostumado a trabalhar.

No meu caso, o aplicativo utilizou o modelo de texto XAML e T4 em vez do código C # básico, e não foi tão fortemente digitado quanto eu estava acostumado. Isso tornou um pouco mais difícil para mim entender a estrutura dos dados. Nenhum tipo significava que eu estava executando o TypeErrors em tempo de execução com muito mais frequência, o que pode ser difícil de depurar quando você está gravando um recurso grande. Além disso, o aplicativo usava uma versão muito mais antiga do dotnet, que precisava ser reconciliada com uma versão compatível da biblioteca de componentes.

Antes de entrar no âmago da questão de como lidar com código legado com um senso de equilíbrio e racionalidade, quero acrescentar um aviso de que o código legado não é tão ruim e que trabalhar em um projeto legado não precisa ser terrível. Pelo contrário, trabalhar no código legado me ensinou a ser flexível, paciente e, acima de tudo, a experiência me deu a chance de resolver problemas com uma nova perspectiva em um novo contexto.

De fato, isso me tornou um desenvolvedor melhor do que era antes de começar a trabalhar na base de código acima mencionada e, esperançosamente, seu projeto legado também pode lhe ensinar algo.

Como lidar com código legado em nível técnico

Leia a documentação e os comentários do código quando possível

Em um mundo perfeito, toda base de código tem um README robusto que contém explicações concisas de como o projeto funciona, comentários sobre o código que explicam a lógica exata do autor original e todo o aplicativo faz todo o sentido. No entanto, isso raramente é o caso. Muitos READMEs não são atualizados à medida que os projetos se desenvolvem, as pessoas esquecem de escrever comentários, assumem que sua lógica é óbvia para um novo desenvolvedor ou simplesmente ficam sem tempo para cuidar dessas coisas.

Veja a base de código como um todo

Se você está perdido e não sabe por onde começar, faça a si mesmo estas perguntas:

  • Qual é o objetivo do aplicativo?
  • Como os dados fluem pelo aplicativo?
  • Como o seu recurso se encaixa no aplicativo?

Quando você pode ter uma idéia do cenário geral, é mais fácil descobrir a melhor forma de lidar com o problema. Talvez você precise criar um novo arquivo e criar um novo controlador. Talvez você precise escrever uma função utilitária e testá-la. Seja qual for o caso, entender o contexto mais amplo do seu problema é um bom primeiro passo para criar uma solução.

Teste o aplicativo manualmente e com testes de unidade sempre que possível

Quebrar um aplicativo temporariamente enquanto adiciona um novo recurso é uma inevitabilidade, independentemente do nível de desenvolvedor que você é. Isso é normal e esperado, especialmente se você é novo no trabalho, trabalha em uma base de código herdada com uma pilha desconhecida ou em alguma combinação dos dois.

A melhor maneira de impedir que essas quebras se tornem problemas de longo prazo é testar seu aplicativo minuciosamente com testes de unidade e manuais. A realização desses testes e o conhecimento exato do tipo de cobertura que você obtém deles economizarão muito tempo a você e aos futuros desenvolvedores. Além disso, testes rigorosos tornam o aplicativo mais escalável e também oferecem um pouco de dopamina sempre que seus testes são limpos. Infelizmente, há casos de teste de unidade limitados no meu cenário

Para testes manuais, você desejará desenvolver uma matriz de teste e garantir que o documento esteja acessível para futuros desenvolvedores. Para a matriz, você desejará definir um conjunto de ações, o comportamento esperado, o comportamento real ao testá-lo e quaisquer outros detalhes importantes, como:

Peça por ajuda

Supondo que seu projeto tenha sido escrito por um funcionário atual ou ex-funcionário em seu local de trabalho, alguém provavelmente sabe o que está acontecendo no aplicativo ou pelo menos sabe o suficiente para fazer com que você se solte. Aprender a engolir seu orgulho e pedir a alguém é um passo desconfortável para alguns, mas necessário para crescer como desenvolvedor, e talvez seu colega de trabalho possa lhe ensinar alguns truques novos.

Uma boa maneira de fazer uso eficiente do seu tempo (e do deles) é formular perguntas informadas. Tente voltar a olhar para a base de código como um todo e descobrir as lacunas no seu entendimento. Isso não apenas os ajudará a entender melhor qual é o seu problema, mas também mostra que você tomou a iniciativa de tentar resolver o problema sozinho.

Saiba quando reduzir suas perdas

Se você está gastando muito tempo tentando colocar o pé na porta e não avançou seriamente na implementação do recurso depois de tentar as etapas acima, pode valer a pena refatorar o código em torno do recurso. Não desista com muita facilidade, mas lembre-se de quais são seus prazos e o que o gerente de projetos espera de você.

Dito isto, há desvantagens em agir dessa maneira:

  • Reescrever o código pode apresentar erros, embora isso possa ser contornado com um bom teste de unidade.
  • Reescrever o código pode remover a funcionalidade oculta, embora isso também possa ser contornado com bons testes de unidade.
  • Se você estiver com pressa de tempo, escrever código fora do seu recurso, além do seu recurso, pode ser mais demorado do que apenas construir em torno dele.

Em suma, use seu melhor julgamento. Existem prós e contras para qualquer uma das opções, e tudo depende das circunstâncias e do orçamento do projeto.

Como lidar com o código legado em um nível psicológico

Agora que abordamos os aspectos técnicos de como lidar com o código herdado, vamos falar sobre como lidar com ele usando nossas habilidades sociais. Afinal, os desenvolvedores são pessoas, não apenas robôs de codificação, e lidar com problemas desafiadores em projetos que exigem criatividade e autoria pode ser emocionalmente desgastante, não apenas para você, mas também para seus colegas de trabalho.

Seja humilde e gentil

Isso é algo que admitirei timidamente que preciso praticar mais. Quando fui designado para o projeto modal de filtro, fiquei bastante sincero sobre como lidar com o código e desagradável enquanto o autor original do código estava sentado a 15 pés de mim. Eu pretendia que meus comentários fossem uma piada, mas, em retrospectiva, reconheço que estava sendo arrogante e ofensivo e que deveria ter sido mais empático.

Existem muitos fatores que podem levar à aparição de códigos herdados, que você deve levar em consideração antes de começar a criticar o autor ou assumir o pior deles (isso está fracamente ligado ao erro de atribuição fundamental!).

O autor original pode ter tido suas razões para escrever código da maneira que fez.

As restrições de tempo e de tecnologia podem fazer com que uma pessoa escreva um código que funcione, mas que não tenha necessariamente a melhor convenção. Se você se imaginar em uma situação com pouco tempo, ferramentas desatualizadas e uma lista de tarefas a uma milha de comprimento, provavelmente também não escreveria o melhor código!

Convenções mudam.

Em projetos mais antigos, a convenção de código está usando aspas simples para declarar seqüências de caracteres e dois espaços eram iguais a uma guia. Tivemos várias Classes pequenas aninhadas dentro de um único arquivo. Em nossa convenção atual, usamos aspas duplas e quatro espaços, e cada classe, por menor que seja, vive em seu próprio arquivo .cs no diretório Models. E em vários anos, tenho certeza de que isso também mudará.

Todo o código acaba se tornando legado

Isso está relacionado ao ponto anterior: seu código acabará sendo legado. À medida que você sobe na hierarquia da antiguidade, novos desenvolvedores serão contratados e terão que manter seu código antigo. Você pode escrever um código DRY limpo, sem falhas, mas, uma vez que as convenções mudem ou as tendências mudem, esses novos desenvolvedores poderão visualizar seu código da mesma maneira que você vê o código legado de outros.

Orgulhe-se dos pequenos sucessos

Não é fácil trabalhar fora de suas convenções habituais; há uma razão para a enorme quantidade de memes e piadas sobre como lidar com código legado. Se você já aprendeu um idioma fora do seu idioma nativo, sabe como é se esquecer de uma palavra ou termo no seu segundo idioma, mas lembre-se dele no seu idioma nativo e não poderá traduzir essa lacuna. O mesmo vale para a mudança entre convenções modernas e antigas. Às vezes, leva apenas um minuto para se recuperar.

Ao navegar com êxito no código legado, você mostra sua capacidade de adaptação, o que é uma habilidade importante que beneficia você no seu trabalho atual e em todos os seus futuros trabalhos, estejam eles no campo tecnológico ou não. O código legado é o playground perfeito para praticar essa habilidade.

Em conclusão

Use esse tempo para reforçar sua própria escrita de código

Agora que você já teve a experiência de trabalhar em uma base de código herdada, deve se afastar dela com uma noção melhor do que gosta e do que não gosta em termos de ferramentas e convenções. São coisas que você pode levar adiante em projetos futuros e torná-lo melhor na revisão do código de outras pessoas, oferecendo críticas construtivas e dando orientação.

Desenvolver aplicativos para o usuário e o futuro desenvolvedor

Se você teve uma ótima experiência com documentação e comentários de código ou sem documentação ou comentários de código, pode ver como a documentação e os comentários são ferramentas poderosas para ajudar futuros desenvolvedores a navegar no projeto. Você compartilha um objetivo comum de desejar um aplicativo suave, funcional e SECO; manter a documentação e deixar para trás comentários informativos sobre o código é uma boa maneira de preencher essa lacuna.

Lembre-se de que seu código também será legado algum dia

Já mencionei isso algumas vezes, mas é importante reiterar que seu código também será legado, não importa o quão SECO e intocado sejam seu código e lógica.

O ponto mais importante é ser flexível, humilde e poder aprender definitivamente novos truques com o código antigo.