Nos dois capítulos anteriores da nossa série falamos sobre os primeiros passos na profissão de programador e sobre o que realmente vale a pena aprender no início da carreira.
Agora chegamos ao momento que quase todo Junior teme.
Primeiro Code Review. Primeiro comentários ao código. Primeiras correções.
E o primeiro pensamento: "Será que eu realmente escrevi esse código tão mal?"
Calma.
Todos nós já passamos por isso alguma vez.
Code Review não é um exame
Acho que este é o maior equívoco entre os desenvolvedores iniciantes.
Muitos Juniors levam os comentários sobre seu código muito para o lado pessoal. Surge ansiedade. Insegurança. Às vezes até frustração.
Mas o objetivo do Code Review não é provar para alguém que cometeu um erro. Pelo contrário. É um dos elementos mais importantes do processo de criar um bom software.
Graças ao Code Review:
- reduzimos o risco de erros,
- melhoramos a legibilidade do código,
- aprendemos uns com os outros,
- zelamos pela consistência de todo o projeto,
- transferimos conhecimento entre os membros da equipe.
As melhores equipes não tratam o Code Review como fiscalização. Tratam-no como uma troca diária de experiências.
"Você tem 37 comentários"
Parece assustador? No começo sim.
O primeiro Pull Request costuma parecer exatamente assim:
- Comentário.
- Correção.
- Mais um comentário.
- Outra correção.
Depois de uma hora você tem a sensação de que todo o código deveria ser jogado fora. Isso é normal.
Lembre-se só de uma coisa. O sênior não corrige o código porque quer mostrar sua superioridade. Faz isso porque, em alguns meses, você escreverá um código bem melhor.
E é exatamente disso que se trata.
Um bom Sênior não diz apenas "ruim"
Os melhores desenvolvedores com quem trabalhamos sempre explicavam:
- por que vale a pena fazer algo de forma diferente,
- quais serão as consequências da solução atual,
- quais alternativas existem,
- qual solução será mais fácil de manter daqui a um ou dois anos.
Isso é uma grande diferença.
Porque você pode dizer: "Isto está errado."
Ou pode dizer: "Isto funciona, mas se daqui a seis meses formos desenvolver este módulo, será muito mais fácil mantê‑lo nessa estrutura."
No segundo caso você aprende algo muito mais valioso do que a própria correção. Você aprende uma forma de pensar.
Clean Code não significa código bonito
Outro conceito que frequentemente é mal interpretado.
Clean Code não significa código que pareça impressionante. Não é sobre o número de linhas em branco. Não é sobre o comprimento de uma função. Nem sequer sobre padrões específicos.
Trata-se de algo muito mais simples - o código deve ser legível.
Se daqui a seis meses você abrir seu próprio projeto e não lembrar o que tinha em mente...
...provavelmente o código não era suficientemente legível.
Há um ditado: Escrevemos código para pessoas. O compilador só checa a sintaxe.
E nisso há muita verdade.
Não se apaixone pelo seu próprio código
Esta é uma das lições mais importantes.
Código não é obra de arte. Não é um quadro. Não é uma escultura.
É uma ferramenta para resolver um problema concreto.
Se alguém propõe uma solução melhor...
...vale a pena considerá‑la.
Não porque alguém tenha mais autoridade. Porque talvez de fato seja melhor.
Os que mais aprendem são os programadores que conseguem dizer: "Você está certo. Vamos fazer diferente."
"Em mim funciona"
Ok. Finalmente chegamos a essa famosa frase. Todo software house tem sua versão dessa piada...
Imagine a situação.
O tester reporta um bug.
O programador responde: "Em mim funciona."
O tester verifica novamente. - Não funciona.
O Project Manager verifica. - Não funciona.
O cliente também verifica. - Não funciona.
Mas... no ambiente do autor do código continua funcionando.
Soa familiar?
Na maioria das vezes o problema não está no próprio código.
As causas podem ser muitas:
- versão diferente dos dados,
- ambiente diferente,
- cache,
- configuração,
- permissões,
- navegador,
- sistema operacional,
- um caso que ninguém previu antes.
Por isso um programador profissional não encerra a análise com a frase: "Em mim funciona."
Faz a pergunta seguinte.
Por que funciona comigo e em outro lugar não?
E é aí que começa a verdadeira depuração.
"É só uma pequena mudança"
Outra frase que provoca um leve sorriso na maioria dos software houses.
O cliente diz: "É só um pequeno ajuste."
O programador já sabe que em breve abrirá um arquivo que ninguém tocou há seis anos.
E esse "pequeno ajuste" acabará sendo uma alteração em cinco módulos, três integrações e duas bases de dados.
Por isso desenvolvedores experientes encaram a palavra "só" com muita cautela.
As frases mais conhecidas da área
Toda profissão tem seus ditados. Os programadores também.
Alguns deles quase todo mundo conhece:
- "Em mim funciona."
- "São só cinco minutos."
- "Isso não é bug. É feature."
- "Mas eu não mudei nada."
- "No ambiente de produção deu ruim."
- "Só mais um deploy."
- "Com certeza é cache."
- "Correção rápida antes do fim de semana."
- "Isso deve funcionar."
E talvez a mais perigosa: "Vamos jogar isso em produção na sexta às 16:00."
Se você trabalha em TI...
...provavelmente acabou de sorrir.
O programador não trabalha sozinho
Este é um tópico frequentemente esquecido. Na prática a maioria dos projetos é trabalho em equipe.
O programador colabora com:
- UX Designers,
- UI Designers,
- Project Managers,
- Testers,
- DevOps,
- Administradores,
- Analistas,
- Clientes.
Por isso tão importantes quanto o conhecimento técnico são:
- comunicação,
- capacidade de ouvir,
- transferência de conhecimento,
- responsabilidade,
- respeito mútuo.
O melhor código não salvará um projeto se a equipe não souber colaborar.
Glossário de termos
Code Review
Processo de revisão de código por outros desenvolvedores antes de sua implantação. Tem como objetivo melhorar a qualidade do código, detectar erros e compartilhar conhecimento.
Pull Request (PR)
Proposta de introdução de mudanças no projeto. É justamente nesta etapa que geralmente ocorre o Code Review.
Clean Code
Abordagem para escrever código cujo objetivo principal é legibilidade, simplicidade e facilidade de manutenção, e não a quantidade de padrões de projeto utilizados.
Debugging (Depuração)
Processo de encontrar e eliminar as causas de erros em uma aplicação.
Cache
Mecanismo que armazena dados temporariamente para acelerar a aplicação. Também é frequentemente fonte de muitos problemas misteriosos durante os testes.
Resumo
Quanto mais tempo trabalhamos como programadores, mais chegamos a uma conclusão: os melhores developers não são aqueles que cometem menos erros.
Os melhores developers sabem:
- encontrar a causa de um problema mais rapidamente,
- tirar lições,
- aprender com os outros,
- receber crítica construtiva,
- desenvolver continuamente suas habilidades.
Portanto, o Code Review não é um obstáculo. É uma das lições mais valiosas que se pode receber no começo da carreira.
No último capítulo da nossa série vamos conversar sobre o caminho do Junior ao Sênior. Explicaremos por que um Senior Developer não é apenas alguém com dez anos de experiência, mas alguém que sabe assumir responsabilidade pelo projeto, pensar de forma orientada ao negócio e ajudar outros membros da equipe a se desenvolverem.
