|
|
O júnior parou de escrever e começou a revisar
O CRUD que enchia o primeiro ano de carreira sai pronto no primeiro prompt, e a vaga agora pede leitura de código alheio antes da primeira linha.
|
O código que alguém precisa ler
|
| ▼ |
| |
|
O primeiro ano de um programador júnior sempre teve formato conhecido. Cadastro de cliente, tela de listagem, formulário de edição, botão de excluir com confirmação, validação de campo obrigatório, mensagem de erro em vermelho. O mesmo cadastro, com outro nome de tabela, em cinco projetos seguidos. Ninguém chamava aquilo de aprendizado nobre, mas era ali que a pessoa aprendia a mexer no repositório sem quebrar o que já estava no ar. Quem entrava pago por tarefa concluída aprendia na fila que a ferramenta hoje esvazia sozinha.
O gerador de código encostou exatamente nessa camada. O cadastro completo, com rota, modelo, tela e teste básico, sai no primeiro pedido bem escrito, em menos tempo do que leva a reunião que descreveu a tarefa. Nenhuma empresa cortou o júnior por maldade de planilha: olhou para a fila que justificava a contratação e viu a fila esvaziar sozinha.
O que não ficou barato foi o passo seguinte. O código gerado chega pronto e plausível, com nome de variável razoável e comentário educado. Ele funciona no caminho feliz e falha no campo vazio, na data com fuso, no valor negativo, na permissão de quem não deveria ver aquela tela. Cada arquivo que entra no repositório vira um arquivo que alguém precisa ler antes de assumir.
Existe uma diferença prática entre produzir um trecho de código e responder por ele depois de mesclado. Produzir é resolver a tarefa uma vez, com o teste passando na máquina de quem escreveu. Responder é dizer que aquele trecho não quebra a fatura do mês que vem, não expõe dado de outro cliente e não vira plantão de madrugada.
A primeira parte a automação alcançou primeiro, porque sempre foi montagem de estrutura repetida. A segunda exige alguém que leia código que não escreveu, encontre o erro e explique por escrito o que precisa mudar.
A travessia de hoje é de um júnior que perdeu o estágio na semana em que o time adotou o gerador, passou dois meses lendo código alheio de graça e descobriu que a falha tinha padrão, contagem e custo em horas de plantão.
Continue lendo ↓
|
|
|
|
I A história de quem atravessou
De estágio cortado a 40 revisões por mês
|
|
Onze meses de cadastro repetido, um estágio encerrado por falta de fila, e um repositório onde 4 de cada 10 trechos gerados traziam o mesmo tipo de falha.
Rafael tem 24 anos e mora em Belo Horizonte. Onze meses de estágio numa empresa de logística: cadastro, listagem, filtro, relatório em planilha, tela ajustada para o celular. O nome vai trocado aqui, e a empresa que encerrou o contrato é a mesma que voltou com outra proposta.
O corte chegou pela fila de tarefas, sem reunião e sem discurso. O time sênior passou a gerar o cadastro inteiro no editor, mesclava no mesmo dia e seguia. A fila que sustentava a vaga secou em seis semanas.
Com o pagamento preso à tarefa concluída, a matemática ficou direta:
Antes, bolsa de estágio de 30 horas semanais, mais auxílio: R$ 2.400 por mês
Depois do gerador, contrato encerrado, dois meses sem renda de programação: R$ 0 por mês
Mesma pessoa, mesmo repositório, mesma cadeira vazia.
A virada aconteceu por teimosia. Com o acesso de leitura que sobrou num projeto aberto da empresa, Rafael passou a ler todo dia os trechos gerados que entravam. Não corrigia nada, anotava cada problema numa planilha, com data, arquivo e categoria.
O resultado apareceu em quatro colunas depois de dois meses. Em 210 trechos gerados que entraram no repositório, havia 84 problemas registrados: 31 de tratamento de erro ausente, quando a chamada externa falhava e o sistema seguia como se tivesse dado certo, 22 de consulta ao banco dentro de laço, 18 de permissão não verificada em rota nova, e 13 de teste que só cobria o caminho feliz.
O padrão se repetia em todos os projetos. A ferramenta acertava a estrutura e errava onde o sistema tem consequência: o frete que não responde, o pedido de um cliente visível para outro, a tela que consulta o banco quatrocentas vezes por carregamento.
Rafael começou a manter uma lista de verificação por projeto, sem plano nenhum, só por incômodo. Onde o dado entra sem validação, que rotas mexem em dinheiro, que consultas rodam dentro de laço, que erro precisa parar o processo.
|
Ali o trabalho deixou de ser produção de código e passou a ser duas entregas separadas que o mercado sempre pagou embrulhadas. Uma era o tempo de alguém digitando uma solução. A outra era a responsabilidade por afirmar que aquele trecho pode entrar no sistema que fatura.
|
Com a lista na mão, a revisão de cada trecho caiu de cinquenta minutos para dezoito, e as correções emergenciais do mês seguinte caíram de 9 para 2. Quando o líder técnico perguntou por que aquele projeto parou de gerar plantão de madrugada, Rafael mandou a planilha com data ao lado.
A proposta nova saiu quatro semanas depois, com a unidade trocada de tarefa concluída para revisão registrada:
Revisão de código gerado por sprint, leitura de cada trecho contra a lista, com laudo do que foi barrado: R$ 3.200
Lista de verificação por projeto, mapa de rotas sensíveis, validação, permissão e consulta ao banco: R$ 2.600
Plantão de análise de incidente, leitura do trecho que quebrou e registro da causa: R$ 1.400 por mês
A empresa aprovou o formato para três times e passou a exigir revisão registrada antes de qualquer mescla em produção. Cinco meses depois, escrevendo menos código do próprio punho, Rafael fechou um mês acima de R$ 7 mil.
|
|
|
|
|
II Radar de Automação
Escrever ficou barato, aprovar continua caro
|
|
A automação não apagou a vaga de entrada em programação. Ela apagou a parte que só precisava de repetição de estrutura e paciência, deixou exposta a parte que depende de julgar código que outra pessoa escreveu, e transformou em produto uma prática que o mercado sempre tratou como favor entre colegas: a revisão de código.
|
O radar de hoje está na taxa de problema por trecho gerado e nas categorias em que a ferramenta escapa sempre. Empresa que só mede tarefa concluída comemora a fila rápida e acumula no repositório decisões que ninguém leu.
A exigência de revisão não nasceu com gerador de código. A prática de ler o código de outro antes de aceitar existe desde a inspeção formal descrita por Michael Fagan na IBM nos anos 1970, criada porque erro encontrado na leitura custava uma fração do erro encontrado em produção, e já operava com a regra que a ferramenta ignora: aprovação é decisão registrada, não sensação de que o texto parece certo.
O que mudou foi o volume a ser lido. Antes, o código que entrava por semana era limitado pela velocidade de digitação do time. Agora é limitado pela velocidade de leitura de quem revisa, e a segunda não acompanha a primeira.
A conta de um projeto de logística explica a proposta nova:
Trechos gerados que entraram no repositório em dois meses, 210 no total
Problemas registrados na leitura, 84, sendo 31 de tratamento de erro ausente
Correções emergenciais no mês seguinte à lista de verificação, de 9 para 2
O ponto que o mercado ainda digere é a assimetria de risco. Escrever o cadastro virou tarefa de minutos, e a afirmação de que aquele trecho pode entrar no sistema que fatura continua sendo uma responsabilidade pessoal, cobrada de uma pessoa quando o pedido de um cliente aparece na tela de outro.
|
"Ler código é mais difícil do que escrevê-lo."
Joel Spolsky, Things You Should Never Do, 2000
|
Spolsky escrevia sobre reescrever sistema do zero, anos antes do gerador de código. A frase descreve a vaga de entrada de hoje: a tarefa cara foi transferida para o lado difícil da conta. Quem define o que pode ser mesclado toma uma decisão de risco do negócio, não digita solução.
Quem continua sendo pago por tarefa concluída é pago por uma etapa que qualquer editor moderno entrega antes do fim da reunião, e herda o preço dela. Quem é pago por revisão registrada e lista de verificação mantida é pago por afirmar que o sistema continua de pé, e por responder pela afirmação.
|
|
|
|
|
III O movimento de hoje
Uma lista de verificação em três linhas de contrato
|
|
O movimento de hoje cabe em duas semanas de leitura e não depende de vaga aberta. Ele separa em linhas distintas o que sempre foi pago embrulhado num salário por tarefa concluída, e a separação cai onde a automação entrou.
1. Escolha um repositório a que você já tem acesso e leia os trechos que entraram no último mês, sem corrigir nada. Cada problema entra com quatro campos: o que o código faz, o que o sistema esperava, a categoria da falha e a consequência se ninguém tivesse lido. Duzentos trechos bastam para o padrão aparecer.
2. Transforme a planilha em lista de verificação por projeto, com data e dono. Rotas que mexem em dinheiro, entrada de dado sem validação, consulta ao banco dentro de laço, permissão por perfil, erro que precisa parar o processo. Anote os problemas por trecho antes e depois. A curva com data separa quem digita rápido de quem sustenta o sistema.
3. Escreva o que a sua revisão cobre e o que fica de fora. Duas frases bastam: assumo a leitura de cada trecho que entra no projeto contratado, contra a lista de verificação, com laudo do que foi barrado e por quê; não respondo por código mesclado sem passar pela revisão, por alteração feita depois da minha aprovação nem por regra de negócio que ninguém me deixou registrar antes. O limite escrito separa favor de função com preço.
A recusa aparece rápido e com o mesmo argumento: a ferramenta já escreve e sai por centavos. Quem não aceita pagar pela leitura costuma ser o mesmo que liga no sábado porque a tela de pedidos travou depois de uma mescla que ninguém conferiu.
Os contratantes que aceitam têm perfil reconhecível. Time pequeno com sistema que fatura, operação que já sofreu incidente de dado exposto, empresa que adotou o gerador antes de decidir quem lê a saída. Todos tratam a mescla em produção como decisão com dono.
A travessia aqui não é de profissão. Rafael segue na programação, com o mesmo teclado e o mesmo repositório. O que ele trocou foi o item que aparece no contrato: saiu a tarefa concluída, entrou a revisão registrada e a lista que sustenta a próxima mescla.
Recalcular a rota, aqui, começa por uma pergunta que cabe no fim de qualquer entrevista. O cadastro que você escreveu hoje a máquina refaz em segundos; a lista de verificação que você manteve continua valendo no incidente do trimestre que vem.
"Quanto do meu salário paga o código digitado, e quanto paga a leitura de quem entra?"
|
|
|
|
| |
|
