Lidar com colegas de trabalho que não possuem um estilo de codificação consistente?

O que você faz quando trabalha com alguém que tende a escrever códigos estilisticamente ruins? O código de que estou falando geralmente é tecnicamente correto, razoavelmente estruturado e pode até ser algoritmicamente elegante, mas parece feio . Nós temos:

• Mistura de diferentes convenções de nomenclatura e títulos ( underscore_stylee camelCasee UpperCamele CAPStodos aplicados mais ou menos ao acaso de diferentes variáveis na mesma função)
• Espaçamento bizarro e inconsistente, por exemplo Functioncall (arg1 ,arg2,arg3 );
• Muitas palavras com erros ortográficos nos comentários e nomes de variáveis

Nós temos um bom sistema de revisão de código onde eu trabalho, então analisamos e consertamos as piores coisas. No entanto, é realmente insignificante enviar uma revisão de código que consiste em 50 linhas de "Adicione um espaço aqui. Soletre 'itarator' corretamente. Altere essa capitalização. Etc."

Como você incentivaria essa pessoa a ser mais cuidadosa e consistente com esses tipos de detalhes?

Concordar com uma convenção de codificação

Mesmo que este seja um pager. Sugiro que toda a equipe se sente e todos concordem com a convenção básica de codificação de trabalho que toda a equipe pode usar.

Eu acho que você só precisa continuar fazendo o que está fazendo. Tenha um conjunto claro de diretrizes de codificação e aplique-as durante as revisões de código. Se um desenvolvedor obtém 50 ou 100 linhas de "Adicionar um espaço aqui" e "Soletrar 'iterador' corretamente" toda vez que ele tenta fazer o check-in de algo, e ele não tem permissão para fazer o check-in antes que todos sejam corrigidos, eventualmente ele terá que começar a escrever um código mais limpo apenas para evitar problemas.

Acho que, se você mesmo consertar essas coisas, como NimChimpsky sugeriu, estará limpando a casa para sempre.

Eu chamo BS para todos que disseram que erros de ortografia e formatação de nomes variáveis ​​não importam. Obviamente, eles apenas leram seu próprio código. E observe essa palavra ali - leia. Imagine ler um livro com muitos erros ortográficos, formatação incorreta, espaçamento inconsistente de linhas e várias outras preguiça que prevalecem em muitos códigos-fonte. Seria tedioso.

Para uma profissão em que sua sintaxe deve estar 100% correta para o trabalho, simplesmente não há desculpa para qualquer desenvolvedor real não ter um estilo de código limpo e consistente. Qualquer outra coisa é negligência e preguiça. Eu sempre questiono a correção do código mal formatado na implementação.

Nós temos um bom sistema de revisão de código onde eu trabalho, então analisamos e consertamos as piores coisas. No entanto, é realmente insignificante enviar uma revisão de código que consiste em 50 linhas de "Adicione um espaço aqui. Soletre 'itarator' corretamente. Altere essa capitalização. Etc."

Eu mesmo mudaria e depois adicionaria um comentário educado no código.

isso pressupõe que já exista um guia de estilo, conforme a pergunta:

Temos um bom sistema de revisão de código

Portanto, minha sugestão é um último recurso, acho que é tão rápido alterá-lo você mesmo e deixar um comentário, como enviar um e-mail ou o que for.

Penso que convenções como a nomeação de classes e variáveis ​​são importantes e devem ser seguidas através de um código elegante e eficiente também, mas correndo o risco de ter minha resposta rebaixada muitas vezes, tenho que dizer que, em geral, o paradigma "código bonito" que é empurrado muito ao redor está no IMHO muito sobrestimado.

Primeiro, o desenvolvedor que o escreveu terá que mantê-lo em primeiro lugar, e se ele for atropelado por um ônibus e outro programador não conseguir descobrir como isso funciona, porque o código não é "bonito", eu diria que o outro desenvolvedor não é muito bom de qualquer maneira. E há muitos formatadores / embelezadores automatizados por aí, então qualquer pessoa pode usá-los para embelezar o código, se necessário, sem perder tempo enquanto está "no fluxo" / "na zona".

Observe que não estou defendendo a codificação no estilo espaguete / vaqueiro aqui, na verdade, eu vi um código espaguete muito bem formatado (corpos de função que abrangem 4-5 telas, variáveis ​​globais espalhadas por diferentes arquivos de código-fonte, geralmente escolhas ruins de nomes etc).

