Como convencer os programadores a seguir as regras básicas

Existem várias regras que devo continuar pedindo aos programadores que sigam com muita frequência. Eles escrevem código e, se funcionar, o trabalho é feito apenas para eles. As regras mais básicas podem ser:

• Confirmando mudanças
• Não escrevendo problemas de modelo no modo de exibição ou controladores
• Evite codificação codificada

Você pode me contar sobre sua experiência? Como você gerencia isso?

Todos os profissionais do conhecimento precisam ser desafiados a realizar um trabalho de qualidade. A qualidade sofrerá se eles sentirem restrições arbitrárias de tempo impostas a eles. Por que não fazer coisas que são "suficientemente boas" quando todos estão preocupados em cumprir as especificações e cumprir os prazos?

Sua lista de reclamações é um sintoma de uma empresa que apenas recompensa o cumprimento de objetivos de curto prazo e não deseja enfatizar a alta qualidade. Você está administrando um hotel cinco estrelas ou uma parada de caminhões?

Para poder seguir as regras básicas, eles precisam saber quais são as regras e concordar com elas.

A maneira de lidar com isso é criar em conjunto um documento de diretrizes de codificação com o qual todos possam concordar. Não tente forçar isso com eles, pois isso sairá pela culatra.

Então junte a equipe e comece a trabalhar em uma definição comum de suas regras básicas!

Faça isso como um workshop onde todas as vozes são ouvidas. Timebox para evitar discussões sem fim. Você está tentando reunir várias mentes; portanto, convém preparar o palco com uma nota positiva de que todos devem ser respeitosos e manter a mente aberta (a escrita de código é pessoal ...).

Essas diretrizes devem estar ativas e alteradas sempre que a equipe achar que há algo que deve ser adicionado ou esclarecido.

Qual é o seu papel? Se você é apenas outro desenvolvedor com um interesse particularmente forte na qualidade do código, provavelmente não tem autoridade para fazê-lo ouvi-lo e talvez deva enviar essas idéias à gerência para estabelecer padrões de código que devem / devem ser seguido. Se você é um gerente / líder de equipe / arquiteto e tem alguma autoridade, você mesmo pode estabelecer essas práticas. Instale um documento de padrões e um processo de revisão de código para eliminar essas coisas.

Não será um interruptor mágico que você pode ligar; será um processo lento e nunca será 100%. Essa tem sido a minha experiência de qualquer maneira.

Ele precisa ser uma combinação sensata de todas as respostas até agora. No final, quando você está falando sobre um grupo de pessoas inteligentes (desenvolvedores), precisa dar a eles razões pelas quais o comportamento é importante e dar a eles controle suficiente sobre como esse comportamento é implementado, para que sejam investidos em fazê-lo da maneira certa. Os mandatos de cima geralmente são frouxos com pessoas inteligentes, porque se eles não concordaram que o problema é um problema, é provável que passem mais tempo trabalhando no cumprimento do mandato do que seguindo a regra.

Aqui estão algumas das minhas táticas:

Confirmando alterações:

Primeiro, a equipe precisa concordar sobre quando cometer e o que cometer. Absolutamente essencial é uma configuração de compilação que faça sentido, para que as pessoas não fiquem esperando apenas porque não sabem onde colocar alguma coisa. E um consenso sobre quando / com que frequência o check-in. "Não interrompa a construção" é uma boa regra óbvia, mas como isso é verificado e quem é informado sobre isso? Outra linha de base é "isso não será feito se não estiver registrado".

A maioria dos desenvolvedores que conheço tem o prazer de verificar o código IF:

• O processo de check-in é fácil
• O processo de sincronização é fácil (considerando as alterações de outros desenvolvedores)
• É fácil ver mudanças e mover-se entre versões

Uma coisa que notei recentemente foi que os check-ins se tornaram mais frequentes e menos dolorosos quando avançamos para uma nova ferramenta de CM. Nossa equipe é pioneira no Rational Team Concert, tendo usado anteriormente o Clearcase. Não pretendo anunciar ferramentas, mas a nova onda (para mim) de streaming de check-ins com muitas pequenas fusões rápidas torna muito mais atraente o check-in antecipado e frequente.

Permitir que os desenvolvedores sejam responsáveis ​​por eliminar a dor de CM geralmente aumenta a quantidade de check-in no que acontece.

Aderindo à arquitetura - Não gravando problemas de modelo em vistas e controladores

Estou colocando isso no grupo geral de "faça a arquitetura corretamente". Eu concordo com quem disse que as avaliações pelos pares - a pressão dos colegas é ótima para isso. Uma das maneiras pelas quais geralmente vejo as pessoas participarem das melhores práticas nessa área é quando seus colegas lhes perguntam por que o fizeram da outra maneira (da maneira não tão correta). Geralmente, a pergunta "por que" levará as pessoas a perceber por si mesmas por que deveriam ter feito isso de maneira diferente. Quando as pessoas têm um motivo bem entendido para a melhor prática, é muito mais fácil aderir a ela.

