Desenvolvimento sustentável: Como escrever código que envelhece bem

A dívida técnica que não se paga com código limpo.

Existe um tipo de dívida técnica que não se paga com um clean code ou uma refatoração rápida. É a dívida que nasce do excesso de zelo, da tentativa de criar o sistema perfeito, cheio de abstrações elegantes, preparado para todos os possíveis erros futuros e cada vez mais distante da realidade do negócio. Esse tipo de cuidado pode até deixar o código bonito, mas também o transforma em uma fortaleza, impenetrável por dentro. E quando o produto precisa mudar de direção, inovar ou simplesmente acompanhar o mercado, o que antes era motivo de orgulho vira justamente o maior obstáculo do negócio.

O código que envelhece bem sustenta o negócio

Bruno Rocha, Principal Software Engineer e Tech Lead na Red Hat, trouxe essa discussão pra o cenário da empresa que ele atua. A Red Hat vive exatamente no ponto de encontro entre estabilidade, longevidade e evolução. Como ele resume, “o cliente não compra o software, ele compra a confiança de que aquilo vai continuar funcionando por muitos anos”. A empresa não vende algo que qualquer pessoa pode baixar gratuitamente, mas um pacto de previsibilidade. E dentro dessa lógica, um código que envelhece bem não é o mais sofisticado, ele pontua que “se o software não entrega o objetivo do negócio, ele é desperdício”.

Essa busca pelo equilíbrio começa ao reconhecer o perigo da complexidade acidental que muitas vezes surge de boas intenções. O perigo desse movimento é criar um sistema que, de tão bem estruturado, se torna rígido. Essa fala do Bruno exemplifica, “você engessa o seu produto mas de tão bom, ele é tão engessado, que ele não permite que o produto evolua”. A verdadeira sofisticação está na simplicidade, e essa simplicidade não é falta de cuidado, pelo contrário, é disciplina e intenção.

Escolhas que duram e escolhas que expiram

A decisão de apoiar o desenvolvimento em tecnologias consolidadas não é conservadorismo; é estratégia. Frameworks com história e comunidades fortes carregam anos de compatibilidade, correções e maturidade que evitam dores de cabeça no futuro. Isso não significa abandonar tudo que é novo, mas entender o preço da escolha e se faz sentido pro negócio. Ferramentas modernas, que estão no hype, são excelentes para aproveitar oportunidades imediatas, mas raramente são construídas para durar. O próprio Bruno reforça: “esse código feito com ferramentas mais modernas não é feito para envelhecer”. Escolher algo bleeding edge é aceitar conscientemente essa troca: velocidade agora, complexidade amanhã.

A regra da janela de oportunidade

Para além das escolhas tecnológicas, a longevidade do software nasce de sistemas capazes de se adaptar. E isso não vem do apego a padrões ou da aplicação de design patterns, mas da capacidade de criar códigos substituíveis. Bruno coloca isso de forma direta: “criar código que seja facilmente substituível. Essa é uma das dicas que eu procuro seguir e ela não exige aquele pensamento científico muito aprofundado”. Sistemas baseados em protocolos, módulos independentes e baixo acoplamento sobrevivem ao tempo porque aceitam mudança sem drama.

Essa lógica aparece também na discussão sobre comentários. A ideia de que “código não deve ter comentários” simplifica demais o contexto. Com a experiência, os desenvolvedores naturalmente perdem referência do que é óbvio para quem está chegando. Por isso, embora o ideal seja sempre um código “limpo”, nem sempre ele segura todo o contexto sozinho. De acordo com Bruno “o melhor código que eu tenho visto é aquele que eu não preciso ir pra outro lugar pra entender ele. O contexto dele tá no próprio código” e nesse caso os comentários são uma ferramenta de comunicação.

O trabalho real é desapegar, modularizar e aprender com a dor

Quando enfim encaramos um código legado, toda teoria encontra a realidade. Refatorar é um processo lento, repetitivo e pouco glamouroso. E ele começa pelo desapego. Desenvolvedores tendem a tratar código como obra pessoal, mas “código não é arte, é ferramenta, se você escreveu uma vez, pode escrever melhor de novo”. Esse desapego abre espaço para outra etapa fundamental que é a modularização. Antes de qualquer tentativa de reorganizar ou otimizar, é preciso quebrar o sistema em partes compreensíveis. Só assim é possível isolar efeitos, testar hipóteses e reconstruir com segurança.

Como atingir a maturidade técnica

A maturidade técnica nasce justamente desse enfrentamento, o bom código não precisa brilhar, precisa funcionar. A experiência de lidar com arquiteturas ruins, com decisões apressadas e com sistemas rígidos forma o olhar crítico que evita o mesmo sofrimento no futuro. Não existem atalhos, pra Bruno, você não aprende a lidar com código legado lendo um livro, aprende mexendo no código.

No fim, a filosofia que governa o desenvolvimento sustentável continua sendo aquela clássica: “make it work, make it right, make it fast” faça funcionar, depois faça certo e só então faça rápido. Código que envelhece bem não nasce da obsessão pela perfeição, mas da responsabilidade com o futuro. Ele precisa sobreviver às equipes, às versões e aos requisitos que ainda nem existem. O tempo sempre cobra e o desafio é escrever algo que envelheça com eficiência.

O episódio completo pode ser ouvido no Escovando Bits (#69), trazendo ainda mais reflexões e experiências reais sobre o tema.