Um dos meus colegas escreve html de tal maneira que minha pele se arrepia. Imagine meu html agradável e estruturado com dois recuos espaciais, cortados em pedaços por tags adicionadas ao final do meu que terminam na mesma linha ou no seguinte como um bêbado que precisa dar um abraço em você para ficar em pé. Novas linhas raramente são recuadas, mas se estiverem, tenho certeza de que há algum buraco negro altamente caótico em alguma parte da galáxia emitindo valores irracionais de temperatura de tal maneira que, de alguma forma, seus dígitos espelham o número de espaços ou guias usados ​​em tal recuo por esta mulher. Se tiver sorte, vou ver uma tag de entrada fechada com " </input>". Pesadelo total que você pode entender.

Ninguém parece entender isso também, ver como para a maioria dos superiores aqui, código organizado ou código não organizado, é como a diferença entre colocarmos queijo suíço ou queijo americano em nossos sanduíches, ou seja, eles realmente se importam menos. Comecei a deixar passar, porque estava estressado com outro projeto, e acho que ela começou a perceber o quão difícil era entender um código assim antes de querer melhorar. Meu conselho seria demonstrar por que é preferível estilizar seu código mais do que simplesmente dizer a eles para fazê-lo.

O código do qual estou falando geralmente é tecnicamente correto, razoavelmente estruturado e pode até ser algoritmicamente elegante ...

Fique feliz por ter conseguido tudo isso. A maioria dos programadores talvez dê a primeira coisa nessa lista. Eu acho que nomeação e espaçamento variáveis ​​são a coisa menos importante para se preocupar.

Parece que você precisa configurar e concordar com uma convenção de estilo. Caso contrário, você terá bibliotecas com 3 recuos de espaço, outras com 4, algumas que usam Camel Case e outras que usam underscore_case.

As mudanças que você deseja fazer nas suas preferências pessoais ou você tem um padrão real a seguir? Se você não possui um padrão real, não faça isso. Primeiro defina um padrão. Em seguida, você pode obter um software que pode ser definido para refatorar o código para as configurações padrão (pelo menos em algumas coisas).

Se você possui um padrão, comece a aplicá-lo na revisão de código. Não há sentido em ter um padrão se você não o aplicar na revisão de código. Isso significará muito trabalho extra em manutenção, pois as pessoas terão que corrigir o código antigo que não atendeu ao padrão original quando o tocou.

Mesmo sem um padrão, insista em corrigir erros de ortografia em nomes de variáveis ​​(eu não me preocuparia particularmente com comentários), pois eles deixarão todo mundo que toca no código louco para sempre.

Os padrões de codificação precisam ser identificados para que todos saibam o que são e, em seguida, precisam ser aplicados. Deveria haver consequências para não seguir as regras.

Aqui estão as coisas que devem fornecer algum incentivo:

1. As revisões de código serão tediosas e mais longas que o necessário.
2. O código será rejeitado com mais frequência.
3. Os horários não serão cumpridos.

Se essa pessoa não precisa se preocupar com isso, porque ninguém aplica suas regras ou elas não se importam se são improdutivas (e ninguém faz nada sobre isso), não há muito o que fazer.

Eu ficaria tentado a sugerir um bate-papo particular e ver se vocês dois poderiam encontrar uma causa raiz:

1. O colega de trabalho está com pressa e porque alguém queria o código ontem, a pessoa está tentando fazer com que algo funcione o mais rápido possível? Essa pode ser uma oportunidade para informar essa pessoa a se concentrar mais na qualidade do que na velocidade do trabalho. Um mantra como "Não se apresse" pode ser útil se isso não for contraproducente.

2. Como a pessoa vê seu trabalho? Se houver um sentimento de orgulho, você poderá usar um ângulo para conseguir que alguém melhore. Se é apenas um trabalho que paga as contas, pode ser muito mais difícil obter alterações. Eles sabem que não estão fazendo um ótimo trabalho, mas estão tão perto disso?

3. Essa pessoa não concorda com as convenções e está tentando codificar em protesto? Nesse caso, você pode ter um grande problema, mas vale a pena descobrir se é esse o caso ou se a pessoa é apenas preguiçosa? Que tipos de motivação podem ser úteis aqui, por exemplo, você poderia apelar à ganância, ao orgulho ou a algum outro vício para fazer a pessoa melhorar. Isso é sorrateiro, mas possivelmente eficaz se tentar a rota do cara legal não chegar a lugar algum.

