Introdução
Vivemos numa época em que se quer uma resposta rápida para tudo. No mundo empresarial, a velocidade pode ser uma exigência — há que reagir rapidamente às mudanças nas necessidades de negócio. Isso leva à pressão de entregar software o mais rápido possível. O problema é que essa urgência, quando mal gerida, leva à negligência no cuidado com o código (e não falo apenas de arquitetura).
Questões de segurança e ciberhigiene podem surgir, tal como pequenos erros evitáveis que se acumulam ao longo do tempo. É como o aluno do secundário que só quer ler o resumo d' Os Maias (sim, também estudei pelos resumos): ao saltar etapas, perde-se o essencial.
No meu artigo anterior falei do uso do ChatGPT. Um dos problemas atuais é o uso excessivo de inteligência artificial sem espírito crítico. O ChatGPT não faz mal a ninguém — mas não substitui o ser humano. Quem decide, compreende e coloca o código a funcionar é o programador.
No "vibe coding", quem manda és tu — não é o Cursor, nem o GitHub Copilot. Eles sugerem. Tu avalias. E é aqui que entra a importância da leitura de código: só lendo conseguimos perceber se as sugestões fazem sentido.
Neste artigo, falo sobre a impaciência do programador em ler código e partilho algumas sugestões de melhoria.
Ninguém gosta de ler código
Sempre tive paixão por engenharia de software. Se alguém me disser:
"André, lê este código."
A minha resposta será:
"Claro. Qual é o problema que estás a ter?"
Se me disserem que há um erro de referência nula, eu gosto primeiro de perceber o código no seu todo. Se conhecer o domínio da aplicação (Domain-Driven Design ajuda aqui), consigo resolver o problema mais facilmente.
Mas nem todos partilham esse cuidado. Em muitos trabalhos académicos, o objetivo era só “fazer funcionar”. Ouvi muitas vezes:
“Já fiz. Está feito. Não mexe mais.”
E eu, ao analisar mais a fundo, percebia que:
-
O código funcionava, mas não fazia exatamente o que era suposto.
-
Tinha lógica desnecessária (ex: ifs a mais).
-
Podia ser simplificado.
Quando tentava dar esse feedback, muitas vezes não era ouvido — mesmo quando tinha razão. Lembro-me de situações em que tentei antecipar problemas e fui ignorado. Depois, os problemas aconteceram.
Num projeto de análise de dados, avisei:
"A professora disse para colocarmos os controlos da esquerda superior para a direita inferior. E que as cores dos dashboards deviam ser uniformes — é um princípio de usabilidade que aprendemos no 1.º ano."
Responderam-me:
“Mas a professora vai avaliar cada dashboard individualmente.”
Eu tentei argumentar, mas calei-me para evitar conflitos. No fim, a professora criticou exatamente o aspeto que eu tinha alertado. Com uma simples decisão partilhada, podíamos ter tido melhor nota.
Falta de paciência dá nisto. E com o código é igual.
“Não vou perder tempo com isto.”
“Esquece. Não vale a pena complicar.”
Às vezes, sim, não vale a pena complicar. Mas há outras em que “não perder tempo” é exatamente o que faz perder tempo no futuro — e aprendizagem.
O sistema académico valoriza notas, não processos. Mas no mercado de trabalho, o importante é aprender, refletir e evoluir. São contextos diferentes, sim. Mas a verdade é: todo o programador devia saber ler código.
Especialmente código de outros. Pode ser chato — não foste tu que escreveste. Mas é assim que se aprende. E empresas valorizam quem tem:
-
Capacidade de adaptação.
-
Vontade de aprender continuamente.
-
Espírito crítico e atenção ao detalhe.
Ler código não é dor de cabeça. É ganho de tempo e aprendizagens
Imagina: o teu colega diz
“Este código está a fazer isto.”
Lês o código e respondes:
“Na verdade, não. Faz isto, isto e isto. Para fazer o que disseste, terias de mudar aqui e ali.”
Ler código evita suposições erradas. Permite corrigir com precisão. Dá-te confiança para mexer sem estragar. Garante que entendes antes de mexer. E se não entenderes, pelo menos podes escrever testes ou diagramas antes de intervir.
Ler código é essencial quando:
-
Não há testes nem documentação.
-
Estamos a lidar com sistemas legados.
-
É preciso criar um fluxograma de uma funcionalidade complexa.
Não há vergonha nenhuma em desenhar para entender.
Para fazer o fluxograma, é preciso ler o código.
Também é uma questão de cibersegurança. Exemplo clássico:
-
Alguém deixou uma password hardcoded no código.
-
Publicaram-no no GitHub.
Se alguém tivesse lido com atenção, isso podia ter sido evitado. E se houver dúvidas: pergunta-se. É assim que se aprende.
Conclusão
A paciência é uma virtude — e na programação, uma competência técnica.
Ler código não é uma enxaqueca. É uma forma de ganhar tempo e aprender.
Se vais mexer num sistema legado, refatorar funcionalidades ou integrar código com o de outros, ler com paciência é meio caminho andado.
Trabalha essa paciência.
E lembra-te: quem programa não é a IA.
És tu.