Além disso, se houver alguma formalidade em vincular uma pessoa a uma decisão, será mais fácil atribuir bugs nessa área ... portanto, se uma pessoa for responsável por corrigir bugs em uma área com design defeituoso, a necessidade de corrigir algo antes eles podem passar para algo novo e emocionante pode ser um grande motivador.

Evite codificação

Eu começaria com padrões claros de codificação e a integração de uma revisão de padrão de codificação nas revisões por pares. A codificação embutida é uma daquelas coisas que podem ser facilmente uma caixa de seleção na agenda de revisão por pares.

Receio que esse tipo de coisa seja a única coisa em que eu vi que se tornou o papel do líder da equipe para impor a regra. Nas equipes que eu administro, geralmente não deixamos alguém seguir em frente até que eles corrigam os comentários de uma revisão por pares de seu código. E "sem código rígido" é um comentário frequente de revisão por pares.

Em geral

Com quase todas as melhores práticas, acho que você deve escolher suas batalhas. Nenhuma equipe se tornará absolutamente perfeita. Mas você pode ficar de olho em seus principais pontos problemáticos e começar a enfrentá-los em grupos. Eu acho que se torna o papel do líder realmente saber o que é um ponto problemático para a equipe versus uma peculiaridade irritante de um indivíduo em particular.

Se sua equipe está perdendo uma prática recomendada específica, acho que a primeira pergunta deve ser "quanto dano isso está causando?" se a resposta for "mínima", provavelmente não vale a pena. Algumas práticas recomendadas são mais relevantes para tipos específicos de sistemas - embora sejam boas no geral, podem não valer a pena a batalha por sistemas em que a prática não é uma ocorrência frequente ou é uma parte importante do sistema.

Se a resposta para "quanto damange?" é "MUITO !!!", então você pode começar a criar um caso para mostrar à equipe que toda essa dor e sofrimento poderiam ser removidos, fixando esse ponto de folga nas melhores práticas. A maioria das pessoas fica feliz em evitar a dor e o sofrimento e isso muda o diálogo de "faça isso porque eu lhe disse", para um "decidimos fazer isso porque é melhor".

Revisão de código. Aceite apenas código bem escrito que não tenha erros.

Finalmente :

• Torne mais fácil para eles seguirem linhas de código (Ferramentas como reaharper, StyleCop). Se for fácil, é mais provável que elas adotem.

Além disso, escolha o que funciona com base na sua organização, nos desenvolvedores e na sua função na equipe.

• Deixe que eles façam correções de erros e solicitem alterações regularmente
• Emparelhe o programa com um desenvolvedor experiente
• Revisões de código de maneira construtiva
• Instruções passo a passo do código
• Comece o treinamento, use livros como o Code Complete e o programador pragmático.

Meu papel é gerente, mas como uma equipe pequena, desenvolvo e prefiro gerenciar como treinador.

Os eletrodos na cadeira conectada a um analisador de código já foram apontados, mas os programadores não parecem ter medo. Disparar não soa como uma boa abordagem, pois isso significa perder ativos dignos.

Vou dar uma olhada em todas essas ferramentas e permanecer aberto a qualquer outra que você me disser.

Existem três maneiras pelas quais abordamos esse problema:

1. Análise estática do código fonte para verificar se há problemas com a convenção de codificação. Use ferramentas como cppcheck e as da grammatech . A Wikipedia tem uma boa lista: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis . Normalmente, a maioria dos sistemas de controle de origem possui ganchos pelos quais você pode verificar esses problemas diretamente durante o check-in. Para ganchos CVS, consulte este link: http://goo.gl/F1gd2 . O não cumprimento significa uma falha no check-in e mais de três falhas significam que o desenvolvedor precisa se explicar para a equipe.

2. Durante o processo de codificação, ele próprio sinaliza problemas para o desenvolvedor. Ter scripts personalizados integrados ao IDE de sua escolha é uma maneira interessante de fazer isso. Confira este link: http://goo.gl/MM6c4

3. Siga os processos ágeis e verifique se a revisão de código faz parte do sprint

Aqui está o meu plano de três etapas:

1. Dispare os programadores
2. Contrate alguns engenheiros de software
3. ...
4. Lucro!

: D

Com toda a seriedade, se eles não acreditam em nada além de escrever código, você precisa de uma equipe mais completa. Uma programadora em que trabalhei usava diretórios diferentes no computador como seu CM. Nós brigamos com o programador por quase um ano (pois as mudanças introduziriam erros ao copiar e colar o código antigo). Acabamos de demiti-los.

