Lidando com padrões de codificação no trabalho (não sou o chefe)

38

Eu trabalho em uma equipe pequena, com cerca de 10 desenvolvedores. Nós não temos nenhum padrão de codificação. Há certas coisas que se tornaram a norma, mas algumas maneiras de fazer as coisas são completamente diferentes. Meu grande é o recuo. Alguns usam guias, alguns usam espaços, alguns usam um número diferente de espaços, o que cria um problema enorme. Muitas vezes acabo com conflitos quando eu mesclar porque alguém usou seu IDE para o formato automático e eles usam um caractere diferente para recuar do que eu. Eu não me importo com o que usamos Eu só quero que todos usem o mesmo.

Caso contrário, abro um arquivo e algumas linhas têm chaves na mesma linha que a condição, enquanto outras estão na próxima linha. Mais uma vez, não me importo com qual deles, desde que sejam todos iguais.

Eu trouxe a questão dos padrões para o meu gerente direto, um a um e em reuniões de grupo, e ele não está muito preocupado com isso (há vários outros que compartilham a mesma visão que eu). Eu mencionei minha preocupação específica com os caracteres de recuo e ele pensou que uma solução melhor seria: "criar algum tipo de roteiro que pudesse converter tudo isso quando forçarmos ou retirarmos do repositório". Eu suspeito que ele não quer mudar e esta solução parece excessivamente complicada e propensa a problemas de manutenção no caminho (também, isso aborda apenas uma manifestação de um problema maior).

Algum de vocês se deparou com uma situação semelhante no trabalho? Se sim, como você lidou com isso? Quais seriam alguns pontos positivos para ajudar a vender meu chefe em padrões? Começar um movimento de base para criar padrões de codificação, entre aqueles que estão interessados, seria uma boa ideia? Estou sendo muito particular, deveria simplesmente deixar ir?

Obrigado a todos pelo seu tempo.

Nota: Obrigado a todos pelo excelente feedback até agora! Para ser claro, eu não quero ditar um estilo para dominá-los todos. Estou disposto a admitir minha maneira preferida de fazer algo em favor do que melhor combina com todos. Eu quero coerência e quero que isso seja uma democracia. Eu quero que seja uma decisão do grupo em que todos concordem. É verdade que nem todos conseguirão o que querem, mas espero que todos estejam maduros o suficiente para comprometer a melhoria do grupo.

Nota 2: Algumas pessoas estão presas nos dois exemplos que dei acima. Eu sou mais depois do cerne da questão. Ele se manifesta com muitos exemplos: convenções de nomenclatura, funções enormes que devem ser quebradas, se alguma coisa for usada em um utilitário ou serviço, se alguma coisa for uma constante ou injetada, se todos usarmos diferentes versões de uma dependência ou a mesma, interface deve ser usada para este caso, como devem ser configurados os testes unitários, o que deve ser testado em unidade, (específico para Java), se usarmos anotações ou configuração externa. Eu poderia continuar.

    
por Josh Johnson 18.07.2011 / 15:34
fonte

13 respostas

72

Um colega de trabalho e eu tivemos um problema semelhante em nossa equipe quando nos unimos pela primeira vez (eu entrei para a equipe primeiro, ele se juntou cerca de um ano depois). Não havia padrões de código reais. Somos uma loja de MS e nem os padrões de codificação da MS foram usados. Nós decidimos liderar pelo exemplo. Nós nos sentamos juntos e elaboramos um documento que tinha todos os nossos padrões: padrões IDE, padrões de nomenclatura, tudo em que pudemos pensar. Então ele e eu concordamos em seguir o padrão explicitamente. Enviei um e-mail para a equipe (de nós dois) e avisei-os de que havíamos encontrado uma falta e resolveríamos a falta com nosso documento. Nós convidamos críticas, idéias, comentários, opiniões. Recebemos muito pouco na forma de feedback e apenas um pequeno empurrão para trás. Ele e eu imediatamente começamos a usar os padrões, e quando trouxemos desenvolvedores juniores para nossos projetos, nós os apresentamos ao padrão e eles começaram a usá-lo. Nós temos alguns líderes que relutaram no início, mas começaram lentamente a usar o padrão para muitas coisas.

