Como convencer os programadores a seguir as regras básicas


20

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?


2
Você deve perguntar em programmers.stackexchange.com. Você faz revisões de código? Você tem uma ferramenta de revisão de código como o Crisol? Eu recomendaria fazer revisões completas de código e insistir em que todos os problemas fossem resolvidos antes que qualquer outro trabalho fosse realizado.

15
Você pode tentar deixar a cabeça de cavalo na cama deles que funcionava no padrinho.
precisa

4
Eu tive grande sucesso com alta tensão. Sua milhagem pode variar.
Tim Post

2
@ Tim: um jornal enrolado é mais ecológico
Steven A. Lowe

@ Steven, acho que seria. Primeiro você redefine o jornal e depois o recicla. Suponho que exista uma arte para intimidar verde.
Tim Post

Respostas:


6

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?


1
+1 para apontar que essa é uma questão cultural e precisa ser tratada do ponto de vista da motivação.
Alex Feinman

é tanto questão cultural de uma empresa como aludido por Jeffo. mas às vezes essa cultura é elaborada de baixo para cima quando codificadores e desenvolvedores não têm visão para um código de qualidade ou para a necessidade dele. quando estavam na escola de Ciência da Computação, seus professores deviam ter dado um tapa na lateral da cabeça algumas vezes.
Robert Bristow-johnson

@ robertbristow-johnson - Bom ponto.
Jeffo

14

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.


2
Embora eu concorde, eu também discordo de "Não tente forçar isso com eles, ele sairá pela culatra se você o fizer". - Quando tudo estiver dito e feito, se alguém concorda ou não com as regras básicas é irrelevante. O chefe faz as regras, segue-as ou encontra outro emprego. Não somos tão especiais que a relação empregador-empregado não se aplique.
Steven Evers

12

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.


1
Aceita. Esta é uma questão política, não técnica.

E qualquer padrão de código teria que ser acordado pelo menos parcialmente pelo grupo. Ferramentas como o StyleCop ajudam bastante.
Job

Meu chefe está tentando empurrar sua "qualidade de código", mas simplesmente não decola, porque as pessoas não acreditam nela. ter poder nem sempre é a resposta.
IAdapter

@ 0101 Muito verdade. O poder ajuda a transmitir a mensagem. A mensagem deve ser criada para ser aceita e seguida.
RationalGeek

7

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".


Comentário longo, mas sua abordagem é incrível. Para levar as pessoas a seguir essas diretrizes, elas precisam acreditar que é um benefício. Gostaria de ouvir alguns exemplos de como isso funcionou para sua equipe.
precisa saber é o seguinte

Meu exemplo favorito é a configuração consistente do ambiente de teste. Eu não tive que impor o caminho certo. Eu tinha um cara encarregado do documento de instalação. Eu disse - "é tudo o que você pode fazer para criar um mecanismo de instalação que garanta uma instalação consistente - todos têm o poder de incomodá-lo se a instalação estiver com problemas". Em menos de um mês, tínhamos uma ferramenta sólida e um documento muito curto. E a ferramenta foi instalada como atalho em todas as áreas de trabalho. Eu não precisava de fiscalização, a instalação adequada já era o caminho de menor resistência. Agora, nosso objetivo é remover o atalho, tornando-o automatizado.
bethlakshmi

6

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


3
Essa não é uma solução para o problema subjacente. Não perca tempo com revisões de código, quando você pode corrigir o problema de causa raiz.
Martin Wickman

Se você pode forçá-los a refazer as coisas uma e outra vez, a preguiça inerente fará com que elas comecem a se conformar com o tempo.
David Thornley

Concordado, as pessoas só precisam ser responsáveis ​​e fazer seu trabalho sem serem informadas. A revisão de código após cada alteração é uma enorme perda de tempo.
precisa saber é o seguinte

5

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.

5

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.


3
Se seus ativos são tão valiosos, talvez esses problemas não sejam tão importantes? Você tem que escolher suas batalhas algumas vezes.
JeffO

A minha pergunta é sobre como melhorar o que eu tenho, que é mais difícil, mas eficaz do que a busca e substituir
Llistes Sugra

Demitir pessoas que não seguem as regras de codificação NÃO está perdendo bons ativos, está se livrando da madeira morta.
HLGEM

@HLGEM - A menos que a pessoa que não segue as regras seja um ninja de código que possa resolver qualquer problema na organização. O Dr. House não segue as regras, mas se o hospital o demitisse, haveria muita gente de ficção que morreria. en.wikipedia.org/wiki/Gregory_House
jmort253

4

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


1
+1, eu tenho commit de ganchos que executam tudo o que foi modificado através do splint (e vários outros fiapos), além de ferramentas para garantir que eu não esteja incluindo cabeçalhos desnecessariamente, além de garantir que o recuo seja tabulação, não espaço, etc.
Tim Publicação

As soluções técnicas não ajudarão se os desenvolvedores não forem obrigados a usá-las.
Robert Harvey

2

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.


2
  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 amo isto. Ótima receita para fazer alguém te odiar. ;)
Roman Zenka

@ Roman Zenka: Possivelmente sim. Mas se a escolha é entre ser odiado e frustrado, porque você está tendo um NNPP na equipe, eu prefiro a primeira opção;)
back2dos

Nesse ponto, eles precisam ser retirados da folha de pagamento.
JeffO

Eu realmente trabalhei nisso! E eles não me odeiam. A conclusão é que todo mundo é confortável em sua própria merda. E isso torna essa tarefa tão difícil.
Llistes Sugra

1

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.


1

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.


1
Essa é uma ótima maneira de compensar a falta de habilidades de liderança e capacidade de orientar indivíduos menos experientes. Se suas habilidades de persuasão forem ruins, comece a demitir todas as pessoas que discordam de você.
precisa saber é o seguinte

@ jmort253, Se eu tiver uma chance, eu dispararia todos os programadores que não estão comprometidos com o controle de versão regularmente. Das palavras dos autores, entendo que TODOS os programadores são inexperientes e não querem aprender e melhorar a si mesmos.
Konstantin Petrukhnov

1

É 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.


0

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.


Eeep! Você tem um tipo de VCS com checkout único? Fique com o século, cara!
David Thornley

0

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.


0

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 1 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.


1 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.


Eu concordo com tudo, exceto a parte de disparo. Boa sorte em descartar todas as outras tarefas críticas nas quais você está trabalhando como gerente, incluindo o cumprimento de prazos e marcos do cliente, para substituir toda a sua equipe experiente por pessoas que podem comentar o código, mas que não possuem conhecimento de domínio.
precisa saber é o seguinte

0

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.