ti-enxame.com

Como líder de equipe de tecnologia, como devo lidar com os erros de codificação e as más práticas dos membros da equipe?

Sou líder de equipe de tecnologia em uma equipe de cerca de 5 desenvolvedores. O tamanho da equipe é um tanto dinâmico, pois os membros da equipe partem periodicamente para outros projetos e outros se juntam à equipe de outros projetos.

Periodicamente, me deparo com o código dos membros da minha equipe, seja ao fazer modificações nele, ao escrever algo próximo ou apenas ao revisar o código. Às vezes (o suficiente para escrever este post, eu acho) seu código é mal escrito, com pequenos erros (como converter dois objetos Date em strings para compará-los) ou maiores (escrever 2+ quase idênticos de médio a grande funções dimensionadas com apenas uma diferença de linha, em vez de uma função que pode lidar com os dois casos.)

Qual é a melhor maneira de melhorar suas habilidades e apontar esses erros para eles? Às vezes, examino esses segmentos de código com eles, explicando por que devem ser escritos de maneira diferente. Mas não quero ser minucioso e fazer com que eles venham com muita frequência para revisar o código. As revisões de código são a resposta aqui? Em caso afirmativo, como eles devem ser organizados? Devem incluir todos os membros da equipe ou ser individuais? Com que freqüência eles devem ser realizados? Algum outro conselho?

Existe outra pergunta que parece semelhante, mas na verdade é diferente, porque além de estar curioso sobre as revisões de código, eu também gostaria de saber de outras maneiras possíveis de melhorar as habilidades de codificação dos membros da minha equipe . Além disso, os prazos não desempenham um papel na minha pergunta porque podemos facilmente revisar e/ou corrigir o código antes ou depois da entrega de uma próxima versão.

5
Val Schuman

Existem algumas coisas que você pode fazer para resolver essa situação. Primeiro, faça o que puder para ter um livro de regras para consultá-los. Em outras palavras, quando surgirem coisas assim, é melhor dizer: "Dê uma olhada na página 6 do guia de estilo." Ou, "Aqui está um link para um site que explicará algo que desejo que você saiba" e salve esse link para sua biblioteca. Como líder de tecnologia, é parte de seu trabalho evitar dívidas técnicas, portanto, essa é sua obrigação para com eles.

Em segundo lugar, em vez de apontar o que eles fizeram de errado, faça perguntas sobre seus próprios códigos. Por exemplo, meu mentor me pegou copiando matrizes quando eu não precisava, então ele me perguntou: "O que você acha que este código aqui está realmente fazendo?" Tínhamos uma cultura de respeito mútuo que tornava essas perguntas estimulantes, em vez de minuciosas.

Se você governar com base na política, manter seu papel de guardião e tratar as pessoas com respeito, os bons funcionários vão adorar e os ruins vão encontrar outro emprego. Lembre-se de elogiar publicamente, mas criticar em particular. E o feedback é um presente; os bons programadores dirão como você está se você perguntar a eles.

6
Gavin

Aqui está minha opinião sobre revisões de código.

Grande ideia em teoria, mas você deve gerenciar as coisas com cuidado. Os programadores são criativos, egoístas e podem ser extremamente magros. Uma revisão de código de equipe aberta pode facilmente se transformar no Coliseu Romano. Os codificadores podem separar o trabalho uns dos outros de maneira cruel e improdutiva. Mesmo se você fizer isso individualmente, ainda pode se transformar em uma experiência negativa. O conselho de Gavin sobre criticar em particular é um ótimo conselho e algo difícil de manter quando há revisões de código aberto.

A sugestão de Gavin (novamente) sobre escrever um guia de estilo ou documento de padrões de codificação é novamente excelente, mas você precisa ter autoridade para aplicá-la. Eu sugiro fortemente encontrar um bom modelo online e adaptá-lo, caso contrário, haverá sangue entre as facções daqueles que colocam a abertura "{" na mesma linha e aqueles que colocam em sua própria linha etc. Eu vi (seriamente) um ferramenta de formatação de código de linha de comando incorporada ao fluxo de trabalho de check-in para impor o estilo da empresa (bom - suponho), mas também viu programadores renegados na mesma empresa usarem a mesma ferramenta com parâmetros de estilo diferentes para formatar o código "à sua maneira" no check-out (não é tão bom).

Sobre o novo conteúdo, compre uma biblioteca de bons livros sobre programação, por exemplo, "Clean Code", "Clean Coder" e "Code Complete" e tente iniciar uma cultura de aprendizagem e melhoria.

2
mcottle

Não sou líder de equipe, então não usei isso na prática.
Mas, na minha opinião, uma competição saudável é o caminho a percorrer.
Faça com que seus desenvolvedores resolvam um desafio não relacionado ao trabalho. O mesmo desafio para todos os desenvolvedores.
Certifique-se de explicar de antemão o que constitui uma boa solução (funções curtas, nomes significativos, eficiência, etc.).
Quando todos estiverem prontos, vote pela melhor implementação.
O fato de todos estarem trabalhando no mesmo problema permitirá discussões mais profundas, já que todos já pensaram na solução.
O fato de não ser relacionado ao trabalho reduzirá a ansiedade do fracasso e tornará as pessoas mais receptivas às críticas.
Tornar esses conteúdos uma tradição melhorará gradualmente as habilidades de codificação de toda a equipe, sem a necessidade de passar pelo processo de revisão de código.

0
DanielS