Como devo introduzir um padrão de codificação para minha equipe?

8

Primeiro, um pouco de histórico: meu atual gerente de desenvolvimento está aproveitando outra oportunidade no final desta semana, deixando nossa equipe com quatro desenvolvedores em período integral, um estagiário em período parcial e um web designer (que é tecnicamente parte do Marketing, não do AppDev). No momento, não estamos promovendo ou contratando um novo gerente.

O gerente anterior nunca teve tempo para criar um conjunto de padrões de codificação a seguir (para colocar isso em perspectiva: meu aniversário de um ano neste trabalho é daqui a duas semanas e eu converso com ele sobre padrões desde Eu comecei). Devido a isso, todos nós, quatro desenvolvedores, escrevemos código da nossa maneira: alguns de nós seguem as convenções de nomenclatura da Microsoft para .NET, alguns usam notação húngara, outros usam uma mistura (por exemplo, mixagem PascalCasee camelCasenomes de parâmetros) e é totalmente aleatório quando você abre um arquivo de código que padrão ele seguirá - a única coisa consistente é que as chaves estão em linhas separadas.

Dois dos meus três colegas de trabalho entraram em contato comigo para criar um documento de codificação padrão que podemos usar e forçar a avançar (embora eu não seja tecnicamente o desenvolvedor mais sênior, o quarto desenvolvedor está aqui há vários anos, dois colegas de trabalho e o estagiário procura aconselhamento / orientação, mas não temos um líder de equipe). Eu pretendo fazer isso há algum tempo, mas o gerente que partia sempre o colocava em segundo plano; sua partida agora nos dá a chance de levar algum tempo e configurar as coisas corretamente para facilitar um ambiente de software adequado e não a mistura apressada que temos atualmente.

Como devo fazer isso e apresentar esse padrão à minha equipe sem causar atrito? Não quero que pareça que estou "assumindo o controle", embora me oferecessem o cargo de gerente que aceitaria. Como eu disse, dois de três outros desenvolvedores estão a bordo comigo, criando um, mas o quarto (o verdadeiro "senior" em questão de tempo) pode ou não aceitá-lo. Eu pretendo começar com as convenções .Net da Microsoft (por exemplo, não use a Notação Húngara), adicionar algumas preferências pessoais (por exemplo, _camelcasepara campos) e chamar especificamente determinadas práticas estranhas que usamos aqui como não devem ser usadas (por exemplo, nomear uma classe com sublinhado no início), mas o que mais devo incluir? Eu não quero entrar em diretrizes arquitetônicas como que vontade causam atrito e temos uma base de código existente muito grande e fedorenta que não iria aderir a ela, e não estamos nem perto de chegar a uma estratégia de refatoração.

Para resumir: Além das convenções básicas de nomenclatura, o que devo incluir em um documento sobre padrões de codificação (os exemplos seriam ótimos - não consegui encontrar exemplos concretos de como deve ser esse documento) e como devo apresentá-lo à minha equipe sem parecer o novo ditador.

.net coding-standards teamwork

— Wayne Molina
fonte

Além das convenções de nomenclatura, você desejará uma maneira padrão de descrever o que o arquivo faz nos cabeçalhos, além de possivelmente uma estrutura de diretório padronizada. Veja o guia de estilo do Google como um exemplo.

— Chrisaycock

Você não tem gerente / líder de equipe e está preocupado com os padrões de codificação!

— mattnz

Podemos não precisar de um líder de equipe para ser honesto, a maioria de nós concorda com as coisas e colabora por conta própria. Os padrões são uma preocupação porque já existe "vamos falar sobre eles" há quase um ano, com tempo zero sendo alocado para sentar-se para discutir alguns.

— Wayne Molina

2

O fato de você não se sentar para uma reunião de 30 minutos em quase um ano indica para mim que você realmente precisa de um líder de equipe.

— mattnz