Descobrimos que muitos dos desenvolvedores júnior haviam reconhecido o mesmo problema, mas estavam esperando que alguém se aproximasse e tomasse a decisão. Uma vez que havia um plano a seguir, muitos estavam ansiosos para adotá-lo. Os malucos mais difíceis de quebrar são aqueles que se recusam a codificar por qualquer outro meio, e eles geralmente se codificam fora da imagem a longo prazo.

Se você quiser padrões, chame o caminho. Invente uma lista sugerida de padrões que você acha que beneficiaria sua equipe. Envie para os colegas e leva para feedback. Tenho certeza de que outras pessoas em sua equipe têm ideias parecidas, mas elas provavelmente não têm o bom senso para fazer algo a respeito. Como Gandhi disse: "Você deve ser a mudança que deseja ver no mundo".

    
por 18.07.2011 / 15:52
fonte
6

Os padrões não devem ser definidos e aplicados por um gerente. A equipe como um todo deve concordar com os padrões. Se eles não conseguirem concordar com um conjunto comum de padrões, fazer com que um gerente force os padrões sobre eles falhará.

Você e os outros que concordam com você devem dar o exemplo. Comece a usar os mesmos padrões de codificação, publique-os e promova-os para o restante da equipe e peça feedback sobre como melhorá-los.

Aqui está a parte importante ao tentar promover os padrões: certifique-se de que o foco não está em encontrar a maneira melhor de fazer as coisas, mas em encontrar uma maneira consistente de fazer as coisas. Por mais que algumas pessoas possam discordar, não há um estilo de chave verdadeira, nenhum estilo de comentário verdadeiro etc. O que torna o código mais fácil de ler (e, portanto, mais fácil de manter) é um estilo consistente, não importa o que seja. p>     

por 18.07.2011 / 15:52
fonte
5

Você pode mostrar alguma evidência do tempo que você desperdiçou devido aos problemas que isso está causando?

Se você está gastando uma quantidade significativa de tempo trabalhando em torno desses problemas, ou se está causando bugs que demoram a ser resolvidos, esse é um custo que você pode reduzir drasticamente adotando padrões de codificação.

Portanto, mantenha um registro dos problemas encontrados e o tempo necessário para resolvê-los - tanto para você quanto para os colegas (onde você está ciente deles).

Então, quando você tiver uma quantidade razoável de dados, apresente aos seus colegas. Eles devem ver o benefício de adotar um padrão. Se não mostrar os dados para o seu chefe e seu chefe. Mostre que, ao ter padrões de codificação, você pode economizar o dinheiro da sua empresa e eles devem ajudá-lo a adotá-los.

    
por 18.07.2011 / 15:42
fonte
3

Na sua situação particular, acho que a solução do seu chefe é boa. Ninguém precisa mudar o que eles estão fazendo em toda a carreira, e tudo bem, porque os bits de estilo de código que o compilador ignora não importam, desde que o código seja legível. Se todos fizessem um autoformatação no estilo ao fazer check-out e uma autoformatação em um estilo padrão ao fazer o check-in, tudo ficaria bem. (Infelizmente eu sugeri que onde eu trabalhasse e se opusesse com base no fato de que o codificador não estaria mais escrevendo o mesmo código exato que o servidor de integração contínua vê.)

Eu acho que os padrões de codificação são bons quando aplicados em lugares onde faz uma diferença real na qualidade do código: por exemplo, métodos pequenos, classes que têm uma responsabilidade clara, comentários úteis e precisos para os bits mais difíceis, etc. , esses aspectos são mais difíceis de verificar automaticamente, mas isso é fundamental para o desenvolvimento de software. Tudo o que você pode realmente fazer é ensinar boas práticas aos outros e aprender a ler o código com a chave na linha errada.

    
por 18.07.2011 / 15:47
fonte
2

Em relação aos padrões de codificação: Eu vou subir com quase todos os outros dizendo que os padrões de codificação são uma "coisa boa" (versus nenhum padrão).

No entanto, não se empolgue. Eu trabalhei em alguns projetos que ditaram um estilo de recuo específico, até o número de caracteres (e quando os projetos chegam tão longe, eles inevitavelmente escolhem algo estúpido como um recuo de 8 espaços). Não se preocupe com as pequenas coisas.

Uma solução simples: dê aos desenvolvedores um conjunto limitado de opções de contraventamento e recuo, mas determine que o estilo e o recuo da chave devem ser consistentes em um módulo. (Você quer que foo.h e foo.cpp sigam o mesmo estilo, não é?) Mantenedores devem adaptar-se ao estilo existente; eles não podem reescrever um módulo para se adequar ao seu estilo extravagante. Vários estilos dentro de um módulo são apenas confusos e são um sinal de desleixo. Quando vejo esse absurdo, fico imaginando o que há de errado.

