Meu primeiro código profissional real — e o que ele me ensinou sobre o que eu não sabia
Quando entrei na software house, achei que sabia programar. Sabia. Mas sabia de um jeito que não escalava, não era legível, e não sobrevivia a outro desenvolvedor mexendo nele. Aprendi isso da forma difícil.
Eu achava que sabia programar. E sabia — só que de um jeito muito específico que não se traduzia bem para outros contextos.
Na telco, o código que eu escrevia era principalmente para mim ou para um sistema legado onde os padrões já estavam estabelecidos há anos. Code review existia no papel. Na prática, eu entregava, subia, e se funcionava, estava aprovado.
Na software house, o primeiro Pull Request que abri voltou com comentários. Muitos comentários.
Não eram bugs. O código funcionava. Os comentários eram sobre como eu tinha escrito, não sobre o que tinha escrito.
Variáveis sem nome descritivo. Eu tinha escrito tmp, data, result — nomes que fazem sentido enquanto você está escrevendo mas que não dizem nada para quem lê depois. O comentário dizia: "nome de variável deve ser autoexplicativo, quem vai ler isso daqui a três meses?"
Funções longas. Eu tinha uma função de 80 linhas que fazia três coisas diferentes. O comentário era uma pergunta: "o que essa função faz?" — e a resposta honesta era "várias coisas". Função que faz várias coisas é uma função que precisa ser dividida.
Ausência de tratamento de erro. Eu fazia chamadas que podiam falhar e simplesmente não tratava o caso de falha. "E se isso retornar null?" não era uma pergunta que eu estava fazendo.
A reação inicial a comentários de code review é quase sempre defensiva. "Mas funciona." "Mas é claro o suficiente." "Mas estou com pressa."
Tive que suprimir essa reação e tratar os comentários como informação. Alguém mais experiente estava me dizendo como fazer melhor — não como fazer diferente por preferência pessoal, mas como fazer de um jeito que ia durar mais, escalar melhor, ser entendido por outras pessoas.
Isso foi importante: entender que code review não é crítica pessoal. É o mecanismo pelo qual conhecimento coletivo é transferido para quem está chegando.
Tinha uma coisa específica que eu não entendia antes e entendi ali: código é comunicação.
Você não escreve código para o computador. O computador executa assembly — o que você escreve é compilado ou interpretado de um jeito que o computador não se importa se você escolheu um nome descritivo ou x. Você escreve código para humanos. Para o colega que vai dar manutenção. Para você mesmo daqui a seis meses quando tiver esquecido o contexto. Para o desenvolvedor novo que vai entrar e tentar entender o sistema.
Código que funciona mas que ninguém entende é código que vai ser reescrito — porque quando algo precisar mudar, será mais rápido reescrever do que entender.
Legibilidade não é luxo. É manutenabilidade.
Aquele período na software house comprimiu muito aprendizado. Em empresa grande, você pode ficar meses sem receber feedback real sobre como você está escrevendo código. Em ambiente menor, com code review de verdade, o feedback é semanal.
Velocidade de aprendizado nessa dimensão foi muito maior do que qualquer curso que eu poderia ter feito. Porque o feedback era aplicado ao código real que eu estava escrevendo, para problema real, revisado por alguém que ia ter que trabalhar com esse código depois.
Sobre o que eu descobri que não sabia:
Não sabia escrever código para outros humanos. Sabia escrever código que funcionava para mim. São coisas diferentes, e a segunda é mais difícil.
Não sabia pensar em casos de erro. Estava acostumado a pensar no caminho feliz — quando funciona, como funciona. O caminho infeliz — quando falha, como falha, o que o sistema faz — era território que eu não habitava.
Não sabia fazer perguntas pequenas enquanto escrevia. "Essa função está fazendo uma coisa só? Esse nome descreve o que isso faz? Isso vai fazer sentido para alguém que não sou eu?"
Essas perguntas são hábito. E hábitos se constroem com repetição e feedback. Eu precisava de um ambiente que me forçasse a praticá-las.
Essa semana: pegue um trecho de código que você escreveu há mais de três meses. Leia como se fosse de outra pessoa. Consegue entender em menos de dois minutos o que ele faz e por quê? Se não, o que você mudaria no nome ou na estrutura?