Possivelmente. O gerente anterior estava com pressa de pôr em prática o código, e não "perder tempo" com coisas como falar sobre padrões ou tentar implementar CI, testes, revisões de código ou algo parecido. Na única vez em que tentamos resolver o problema, o desenvolvedor sênior ficou tenso com o fato de a reunião estar demorando muito ("tenho trabalho a fazer!" Era a citação exata)) e saiu em disparada, terminando abruptamente.

— Wayne Molina

10

Como devo fazer isso e apresentar esse padrão à minha equipe sem causar atrito?

Você também diz:

Dois dos meus três colegas de trabalho entraram em contato comigo para criar um documento de codificação padrão que podemos usar e impor no futuro

Parece que você já tem algum apoio da maioria da equipe. Faça da criação do documento algo que é feito por todos vocês (todos os quatro, se possível). Se isso consumir muito tempo, crie seu documento e mostre-o como rascunho para seus colegas. Depois que todos concordarem e finalizarem uma versão, você estará pronto.

Um bom lugar para começar é dar uma olhada nas diferentes regras do stylecop - você não precisa seguir todas elas, mas elas dão uma idéia do que o documento deve conter. Como um bônus adicional, você pode implementar facilmente o stylecop em suas soluções e até integrar-se a uma compilação automatizada (falhando na compilação se houver violações).

Para resumir:

Veja as ferramentas e os padrões existentes para decidir o que você deseja no seu.

Para evitar parecer um ditador, faça da mudança uma colaboração.

— Oded
fonte

"Para evitar parecer um ditador, faça da mudança uma colaboração." Tão verdade. Você tem três rotas para o sucesso aqui: 1. use um padrão externo, para que todos tenham algo que gostem e algo que não gostam (fxcop, stylecop ou até mesmo qualquer .pdf que você possa encontrar na web). 2. Geração colaborativa. 3. Você é um herói lendário com anos de experiência e as pessoas se reúnem para trabalhar com você e são amadas por todos, ou talvez seu sobrenome seja Zuckerberg, Page ou Brin.

— anon

6

Além das convenções básicas de nomenclatura, o que devo incluir em um documento de normas de codificação, se houver alguma coisa?

Nada.

Não tenha pressa. Vai devagar. Não perca tempo escrevendo. As convenções de codificação só funcionam quando fazem parte da cultura comum.

Se eles não fazem parte da cultura, são simplesmente ignorados.

Como devo fazer isso e apresentar esse padrão à minha equipe

Revisões de código. É um ótimo lugar para apresentar o problema resolvido pelas convenções de codificação.

Na maioria das vezes, as convenções são simplesmente uma perda de tempo. Quando você tem um problema real (ou seja, programas ilegíveis) que pode resolver por meio de convenções de codificação, pode obter 100% de conformidade rapidamente.

As convenções de codificação que são apenas preferências pessoais não resolvem um problema. E, de fato, durante uma revisão de código, você pode descobrir algo melhor e realmente alterar sua preferência pessoal.

Não canonize muito em um documento de convenções de codificação. Trabalhe cooperativamente para chegar a um entendimento comum.

Não quero entrar em diretrizes de arquitetura, pois isso causará atrito e temos uma base de código existente muito grande e fedida que não iria aderir a ela,

Política ruim.

Um padrão arquitetural nunca é algo com 100% de aderência. Não pode ser É sempre uma descrição "prospectiva", na qual o desenvolvimento evolui.

Toda boa idéia arquitetônica levará a uma nova direção arquitetônica. E é assim que a inovação se parece - um caminho, não um objetivo.

e estamos longe de chegar a uma estratégia de refatoração.

Boa. Não desenvolva um. Com isso, quero dizer "não sufoque a inovação escrevendo muitas coisas que podem ou não ser a melhor abordagem possível".

— S.Lott
fonte

4

Com algo como convenções de codificação, eu diria que qualquer convenção específica deve ser 100% unânime ou encontrar algum meio termo que a torne 100% unânime.

