Se você está abrindo este artigo, presumo que lida com código legado regularmente, senão diariamente, em seu trabalho como desenvolvedor de software. E também presumo que você está decidido a enfrentá-lo, aprender com ele, prosperar nele e viver uma vida feliz (bem, na medida em que o código legado está envolvido, isto é!).
Se essas suposições estiverem corretas, então você veio ao lugar certo. Este artigo, inspirado no primeiro capítulo do livro "The Legacy Code", lhe dará insights sobre como perceber o código legado, como agir sobre ele, como agir sobre seus colegas desenvolvedores e como viver uma vida feliz (bem, dentro das limitações impostas pelo código legado).
O Que Realmente Significa Código Legado?
Primeiro as coisas primeiras. Vamos começar concordando sobre o que chamamos de código legado. Você tem uma ideia razoável do que é, eu também, mas vamos nos certificar de que estamos na mesma página.
Existem várias definições de código legado por aí. Por exemplo, em seu livro "Working Effectively with Legacy Code", Michael Feathers define código legado como código sem testes. A Wikipédia oferece uma definição mais formal, que é "código fonte que se relaciona a um sistema operacional ou outra tecnologia de computador não mais suportada ou fabricada". Há também definições menos formais, por exemplo, algumas pessoas chamam de código legado o código que foi escrito antes de chegarem a uma empresa.
Para o nosso propósito, usaremos uma definição que tenta se ater ao significado de código legado em uso, aquela em que você provavelmente pensou ao ler a capa deste artigo. Quando falamos sobre código legado, significaremos código que:
- é difícil para você entender,
- você não se sente confortável em mudar,
- não tem testes automatizados abrangentes.
Você Não se Tornou um Desenvolvedor para Isso
Código legado pode ser difícil de encarar, especialmente no início de sua carreira, quando você chega no seu primeiro dia, animado para ser pago por passar seus dias programando. De fato, código legado não se parece em nada com o que as escolas ensinam. Se você estudou ciência da computação, tipicamente recebia projetos que construía do zero. Você os entendia bem porque projetou partes consideráveis, se não a maioria.
Agora, você está diante de uma base de código existente que é difícil de entender (por causa da parte 1) da definição), e é uma jornada muito menos suave do que escrever seu próprio código. Além disso, você tem que modificá-lo! Como desenvolvedor, você é pago para mudar código, não apenas para ficar olhando para ele e tentando decifrá-lo. E a parte 2) da definição de código legado o coloca em uma posição difícil.
Se reconhecendo nisso ainda? Se sim, então ótimo, porque este artigo é direcionado a você. A primeira coisa que quero que você perceba é que você e sua empresa não são os únicos enfrentando código legado. Longe disso. Eu trabalhei com grandes bases de código (na casa das dezenas de milhões de linhas de código), sou um organizador de um meetup de Software Crafters, vou a um número razoável de conferências e mantenho um blog popular sobre como tornar o código mais expressivo (fluentcpp.com¹). Em todos esses lugares, encontro pessoas que lidam com código legado diariamente. E posso lhes dizer, código legado está em toda parte.
Este artigo trata de confrontar essa realidade da programação. Aqui está o programa: começaremos com a atitude certa para lidar com código legado (Capítulo 1 do livro), depois passaremos para como usar código legado para melhorar suas habilidades de programação (Capítulo 2 do livro) e onde encontrar bom código para se inspirar (Capítulo 3 do livro). Isso constitui a Parte I do livro, sobre como abordar o código legado.
A Reação Natural: Quem Diabos Escreveu Isso?
Imagine-se navegando em uma base de código legado. Você está procurando por algo e se depara com um monte de código emaranhado que você não consegue entender. Ou algum código que parece muito mal escrito. Ou ambos.
Como você reage? Uma das possíveis reações é a natural – ou primal. Consiste em decidir que:
- Este código é um monte de lixo,
- A pessoa que o escreveu não tinha ideia do que estava fazendo,
- Você teria feito um trabalho muito melhor,
- Você é muito melhor do que isso, talvez devesse procurar outro lugar que mereça suas habilidades.
Você já se sentiu assim? Eu vi muitas pessoas se sentirem assim. Eu mesmo já experimentei isso antes de saber mais. E é normal, porque é isso que essa mentalidade é: primal. É o que estamos programados para fazer, por qualquer razão psicológica que nos faça sentir bem com isso. Essa reação inicial pode até nos confortar temporariamente, reforçando uma sensação de superioridade ou nos permitindo evitar a tarefa difícil de tentar entender o código. Podemos nos convencer de que o problema não está em nossa capacidade de compreensão, mas na incompetência de quem escreveu o código.
Mas, muitas vezes, colocar seu chapéu racional oferece uma perspectiva totalmente nova sobre um pedaço de código. E se você é um desenvolvedor de software, é um esplêndido chapéu racional que você está usando. Então, vamos nos vestir e colocá-lo: vamos ver o código legado pelo que ele realmente é.
Uma Visão Humilde do Código Legado
Código legado não é seu inimigo. De fato, quando você pensa sobre isso, todos nós escrevemos código legado em potencial. Aquele código perfeito que você escreveu no ano passado? Se você o olhar agora, provavelmente encontrará maneiras de melhorá-lo. Se você não encontrar, pode ser um sinal de que você não aprendeu muito no último ano – e isso certamente não é o que você deseja.
Código legado frequentemente é mais ou menos antigo. Se você viajar mentalmente de volta ao tempo em que foi escrito, você acha que as pessoas sabiam tanto quanto você hoje?. A pessoa que o escreveu conhecia as melhores práticas que estamos familiarizados hoje?. Talvez sim, talvez não. Mas mesmo que conhecessem, as melhores práticas evoluem com o tempo. A tecnologia também evolui. O código que era considerado bom há alguns anos pode parecer antiquado hoje. Um pensamento perturbador é que o melhor código que podemos escrever agora pode ser ridicularizado em dez anos.
Então, se estivéssemos na posição real da pessoa que escreveu aquele código, pode muito bem ser que não tivéssemos feito um trabalho tão melhor assim. O que é ainda mais humilhante é dedicar um tempo para pensar sobre como teríamos resolvido o problema que algum código está tentando resolver. Ao analisar um pedaço de código legado rapidamente, podemos ver coisas que parecem absurdas, e nosso cérebro reptiliano começa a emitir aquele sentimento de "quem diabos escreveu isso?". Mas se dedicarmos um tempo para analisar o problema que o código está resolvendo, muitas vezes perceberemos que não é tão trivial quanto parecia inicialmente.
Além disso, código legado raramente é o trabalho de uma única pessoa. Ele evolui ao longo do tempo, com várias pessoas contribuindo com mudanças e adições. Cada pessoa tinha sua própria compreensão do problema, seu próprio estilo de codificação e suas próprias restrições de tempo. O resultado é um pedaço de código legado complexo (é por isso que ser expressivo é uma característica tão determinante de sucesso para o código). Portanto, o código que você vê hoje e que o fez – primalmente – querer acertar alguém com um porrete na cabeça, não tem um único culpado. Para ser realmente justo, você teria que ir encontrar muitas pessoas, algumas delas trabalhando em outros projetos, e gentilmente tocar cada cabeça com seu porrete, sobre o qual você teria colocado uma almofada antes. Dessa forma, você espalharia seu golpe punitivo de forma equitativa.
A Abordagem Eficiente: Assumindo a Responsabilidade
Agora que você vê o código legado com um olhar racional, o que você pode fazer na prática para abandonar a mentalidade primal e se juntar àqueles com a mentalidade eficiente?.
A primeira coisa a fazer é: não reclame se você não pretende melhorar o código. Reclamar sem intenção de agir é improdutivo e cria um ambiente negativo. Se você identifica um problema no código, o foco deve ser em como resolvê-lo, em vez de apenas criticá-lo. E se você tem pessoas que fazem reclamações não construtivas ao seu redor, faça um esforço ativo para não se deixar sugar. Não critique o código apenas por criticar. Seja particularmente cuidadoso com isso se você estiver no início de sua carreira, para que desenvolva hábitos positivos.
O segundo aspecto da mentalidade eficiente é considerar que o código em que você está trabalhando é seu código. Quer você o tenha escrito ou não, por melhor ou pior que você o ache, agora faz parte do seu domínio de responsabilidade. Não é algo separado de você, escrito por alguém que não está mais por perto e que você pode criticar à vontade para mostrar o quão ruim ele é e o quão bom você é. É seu código, e você está aqui para tirar o máximo proveito dele.
Quando me deparei com essa mentalidade (graças ao meu fantástico gerente Patrice Dalesme), fiquei motivado a fazer o que estivesse ao meu alcance para entender meu código, melhorá-lo e criar valor de negócio a partir dele. Vários anos depois, ainda estou tão motivado a fazê-lo. Patrice, além de se preocupar em escrever um bom código, me ensinou como criar valor e ter uma vida profissional gratificante enquanto trabalho com código existente, seja explicitamente ou simplesmente tê-lo como modelo (alguns o chamam de "Rei Patrice" ou até "Patrice Mágico"). Sem ele, eu não teria muito a dizer neste livro. Poucas pessoas têm a chance de trabalhar com um desenvolvedor e gerente como você. Você é demais.
Tendo um Modelo
Ter um modelo ajuda muito a adotar a mentalidade certa. Tente pensar em alguém que você admira por sua atitude em relação ao código legado. Como essa pessoa aborda o código difícil? Como ela fala sobre ele? Que tipo de soluções ela propõe? Observar e aprender com alguém que lida com código legado de forma eficaz pode fornecer insights valiosos e ajudá-lo a moldar sua própria abordagem.
Conclusão do Capítulo 1: Adotando a Atitude Certa
Escolher a mentalidade certa faz toda a diferença, seja na sua eficiência como desenvolvedor ou na sua felicidade como pessoa no dia a dia. É sempre uma boa hora para entrar na mentalidade eficiente, e o momento perfeito para fazer isso é… agora. Assuma a responsabilidade, tome posse.
Principais conclusões:
- Suspeite que escrever o código que você está lendo deve ter sido mais difícil do que parece.
- Perceba que código difícil de ler não é obra de um personagem maligno.
- Evite reclamar se você não pretende melhorar o código.
- Assuma a responsabilidade da parte da base de código em que você está trabalhando.
- Encontre um modelo para se inspirar em sua atitude.
No próximo capítulo, exploraremos como usar o código ruim como uma ferramenta poderosa para aprender a escrever um ótimo código. Fique ligado!
¹ Nota do autor: O blog fluentcpp.com é um recurso valioso para aprender sobre como escrever código mais expressivo e de qualidade.