4. Como conquistar amigos e influenciar as pessoas tem algumas sugestões em termos de persuasão que podem funcionar, como elogiar melhorias e dar à pessoa uma boa reputação para defender.

Quanto ao motivo pelo qual isso deve ser feito em particular, aqui estão algumas razões:

1. Há uma boa chance de humilhação, crítica ou outro desconforto que é melhor manter atrás de uma porta do que deixar de fora onde alguém pode sentir que seu personagem está sendo assassinado.

2. Você quer incentivar essa outra pessoa a se abrir um pouco. Um desafio aqui é que algumas pessoas são tão protegidas que pode levar muito tempo para derrubá-las.

3. Se possível, sugiro tentar fazer isso um pouco longe do escritório. Sair para almoçar, passear ou fazer algo para que os arredores sejam alterados o suficiente para que a pessoa possa se sentir um pouco mais confortável. Isso pode ser um desafio e requer conhecer a pessoa, mas a idéia aqui é que no escritório algumas pessoas usem uma máscara de trabalho que provavelmente não será útil aqui.

4. Esteja preparado para que a conversa fique um pouco quente ou feia, mas isso pode ser um bom sinal se você puder manter a outra pessoa envolvida e ter um bom diálogo. Algumas pessoas gostam de manter as coisas ao ar livre e outras podem preferir maneiras mais sutis de fazer as coisas. A chave é garantir que você esteja ouvindo a outra pessoa o suficiente para ter empatia e tentar entender o lado deles.

Temos um teste JUnit que procura por problemas de formatação. Ele é executado como parte da compilação. Eu fico cada vez mais omitindo um espaço entre if, while ou for e o parêntese de abertura. Nosso código é formatado consistentemente.

http://code.google.com/p/kawala/wiki/BadCodeSnippetsRunner

O embelezamento de código, como não criptografar , poderá resolver alguns dos seus problemas. Se você está pronto para pagar por isso, existem softwares de alto nível que incorporam as regras no próprio código-fonte, como a Parasoft . A Parasoft torna obrigatório escrever o código em estilo uniforme. Você também pode incorporar suas próprias regras. Quando essas ferramentas são usadas, os desenvolvedores são forçados a usar um estilo uniforme. E depois de um tempo eles vão se acostumar.

Se você usar o Eclipse, ative Salvar Ações para os Editores de Java e peça a todos para usá-lo. Isso corrige os problemas de formatação a cada salvamento, mas não corrige a capitalização incorreta. Pode ser bastante útil!

Quão difícil é seguir as convenções de estilo? Eu entendo os erros ortográficos, mas o resto é um indicador de pensamento e codificação desleixados. Diga à pessoa que ela precisa ser mais consistente no que diz respeito ao código de produção, porque eles não são os únicos que o examinarão. É simplesmente rude, egoísta e imprudente escrever código de produção em um estilo inconsistente.

RI MUITO. Você absolutamente odiaria o meu código. Não sei soletrar para salvar minha vida e não me importo.

Mas sei que algumas pessoas realmente se importam com essas coisas.

Eu sugiro que você demitir a pessoa que escreve esse código feio, se não mudar, e encontrar alguém que torne as coisas realmente bonitas e espero que possa escrever código que

geralmente é tecnicamente correto, razoavelmente estruturado e pode até ser algoritmicamente elegante

e se eles não puderem, pelo menos você pode mostrar o código bonito quebrado ao cliente e vendê-lo!

Mas seriamente. Concentre-se nas coisas realmente importantes primeiro. Se você não consegue encontrar uma razão boa e sólida fora de "isso machuca minhas delicadas sensibilidades", então a ignore por enquanto. Se é realmente importante, sente-se com a pessoa e convença-a dessa importância. Coisas como padrões que facilitam a diferença entre nível de classe, nível de método, variáveis ​​compartilhadas e constantes fazem a diferença. Se o codificador em questão se importar com sua profissão, ele entenderá e tentará fazer a coisa certa.

Minha solução ao lidar com recursos terceirizados que não deram a &% $ # sobre formatação (ou bugs facilmente evitáveis) foi fazer com que o servidor de compilação reforçasse isso. Criei um trabalho de servidor de CI que executava todas as noites que fazia o check-out do código, executava o Jalopy e o findbugs e depois fazia o check-in novamente. Depois que a outra equipe aprendeu que o não uso das convenções de código padrão tornaria o trabalho mais difícil, eles começaram a usar o IDE para manter um formato padrão.