Estabeleça um prazo para o documento ser concluído, isso forçará outras pessoas a levarem a sério.
Faça o trabalho de compilar o documento, ninguém terá vontade de ajudá-lo, mas se você é o proprietário do trabalho, ninguém lutará com você.
Envie propostas para várias convenções de codificação com base em estilos diferentes que existem na base de código agora. Obtenha feedback e marque uma reunião em que eles possam ser votados.
Ninguém sai da reunião até que cada convenção chegue a um acordo 100% unânime
As novas pessoas da equipe terão que respeitar o documento e não terão voz. É como a Constituição naquele ponto.

Ah, e nenhuma notação húngara. Sério, eu preferiria ocultar meus olhos do que ter que olhar o código na notação húngara.

— maple_shaft
fonte

1

O húngaro é uma coisa importante, assim como os nomes de classe sublinhados. Ver algo assim _Customer oCust = new _Customer();me faz balançar a cabeça em perplexidade.

— Wayne Molina

Eu assumi a tarefa de compilar um novo conjunto de padrões de codificação para minha empresa. Felizmente, tive a ajuda de um conjunto de desenvolvedores seniores que também eram novos na empresa e tivemos um vice-presidente nos apoiando na aplicação da lei. Atualizamos o documento a cada poucos meses, conforme necessário. Após a segunda grande revisão, adicionei numeração de seção ao documento que tornou mais fácil fazer referência a um padrão específico quando um projeto falhou na revisão de código. "Confira a seção 5.3.4.6 sobre o uso da funçãoA em vez da funçãoB". No último ano, finalmente estamos recebendo menos revisões de código com falha.

— Adrian J. Moreno

1

Os padrões de codificação serão um desafio para serem aceitos. Algumas pessoas gostam de codificar em sua caixa de areia e apenas fazem suas coisas, apesar de poder causar problemas se quebrar e outras tentarem corrigi-la.

Se você estiver usando o Visual Studio com .NET, dê uma olhada no StyleCop. Você pode usar os conjuntos de regras predefinidos ou escrever seus próprios. Em seguida, peça a todos que concordem, antes das revisões de código (se houver), de que devem seguir as configurações.

— ist_lion
fonte

1

Do ponto de vista técnico:

Indique as inconsistências que realmente são um problema para a equipe e defina regras de codificação para solucionar esses problemas.

Do ponto de vista relacional:

Se você quiser envolver o sênior, inspire-se nas convenções de codificação dele.

— mouviciel
fonte

Bem, parte do motivo pelo qual queremos padrões de codificação é porque o sênior não segue nenhum. Ele usa a notação húngara em todos os lugares, ele não sabe que os métodos podem ser sobrecarregados (portanto, haverá um GetFoométodo e, em seguida, um GetFoo_WithSomethingElsemétodo que tem a mesma coisa, mas com um parâmetro extra, com toda a lógica copiada e depois a extra bits adicionados) e ele não entende o design da classe além de apenas colocar muita lógica em um arquivo code-behind. O gerente que partiu não se importava em fazer as coisas de maneira diferente, apenas seguiu esse estilo.

— Wayne Molina

Foi o que pensei. Parece que seu projeto tem problemas não técnicos e você tenta resolvê-los com uma resposta técnica.

— Mouviciel

Qual seria a maneira correta de resolver os problemas? A questão é que ninguém pensou nessas coisas desde que a empresa começou.

— Wayne Molina

Posso estar errado, mas o problema que vejo é que um desenvolvedor sênior que escreveu código por muitos anos não tem motivos para mudar, principalmente se a solicitação vier de um júnior (não questiono sua competência). Não vejo uma solução geral, pois não sei o suficiente sobre a situação.

— Mouviciel

0

