Por onde eu passei, apesar de ter outros programadores ao lado e ter a possibilidade de tirar uma ou outra dúvida, no final o projeto era feito de forma individual. Raramente havia algum aprendizado dividido.
Aqui na Live é diferente: todo desenvolvimento passa por uma revisão de código, feita por 2 ou mais membros da equipe antes de ser publicado.
Nesse artigo vou dividir com vocês um pouco do que já aprendi nesse tempo trabalhando em equipe e o quão enriquecedor é aplicar na sua equipe técnicas de Code Review.
>>Leitura Recomendada:
Como ser um bom programador: 7 comportamentos para evitar
Desapego ao código
Até outro dia eu pensava numa solução, escrevia ela e testava. Funcionou? Avançava para o próximo passo. Mas hoje não é assim.
Quando acabo de escrever uma solução, submeto o meu código para uma avaliação.
Invariavelmente algum comentário, sugestão de mudança ou mesmo um questionamento se aquela solução é a ideal vai ser enviado por alguém da equipe. Muitas vezes até com um exemplo de código que poderia substituir um trecho do que escrevi.
Confesso que, da primeira vez, doeu no ego. “Como assim, criticaram meu código?”, foi a primeira coisa que pensei.
E isso pesa mais quando a maioria da equipe sequer estava na educação infantil quando eu já trabalhava como programador.
Comecei a entender que o “meu código” não é meu, faz parte de um projeto inteiro que está sendo construído por muitas mãos.
E, no final, a contribuição de todos vai garantir o resultado. Se eu me apego demais àquilo que escrevi, paro de olhar para o todo e deixo de tirar proveito do segundo ponto que vou explorar:
Contribuição de todos
Todos aqui na Live tem a responsabilidade de manter o projeto funcionando e em constante evolução.
Ao revisar meu código, os demais têm a possibilidade de contribuir com aquele trecho de código ou com aquela nova solução que está sendo desenvolvida.
Isso é enriquecedor, porque são bagagens e visões diferentes pensando em como dar a melhor solução.
Por diversas vezes recebi sugestões de alteração que, vencido o apego ao meu código, vinha a mente: “Por que não pensei nessa solução? Faz todo sentido!”.
E a contribuição vem de todos, uma vez que o código é submetido à revisão de todos, independente do seu nível de conhecimento — do estagiário ao mais experiente da equipe.
>>Leitura Sugerida:
Leia nosso artigo sobre a importância da comunicação em TI
Aprendizado mútuo
Para revisar um código é preciso ler e entender o que aquele algoritmo está fazendo e nessa hora estamos estudando, mesmo que indiretamente, formas e soluções de problemas diferentes das que normalmente faríamos.
Alguns insights serão tirados daquele código, que poderão ser usados em outras tarefas.
Mas, como somos programadores diferentes, muitas vezes não há consenso entre o revisor e o responsável pela tarefa.
Nessa hora temos a oportunidade de validar nosso raciocínio numa discussão mais aberta e às vezes envolvendo outros programadores.
Já aconteceu de eu chamar um terceiro programador para ajudar na escolha de qual o melhor caminho a seguir e, naquele momento, mais conhecimento foi compartilhado.
>>Leitura Sugerida:
Dicas de Carreira para Programadores .NET
Disseminando conhecimento na plataforma
Quando falei de aprendizado mútuo, foquei mais no desenvolvimento de conhecimento técnico e da linguagem. Nesse ponto quero falar especificamente sobre o conhecimento da solução em si.
Era muito comum, nas empresas que passei, que o conhecimento de um determinado módulo da aplicação ficasse restrito a um ou dois programadores.
E, toda vez que chegava uma nova demanda que interagisse com esse módulo, a tarefa ficaria a cargo desse programador, por já ter o conhecimento prévio do módulo. Principalmente quando não havia tempo para o aprendizado do modus operandi daquele código.
Trabalhando realmente em equipe isso não acontece (ou não deveria acontecer), uma vez que cada revisor do código precisou ler e entender o algoritmo para aprová-lo ou não.
E, com isso, eu já tenho no mínimo dois ou três outros membros da equipe que entendem como funciona aquele módulo.
>>Leitura Sugerida:
Leia nosso artigo com dicas para planejar a carreira em programação
Validação múltipla antes da integração
Todo código que a equipe publica aqui passou pela revisão de dois ou mais programadores, e isso garante ainda mais a qualidade do que está sendo entregue.
Ainda não é à prova de falhas, porque erros podem passar despercebidos, mas diminui e muito a necessidade de fazer rollback numa atualização de versão da aplicação.
5 dicas de como se portar
E, para encerrar, eu gostaria de deixar 5 dicas para você que está começando a programar em equipe, ou que gostaria de aplicar essa metodologia na sua área:
- Seja humilde: todos nós podemos aprender todos os dias;
- Pense coletivamente: o projeto é da equipe, não seu. Esteja aberto às contribuições dos demais;
- Não leve para o pessoal: estão revisando seu código, e não você!
- Seja cordial nas suas revisões: o foco sempre é garantir qualidade e estabilidade e não provar que você sabe mais que os outros
- Segure sua sede por “vingança”: não é porque o seu colega de equipe rejeitou um código seu que você deve se esforçar para rejeitar um dele e empatar o jogo.
Em resumo, trabalhar em equipe tem sido importante aqui na Live, não só para garantir qualidade e estabilidade de código mas também para ajudar no crescimento de cada um da equipe.
E você? Quais foram as suas experiências trabalhando em equipe?