1. Indique a eles quando violarem regras básicas.
2. Espere que eles produzam bugs que eles simplesmente não conseguem rastrear ou que sejam confrontados com solicitações de recursos que eles simplesmente não conseguem implementar devido ao seu código inflexível.
3. Lembre-os do que você havia dito anteriormente.
4. Deixe-os se afogar por um tempo.
5. Aproveite o tempo para refatorar o código em questão, isole os bugs / forneça infrasturcutre para conectar novas funcionalidades. Tire um tempo para explicar o que você fez.

Como alternativa, a coisa mais cruel, mas muito persuasiva a fazer é deixá-los manter uma base de código extremamente mal escrita, com um cronograma apertado. : D
E então, para variar, deixe-os manter uma base de código bem escrita, com um cronograma apertado.

Geralmente, a falta de vontade de adaptar certos padrões significa falta de experiência no trabalho em equipe.

No final, as pessoas apenas aprendem com os erros. NUNCA corrija problemas baseados na teimosia de outra pessoa. Se for realmente vital para o projeto (ou seja, sua empresa será processada se você não entregar dentro de N dias), coloque-os primeiro no projeto.

Eu acho que você programador não mudará sua atitude em relação a esses problemas que você mencionou até que eles percebam que essas coisas levarão a um benefício ou vantagem para eles. Tente explicar-lhes por que você quer que eles façam essas coisas. Melhor ainda, deixe-os experimentar as vantagens.

Contrate um engenheiro de software profissional. E então atire mais fraco. Em seguida, substitua lentamente aqueles que não podem adotar. Ter essas pessoas às vezes traz mais mal do que lucro a longo prazo.

A principal idéia aqui é que esse profissional começará a fazer a maioria dos trabalhos e demitir outros não reduzirá recursos humanos valiosos.

É um pouco nojento, mas deixei o Code Complete no banheiro por alguns meses. Não tenho certeza se foi eficaz, mas parecia uma boa ideia na época.

Então, quais são as consequências de não seguir as regras e recompensas por seguir as regras? Se a resposta for a mesma - nada - boa sorte em conseguir alguma tração. Sugiro uma abordagem em camadas. Primeiro, junte-os e discuta se eles concordam com as regras. O próximo passo é incluí-los nas revisões de código. Você também pode tentar cenouras e palitos. Algo como alguém que deixa um arquivo com check-out da noite para o dia deve trazer donuts para a próxima reunião semanal. Uma cenoura pode ser qualquer pessoa que segue as regras durante um mês inteiro e recebe um fim de semana em Las Vegas. Para dois.

Ou demitir o pior infrator e deixar o resto suar.

Faça com que eles sofram as conseqüências que você deseja evitar usando essas regras; é a única maneira que eles realmente entenderão o motivo de você estar perguntando, por exemplo: faça uma pequena bagunça controlada que eles precisam corrigir.

Se essa equipe está realmente tendo problemas para verificar as mudanças, aderindo à separação de preocupações e não codificando constantes mágicas, eu demitiria a equipe inteira e as substituiria por programadores reais ¹ que realmente se preocupam com o ofício o mais rápido possível. Seja um de cada vez ou em massa , não sei dizer, mas esses brincalhões precisam ir embora.

O tipo de codificação que você está descrevendo é adequado para scripts descartáveis ​​e de uso único. Não é assim que se constrói um aplicativo real. Se eles estão sendo pagos como programadores profissionais, o trabalho deles é conhecer esse tipo de coisa.

¹ Isso é frequentemente usado como um termo de brincadeira para pessoas imaginárias que escrevem seu código diretamente em binário ou algo igualmente ridículo. Aqui, eu não estou brincando. Sou um programador bastante novato e não precisaria receber essas informações porque me preocupo com o meu ofício. Esses não são programadores reais com os quais você está lidando.

O trabalho de um gerente não é ser amigo do empregado, às vezes você precisa ser o cara mau. A imposição de padrões e confirmações de codificação, a recusa em seguir a arquitetura proibida, a falha em usar as ferramentas prescritas etc. são os momentos em que você precisa ser impopular.

Expresse as políticas claramente. Faça revisões formais de código e verifique se as políticas são seguidas. Não permita que eles passem para outra tarefa até que todos os problemas da revisão de código sejam julgados.

Se a política se referir à não confirmação de código, isso solicitará um aviso por escrito se eles não puderem fazê-lo quando for solicitado. Se eles não estão enviando código, para você, eles não escreveram nenhum.

Se eles não melhorarem depois de ter uma chance razoável de melhorar, demiti-los. Desenvolvedores não profissionais são uma chatice para sua equipe, independentemente do tipo de código que eles escrevem. Estão afetando os outros com sua falta de profissionalismo e isso não deve ser tolerado. Eles não são boas pessoas para manter em qualquer caso. Bons desenvolvedores comprometem seu código, bons desenvolvedores seguem decisões de arquitetura mesmo que não concordem com eles e bons desenvolvedores não codificam. Você não estará perdendo nada, exceto dores de cabeça, se livrando dos codificadores de cowboys.