Contanto que você não seja o novo gerente de sua equipe, você precisa de consenso sobre a existência de um padrão de codificação (e se você fosse o gerente, realmente deveria tentar obter consenso na equipe antes de tomar essa decisão "de cima" "). E pode parecer simples, mas apenas conversar - especialmente conversando com o quarto desenvolvedor - pode resolver isso.

— Doc Brown
fonte

0

Você tem uma empresa Wiki? Ou, na sua falta, um servidor no qual você pode soltar um?

Nesse caso, basta criar uma página. Chame de documento vivo. Coloque alguns padrões não controversos e incentive todos os demais a colaborar. Continue adicionando itens a cada poucas semanas, incentive a discussão, mas de uma maneira que diga "se ninguém discordar, devemos esperar que isso seja seguido". Se puder, convença todos a assinar os documentos de normas, para poder ver as alterações feitas por seus colegas.

Tente também fazer com que a equipe comece as revisões de código. Todo trabalho passa por dois desenvolvedores. Isso incentivará a discussão e a aplicação de padrões e fará com que todos sejam iguais, e não um desenvolvedor que dite as regras.

Edite em resposta ao comentário:

Você pode vender revisões de código como uma maneira de o Dev # 4 espalhar sua sabedoria. Mesmo quando seu código está sendo revisado, é uma oportunidade para as pessoas verem seu código mágico e se deleitarem com ele. Realmente, é uma maneira de promover a discussão. Nos casos em que o codificador e o revisor não concordam, deve ir para a equipe. Onde a equipe não concorda, a pesquisa deve ser feita.

Falando em pesquisa, faça algumas revisões de código. Ninguém cuja opinião conta muito pensa que é uma má ideia. Coloque isso na equipe, incluindo o CIO, em um email com muitos links. É difícil argumentar contra eles sem parecer um idiota obstrutivo.

Aqui estão alguns para você começar:

Quanto a um Wiki, eu realmente recomendaria reservar um tempo para configurá-lo (os Wikis dão a ilusão de colaboração, mesmo quando ela não está realmente lá). Mas se você não puder, um documento do Word em uma unidade compartilhada fará o trabalho.

— pdr
fonte

Nós não temos um; é algo que nós (sempre que digo "nós", eu me refiro a mim e aos dois desenvolvedores que me diferem - o quarto é essencialmente um "agente especial" e lida com as partes herdadas / complexas do aplicativo que o resto de nós não toca - mesmo antes de o gerente sair do Dev # 4, ele se reportou diretamente ao CIO, e não ao gerente). Revisões de código Não tenho certeza se podemos fazer isso, pois alguns podem se ofender se o código for questionado (mais do que provável Dev # 4, pois ele precisará mudar a maneira como faz as coisas para aderir aos novos padrões)

— Wayne Molina

@WayneM Onde trabalho, também não tínhamos um wiki. Foi fácil configurar um dokuwiki vm para começar. Você pode executar a coisa da sua caixa pessoal, se necessário, e depois que as coisas estiverem indo, é muito fácil migrar para um servidor "real".

— Spencer Rathbun

1

@WayneM: Veja a edição.

— Pd

0

Os padrões de comentários e espaços em branco são bons, juntamente com as ferramentas para migrar entre diferentes estilos. Eu uso guias no meu código python, que é considerado um estilo ruim. No entanto, uma função simples do VIM converte entre os dois, conforme necessário.

Além disso, pense nos níveis de compreensão do código. O objetivo de um estilo é comunicar informações ao programador que está lendo o código. Se você pode entender reduce(lambda x, y: x+y, map(lambda x: x + 1, theList)), mas seus colegas de trabalho preferem ver:

for pos,item in enumerate(theList):
    theList[pos] = item + 1
tmp = 0
for item in theList:
    tmp = tmp + item

Então isso é importante para ser resolvido. Mesmo com espaço em branco. Você precisa descobrir com que nível de compactação de código todos estão confortáveis.

Por fim, como são cortados os novos projetos e os projetos atuais? Uma classe por arquivo, as funções utilitárias seguem um esquema de nomenclatura, nenhuma variável global ou vazamento de escopo, arquivos de projeto aleatórios são ortogonais e pouco acoplados, e assim por diante. Isso fornece uma importante base de entendimento para todos. Não importa qual é o padrão de codificação, se todo projeto estiver tão entrelaçado que eu tenho que passar por toda a base de código e realmente fazer o grok do projeto antes de mexer foo().

— Spencer Rathbun
fonte