Como ler código que você não escreveu: método em 6 passos

Ler código é uma habilidade diferente de escrever.

E quase nenhum curso ensina. Você abre um repositório novo com 400 arquivos, ninguém do time tem tempo pra explicar, e descobre na marra como ler código que você não escreveu.

Só que é isso que você mais faz no dia. Minelli, Mocci e Lanza (ICPC 2015) mediram 200 horas de uso de IDE de 18 desenvolvedores: uns 70% do tempo foi compreensão de programa, contra uns 5% de edição.

Xia et al. (IEEE TSE, 2018) acompanharam 78 profissionais por 3.148 horas, contando navegador e documentação, e chegaram a uns 58%.

E o famoso “10 pra 1” do Clean Code? É estimativa do próprio Robert Martin, não medição. (A internet transformou o chute do Tio Bob em lei.)

Esses estudos mediram devs. Na minha experiência, quando você vira Tech Lead a leitura passa de 90% do trabalho com código. Code review, investigação de incidente, onboarding e decisão de arquitetura são quase tudo leitura.

Por que você se perde no meio do código

A Felienne Hermans separa três tipos de confusão em The Programmer’s Brain (Manning, 2021).

Falta de conhecimento: você não conhece a sintaxe, o framework ou o domínio. Falta de informação: a resposta tá em outro arquivo e você não sabe qual. Falta de capacidade de processamento: tem estado demais pra segurar de cabeça.

Cada uma pede um remédio. Estudar. Navegar. Anotar.

Antes de reler o trecho pela quinta vez, descubra qual te travou.

Como ler código que você não escreveu, em 6 passos

1. Ache o ponto de entrada. A função main, o arquivo de rotas ou o handler da fila. Do README, leia só como rodar o projeto.
2. Leia os testes antes da implementação. Teste é exemplo executável do comportamento esperado.
3. Siga uma única requisição de ponta a ponta. Pegue um caso concreto e ignore o resto.
4. Pergunte pro histórico o porquê. O código mostra o que acontece. git log --follow -p arquivo e git blame -w levam ao commit e ao pull request que explicam a decisão. (O blame serve pra achar o motivo, não o culpado.)
5. Confirme com o debugger. Põe um breakpoint onde você acha que a execução passa. Se ele não parar, seu modelo mental tá errado. O Michael Feathers, em Working Effectively with Legacy Code, sugere ainda a scratch refactoring: refatorar só pra entender e depois jogar fora.
6. Desenhe o mapa. Cinco a oito caixas com setas de chamada. A Hermans recomenda grafos de dependência e tabelas de estado, que é memória de trabalho fora da cabeça.

Bora num caso real: o Flask

O Flask é um framework web popular em Python. Caminhos conferidos no main em outubro de 2026.

1. Entrada: em src/flask/app.py, o servidor WSGI chama a instância da classe Flask. O __call__ só delega pro wsgi_app.
2. Teste: em tests/test_basic.py, o test_before_after_request_order espera called == [1, 2, 3, 4, 5, 6]. Em 30 linhas você aprende que os hooks after_request e teardown_request rodam na ordem inversa do registro.
3. Requisição: wsgi_app chama full_dispatch_request, que roda preprocess_request (os before_request), depois dispatch_request (busca a view em view_functions[rule.endpoint]) e fecha com finalize_request.
4. Histórico: por que existe src/flask/sansio/app.py do lado do app.py? O histórico leva ao PR #5127 (2023), que separou a parte sem I/O pra que projetos assíncronos como o Quart pudessem reaproveitar o Flask.
5. Debugger: breakpoint em dispatch_request e roda pytest tests/test_basic.py -k before_after_request_order. A call stack confirma o passo 3.

O passo 6, o mapa, fica com você.

Tech Lead lê muito mais do que escreve

Xia et al. viram outra coisa: seniores gastam uma fração bem menor do tempo em compreensão do que juniores. Ler bem é parte do que faz alguém sênior, e a conta só cresce na liderança técnica.

O Tech Lead lê PR em code review. Lê o sistema inteiro antes de uma decisão de arquitetura. E ensina os outros a ler durante o onboarding.

Entregar os 6 passos pra quem chega rende mais do que uma semana de apresentações.

Entender antes de reescrever vale fora do código também. Na B2Blue, minha primeira vez como CTO (2012 a 2013), o marketplace tinha sido feito por uma agência. Era lento e usava um framework proprietário difícil até de arrumar.

Antes de criar time ou sistema novo, instalei um live chat no site e fui eu mesmo abordar os clientes. No primeiro dia veio o primeiro cliente, sem eu escrever uma linha de código.

Abre o próximo repositório pelo passo 1

O Joel Spolsky chamou de lei fundamental da programação o fato de que ler código é mais difícil do que escrever. Com método, a distância diminui. Na próxima base nova, não abre arquivo ao acaso: começa pelo passo 1.

Ler bem é o começo. Conduzir as decisões sobre o código é outra habilidade, e é isso que eu ensino no First Lead, meu curso de liderança técnica, com os três pilares: técnico, negócios e pessoas. A partir de R$ 97.

E você, qual foi a base de código mais difícil que já teve que ler? Conta nos comentários o que te salvou.