Você também pode querer pensar em banir abas para recuo no conteúdo salvo de um arquivo . A maioria dos IDEs / editores fazem um trabalho razoável ao traduzir as abas de entrada do usuário em espaços, e a maioria tem opções para tornar essa tradução automática. Muitos fazem um trabalho de baixa qualidade quando o arquivo já contém abas, particularmente uma mistura de abas e espaços.

Tudo o que disse, acho que você pode ter um problema mais profundo em seu projeto. Você mencionou problemas com a mesclagem. Se você precisar fazer muita mesclagem, pode ser um sinal de um mau particionamento do projeto. Assim como muitos cozinheiros estragam o caldo, muitos programadores que operam no mesmo arquivo estragam o projeto. Por que cada um de Joe, Susie e você toca em foo.cpp?

    
por 18.07.2011 / 16:39
fonte
1

Esta é uma das áreas em que algumas pesquisas são feitas. Basicamente, a questão principal é se você está fazendo revisões de código. Revisões de código são sem dúvida o meio mais eficiente para melhorar a qualidade do código. (Fonte: Software Engineering Institute, CMU). Certamente é mais eficiente que um testador extra.

Agora, as revisões de código se beneficiam de um padrão de codificação comum, pois isso facilita a leitura do código de outras pessoas. Isso fornece um argumento de dois passos para introduzir padrões de codificação: no final, torna mais barato produzir um bom código.

    
por 18.07.2011 / 15:44
fonte
1

Como já existem "vários outros" que estão com você sobre isso, sugiro uma reunião improvisada. Convide todos os desenvolvedores, demore um pouco e descubra quais coisas estão incomodando a si mesmo e aos seus colegas no dia-a-dia. Não tente encontrar soluções específicas no começo, apenas descubra o que precisa mudar na forma como você está escrevendo código no momento.

Depois, veja se todos podem concordar com alguns conceitos básicos. A sugestão de usar o mesmo estilo em cada módulo que o @David Hammen criou é um bom começo, e acho que a maioria dos desenvolvedores poderia concordar.

Se, depois de ter tido essa queda, você sentir que todos podem concordar com algum estilo básico para escrever um novo código, isso é um bom acréscimo. Concentre-se nas coisas que realmente afetam a manutenção; problemas de nomenclatura estariam no topo da minha lista pessoal porque se você tiver meia dúzia de estilos diferentes de nomeação em um único produto de qualquer complexidade notável, vai se tornar uma dor de cabeça muito rapidamente, mas novamente, focar no que você e sua equipe sentir é importante . Faça um rascunho de um documento curto que todos possam pelo menos concordar em seguir (mesmo que eles mesmos tenham um estilo de animal de estimação diferente) e enviá-lo para todos da equipe. Torne um documento "vivo", atualize-o com o tempo, mas certifique-se de não torná-lo demasiado rígido e específico.

A menos que seu chefe esteja envolvido em escrever código, ele não deve se preocupar muito com qual estilo exato é adotado (desde que se concentre na legibilidade e manutenção), mas ele deve ser capaz de ver os benefícios de todos na equipe seguinte um estilo comum ao escrever código.

    
por 18.07.2011 / 17:05
fonte
1

Existem algumas coisas que são dolorosas. O mais doloroso é um IDE que reformata automaticamente o código, combinado com desenvolvedores que configuram seus IDEs de maneiras diferentes. Toda vez que você compara o código, você tem centenas de alterações depois que alguém com diferentes configurações editou o código. Isso é inaceitável. Aqui você precisa bater a cabeça de todos juntos, concordar com um conjunto de configurações e rejeitar qualquer check-in de alguém usando configurações diferentes. Se eu alterar uma única linha de código, os diffs devem mostrar uma única linha de código alterada, e não centenas.

Tudo o mais é inofensivo, ou há maneiras melhores de fazer coisas de que outras pessoas podem ser convencidas. Aqui a regra deve ser: Não mexa no código de outras pessoas, a menos que você realmente o melhore. E uma mistura de estilo A e estilo B é sempre pior que o estilo A ou o estilo B.

