Como lidar com diferentes estilos de programação em uma equipe?

Temos uma pequena equipe de desenvolvimento (apenas 3 desenvolvedores) e recentemente adquirimos um novo membro da equipe. Enquanto ele é um codificador inteligente, seu estilo de codificação é completamente diferente do nosso. Nossa base de códigos existente contém principalmente códigos legíveis, limpos e de manutenção, mas o novo membro da equipe está alterando rapidamente muitos arquivos, introduzindo hacks e atalhos feios, usando definições em todo o lugar, adicionando funções nos lugares errados, etc.

Minha pergunta é se outras pessoas já passaram por essa situação antes e se alguém tem dicas sobre como conversar com ele.

Eu trabalho com uma equipe que cresceu de 2 desenvolvedores para 10 em menos de um ano. Eu era o número 3 e o primeiro a levantar uma questão de padrões de codificação. Os dois desenvolvedores originais estavam trabalhando lado a lado há alguns anos e haviam adotado um padrão comum que me parecia estranho. Tivemos exatamente os mesmos problemas que você está descrevendo.

O que fizemos foi:

Padrões de codificação de pesquisa

Passamos alguns dias verificando projetos de código aberto estabelecidos. Sabíamos que a equipe se expandiria rapidamente e estávamos procurando soluções reais baseadas em projetos reais e não em algumas diretrizes genéricas. Também não nos importamos com os padrões de codificação ideais, mas com um conjunto de regras e diretrizes que fariam sentido e não exigiriam a refatoração de toda a nossa base de código. Estávamos procurando um hack de padrões de codificação, se você quiser.

Nós três decidimos que os melhores padrões de codificação disponíveis para um projeto PHP estabelecido eram os seguidos pelo Zend Framework. Felizmente, o pessoal do Zend Framework fornece um documento de padrões de codificação muito abrangente .

Criando nossos próprios padrões de codificação

Obviamente, aplicar os padrões de codificação de outro projeto em nosso projeto como não fazia sentido. Usamos o documento do Zend Framework como modelo:

• Primeiro, removemos tudo o que não se aplicava ao nosso projeto
• Então mudamos tudo que percebemos como uma questão de estilo para o nosso estilo
• E finalmente escrevemos tudo

Portanto, tínhamos um documento bastante grande em nossas mãos, armazenado em nosso wiki chique , foi uma boa leitura, acordada por todos nós. E completamente inútil por si só.

Permanecendo fiel à nossa promessa

Nossa base de código na época era de cerca de 1 * 10 ^ 6 sloc. Sabíamos que, desde que adotamos padrões formais de codificação, tivemos que começar a refatorar nosso código, mas na época estávamos pressionados por outros problemas. Por isso, decidimos refatorar nossas bibliotecas básicas, um mero sloc 5 * 10 ^ 3.

Designamos um de nós para ser o mestre dos padrões de codificação (usamos palavrões locais no lugar do mestre ) com a responsabilidade de verificar e fazer cumprir os padrões. Reciclamos o papel a cada poucos sprints. Eu fui o primeiro e deu muito trabalho, pois tive que monitorar quase todos os commit.

Tivemos várias novas discussões e pequenos adendos ao documento original durante meu mandato e, finalmente, tivemos um documento um tanto estável. Nós mudamos de vez em quando, mas a maioria dessas mudanças está nos novos recursos da linguagem, já que o PHP 5.3 foi uma versão importante em todos os aspectos, exceto no nome.

Lidando com o novo cara

Quando o novo cara chegou, chegou a hora de testar nossos padrões de codificação. Após uma pequena introdução à nossa base de código, pedimos que ele avaliasse nosso documento sobre padrões de codificação. Ele quase chorou. Parecia que ele fazia tudo de maneira diferente.

Como eu era o mestre dos padrões de codificação na época, cabia a mim avaliar sua opinião e revisar o documento de acordo. Suas propostas foram:

• Questões de estilo pessoal (rejeitadas sumariamente)
• Padrões que faziam sentido para o seu background Java, mas não tanto com o PHP (demitido)
• Convenções que ele carregou de sua breve exposição ao PHP (algumas foram descartadas, mas muitas se mostraram convenções populares que nunca pensamos ou descobrimos em nossa pesquisa inicial)

Nas duas semanas seguintes, ele recebeu uma tarefa simples: atualizar várias partes de nossa base de código com os padrões. Eu tive que escolher cuidadosamente essas partes com base em algumas regras:

• O código deve ser relativamente fácil para alguém não familiarizado com nossa base de código (e PHP em geral)
• O código deve estar no que ele foi contratado para fazer

Eu monitorei seu processo e ele fez um bom trabalho. Identificamos várias partes do código que eram impossíveis de caber em nosso documento e revisadas de acordo (código e / ou padrões, o que fizesse mais sentido)

E então outro cara novo chegou. Repetimos o processo (mestre diferente desta vez) e funcionou novamente. E de novo.

Em conclusão

1. Crie um documento de padrões de codificação, mas certifique-se de que seus padrões não sejam exclusivamente seus, mas que reflitam padrões comuns na comunidade mais ampla de sua plataforma.
2. Atribua uma função semelhante ao nosso mestre de padrões de codificação. Alguém para monitorar pelo menos um novo código, e especialmente um novo código de novos membros. Recicle o papel, pois é extremamente chato.
3. Sempre avalie a entrada de um novo membro. Sempre revise seus padrões, se isso fizer sentido. Seu documento de normas de codificação deve estar evoluindo, mas lentamente. Você não deseja refatorar sua base de código a cada iteração.
4. Reserve algum tempo para que cada novo membro aprenda e se adapte aos seus padrões e convenções. Aprenda fazendo o melhor trabalho nessas situações.
5. O Wiki faz maravilhas para esses documentos.
6. As revisões de código fazem maravilhas para qualquer situação!

Em algum momento do processo, foi sugerido o uso de um gancho de pré-confirmação para automatizar a verificação dos padrões. Decidimos contra isso por vários motivos; existem algumas discussões interessantes sobre o StackOverflow sobre o assunto:

• Formatação automática de código SVN no check-in?
• Controle de versão e formatação de codificação
• PHP codesniffer (phpcs) - como permitir a substituição quando usado como parte de um gancho de pré-confirmação do svn?
• Gancho de pré-confirmação SVN a ser acionado para uma pasta específica
• Implementando padrões de codificação PHP

Alguns são específicos do PHP, mas as respostas se aplicam a todas as plataformas.

Sim, eu já experimentei isso antes. Ao trabalhar em equipe, os membros da equipe devem concordar com certas regras e convenções, e isso inclui o estilo.

Você deve fazer com que sua equipe se reúna e elabore um conjunto de regras, padrões de codificação , aos quais você exigiria que cada parte do código verificado cumprisse.

Muito provavelmente, a base para o seu conjunto de regras, pelo menos no estilo, seria o código existente. Uma vez feito, todos devem cumprir e devem ser inspecionados como parte da revisão do código . O código que não está em conformidade com os padrões não deve ser autorizado a fazer check-in.

A propósito, não precisa ser um voto democrático, é uma das coisas em que o líder da equipe pode realmente executar alguma autoridade. Mas, tendo dito isso, não acho que você possa impor padrões que a maioria da equipe rejeite. Você pode impor padrões que uma única pessoa, especialmente uma nova, rejeita.

Como falar com ele ... Todo programador experiente sabe que cada local e equipe tem suas próprias convenções e estilo, que devem ser seguidos. Você pode dizer a ele que ele é mais que bem-vindo ao sugerir melhorias, mas ele precisa cumprir as regras da equipe e não deve alterar o estilo do código existente, mas sim usar o mesmo estilo ao adicionar novo código.

Além disso, você pode dizer (se você é o gerente ou conversar com ele) a essa pessoa para não fazer certas coisas que você considera inapropriadas (você mencionou define, ordem, hacks e atalhos, etc.).

1. Alguém está no comando - eles precisam agir assim.
2. Se o estilo de codificação é tão importante, por que isso não foi explicado a essa pessoa e informe-os de que não terão acesso a nenhum código até que aprendam as regras.
3. Revisão de código - aparentemente você não tem nenhum ou é muito fraco. Veja # 1.

Anote em seu processo de contratação, que seguir os estilos de codificação aceitos é um requisito para o emprego. Agora, o que você faz com aqueles que não seguem as regras? Comece removendo o acesso ao código ativo até que eles entrem no programa.

.

Aqui está o que pode ser feito:

1. Escreva um documento explicando o estilo de codificação necessário e faça com que todos da equipe aprendam. Colete informações de cada membro da equipe.
2. divida as tarefas de modo que cada membro da equipe seja responsável por sua própria peça e possa decidir as convenções dessa parte do código. Se algum problema for encontrado, quem o escreveu irá corrigi-lo.
3. adicione uma ferramenta automática ao controle de versão, que corrige o recuo e outras coisas toda vez que o código é confirmado no controle de versão
4. Programadores diferentes sempre têm estilos de programação diferentes e, mais tarde, pode ser difícil mudar. A melhor maneira de lidar com isso é compartilhar informações entre os membros da equipe, para que todos aprendam quais estilos as pessoas usaram. Se você tem um membro da equipe que escreve um código diferente, é uma chance dos membros da equipe existentes aprenderem o novo estilo.
5. Um bom truque é nunca modificar o código existente. Em vez de modificar o código, escreva um novo código substituindo as linhas vazias pelo novo. E quando o código estiver pronto, faça apenas a menor quantidade de modificações no sistema existente para usar o novo código. Isso evita alterar o código existente, possivelmente quebrando o que já estava funcionando bem.

Aqui está o que evitar:

1. decidir que o código de alguém é melhor ou pior que outros membros da equipe. Simplesmente não funciona assim - todo mundo conhece certo subconjunto da linguagem o suficiente para usá-lo no código. Todo programador escolheu um subconjunto diferente para aprender e, a menos que eles aprendam juntos, tudo parecerá diferente.
2. Alterando como alguém escreve código. Tudo o que você consegue forçando as pessoas a escrever um estilo desconhecido é que você recebe uma grande quantidade de bugs no código. As pessoas simplesmente não sabem detalhes suficientes de algo que usam na primeira vez. Os programadores sempre escolhem um subconjunto de idioma e o usam sozinhos. Se seus programadores escreveram milhares de linhas de código cheias de gotos, elas fornecerão um código com a menor quantidade de bugs.
3. Você também não deve pensar que a sua base de código existente é uma coisa agradável, limpa e sustentável. Sempre há coisas a melhorar. Mas também todas as alterações confundem a idéia de design original que foi escrita nela. Procure escrever um código perfeito na primeira vez, para que as alterações não sejam necessárias mais tarde. (o novo cara não precisaria "quebrar" seu código perfeito, se fosse feito corretamente na primeira vez)

Nossa base de códigos existente contém principalmente códigos legíveis, limpos e de manutenção

Uma coisa que aprendi ao longo dos anos é que a legibilidade está nos olhos de quem vê. Já vi muitos casos em que o estilo de codificação chickenscratch de alguém é justificado como "legível" e vi pessoas perfeitamente razoáveis ​​argumentarem sobre quais estilos de codificação são os mais "legíveis". Talvez esse cara não veja seu estilo como legível?

Dito isto, o novo cara deve estar em conformidade com seus padrões, e não o contrário.

Considere usar solicitações pull para novo código no repositório. Isso fornece um local conveniente para a revisão do código. O código que falha na revisão de código não é mesclado no repositório até que esteja em forma.

Apenas tome cuidado para não tornar as solicitações pull muito grandes. Na minha experiência, eles não devem ser maiores que entre meio dia e no máximo dois dias, ou você terá muitos conflitos de mesclagem.

Os sistemas vcs online como o bitbucket ou o github suportam essa funcionalidade. Se você preferir um stash de abordagem no local, parece ser a melhor aposta atualmente.

Há uma regra simples que você pode seguir: Se você modificar um arquivo com código, use o padrão de codificação usado nesse arquivo. Se você criar um novo arquivo, use qualquer bom padrão de codificação. (Além disso: se o seu compilador puder emitir avisos, habilite todos os avisos razoáveis, ative os avisos = erro, se possível, e não permita nenhum código com avisos. Além disso: se você usar ferramentas que fazem alterações por atacado em um arquivo, como alterar abas para espaços ou similares, NÃO as use).

A razão pela qual existem enormes argumentos sobre padrões de codificação é que um padrão não é melhor ou pior que outro (geralmente), mas apenas diferente. O único realmente ruim coisa é misturar estilos de codificação.

Obviamente, espero que qualquer programador decente possa escrever código seguindo qualquer padrão de codificação, quer prefira esse padrão em particular ou não.

E, por outro lado, existem padrões de qualidade. Nunca aceite código que não atenda aos seus padrões de qualidade.