Certifique-se de seguir as melhores práticas. Qual é diferente por idioma. Mas lá você não precisa de padrões (que podem ter sido escritos por alguém bem-intencionado, mas não tão qualificado), mas todos deveriam tentar dar bons exemplos.

Evite definitivamente as lutas pelo poder. Não há nada pior do que algum pequeno Hitler em sua equipe tentando forçar todos a sua vontade. E infelizmente esse é o cara que se oferecerá para escrever seus padrões de codificação: - (

    
por 09.05.2014 / 19:09
fonte
0

Todos os exemplos que você deu são basicamente sobre espaço em branco e formatação. Se esse é o maior problema, eu meio que concordo com o seu gerente: não é grande coisa assim.

Onde os padrões são realmente muito úteis é nomear coisas e reduzir a complexidade. Como nomear identificadores, classes, onde colocá-los, etc. Manter os nomes consistentes é extremamente importante, especialmente em um grande projeto . As regras para reduzir a complexidade incluem manter funções sob um certo número de linhas (dividi-las em funções menores) ou manter listas de parâmetros abaixo de um certo número de argumentos (talvez você devesse agrupá-las em um objeto e passar isso). p>

Se um desenvolvedor específico de sua equipe escreve código que é mais difícil de entender / depurar porque inclui muitos trechos longos de código com nomes de variáveis de letras únicas, isso é uma boa razão para adotar alguns padrões, e não algo que possa ser corrigido com um script. É bom salientar (com tato) como uma coisa que os padrões podem melhorar.

Outra razão pela qual seu gerente pode não vê-lo como um problema é que você não lê o código do outro com muita frequência. Isso pode acontecer quando todos têm sua própria área do código e não não se arrisque muito fora disso. Isso funciona muito bem até que alguém saia da organização, o que poderia acontecer por vários motivos bons ou ruins. Padrões que ajudam a legibilidade tornarão mais fácil para um novo desenvolvedor assumir a manutenção de um trecho de código.

    
por 18.07.2011 / 21:13
fonte
0

conflicts when I merge because someone used their IDE to auto format and they use a different character to indent than I do

parece que esse é o seu problema, não a formatação, mas a reformatação. Este é um problema enorme para SCMs e o conselho é simples: não faça isso. Então, da próxima vez que alguém re-formatar todos os espaços para abas, ou refatorar as chaves para o seu estilo preferido, você precisa dar um tapa nelas. Faça-os fazer a fusão em vez disso; fique de pé sobre eles, parecendo desaprovar a perda de tempo que sua falta de pensamento causou.

A alternativa é colocar um formatador de pre-commit, que sempre re-formata todo o código para o estilo padrão antes do checkin. Se você tem uma equipe de desenvolvedores que reformatam normalmente, essa é uma boa opção - o SCM sempre verá o mesmo formato, portanto os deltas serão pequenos e fáceis de mesclar.

    
por 19.07.2011 / 00:21
fonte
0

Quando alguém sugere um novo padrão de codificação onde eu trabalho, nós votamos nele. Se obtiver uma votação majoritária, será aceito, caso contrário, será rejeitado. Se você não fizer isso, não conseguirá aceitar seus padrões e eles não serão usados, mesmo que estejam documentados.

    
por 19.07.2011 / 01:03
fonte
0

A partir do seu problema específico, sua melhor aposta provavelmente estará começando com a sugestão de Joel e liderando pelo exemplo. Reúna 1 ou 2 programadores que se importem com isso, chegue a um acordo e você terá alguma força para impor aos preguiçosos.

Agora, para o problema genérico, acho melhor simplesmente modular . Cada pessoa recebe um arquivo diferente, se você tiver que manter a manutenção em um arquivo, manterá seus padrões de codificação intactos, mesmo que sejam diferentes do outro. Precisa escrever no mesmo arquivo? Crie um arquivo de subconjunto e inclua-o em seu lugar.

    
por 19.07.2011 / 04:35
fonte
0

Não tente isso!

Liderar pelo exemplo de contador. Tente tornar o seu formato de código o mais horrível possível, e registre em lotes mudanças horrivelmente formatadas no código bonito de outras pessoas. Quando a reação (inevitável) ocorre, diga que o que você está fazendo é bom porque não há um padrão de codificação.

Se você não for linchado por seus colegas de trabalho (!!), você pode acabar com um padrão de codificação.

Obviamente, esta é uma estratégia de alto risco ...: -)

    
por 19.07.2011 / 05:32
fonte