Qual a importância de limpar o código de outra pessoa diante de um prazo apertado? [fechadas]


38

(Estou falando de código HTML / CSS (não de linguagens de programação), mas acho que também enfrentamos o mesmo problema que os programadores.

Sou o designer sênior de front-end de uma equipe e muitas vezes tenho que refazer a produção dos meus juniores em prazos apertados.

Estou com 2 problemas:

  1. Seu estilo de codificação é um pouco confuso.
  2. A estética não é boa.

Seu estilo de codificação, eu acho, é um saco misto sem nenhuma convenção / padrão adequado. Estou dividido entre limpar o código ou apenas lidar com o código (até mesmo copiar como eles fazem as coisas).

Acho frustrante seguir o estilo de codificação deles, pois sinto que posso aprender maus hábitos. Mas então, essa é a maneira mais rápida de cumprir o prazo.

Para aqueles com muito mais experiência, qual é mais eficaz? Devo salvar a limpeza para mais tarde? Ou limpar ao longo do caminho enquanto faço as alterações?

(Não quero parecer arrogante, mas essa é a realidade. Levará mais anos para escrever um código melhor. Sei que escrevi um código bagunçado quando estava iniciando.)


1
Se você tiver a opção, consulte os produtos JetBrains (Re-Sharper para C #, IntelliJ para Java e até mesmo algumas linguagens 'dinâmicas') que podem fazer alterações idiomáticas em todo o projeto em toda a solução, com pouco investimento de tempo. (Ele também pode ser usado para ensinar interativamente aos juniores o que é idomatic. Mas verifique se você e eles concordam com as mesmas configurações do projeto. (E certifique-se de fazer todas essas coisas em um commit separado, para não misturar alterações substantivas e cosméticos na mesma commit),
David Bullock


2
Implementar um guia de estilo / minimanual? Quero dizer, eles não escreverão um código melhor , mas todo mundo é capaz de seguir diretrizes que exigem escrever coisas triviais de uma única maneira específica.
31413 Peteris

10
Já vejo você tendo um problema com a falta de trabalho em equipe aqui. Você deve educar e nutrir o jovem; não apenas reescrevendo seu código e reclamando.
James

3
@ Ramhound desde Turing inventou a Máquina de Turing, eu acho. Mas voltando ao ponto, se você é o mais velho que deve fazer os juniores ouvirem você. Ensine-os a fazer o caminho certo (ou por convicção). Mas é importante pedir sua opinião e talvez eles tenham algumas idéias de como fazer as coisas de uma maneira melhor. Além disso, se você estiver usando CSS bruto para qualquer projeto não trivial, está fazendo algo errado, tente fazer com que seu projeto adote LESS ou SASS.
Hoffmann

Respostas:


79

Acredito que você esteja encarando o problema da maneira errada - está perdendo uma grande oportunidade de ensinar aos juniores como escrever um código melhor.

Se você reescrever habitualmente o código deles, poderá dar aos juniores a impressão de que não valoriza o trabalho deles, o que diminuirá o moral deles e não os ajudará a codificar melhor da próxima vez.

Uma abordagem melhor, acredito, é adicionar ao processo de desenvolvimento de sua equipe uma tarefa de revisão de código. Ele não precisa ser sobre todos os trechos de código confirmado e não (eu diria que não deveria) ter que ser conduzido apenas por você - sempre que um membro de sua equipe concluir uma tarefa suficientemente grande, ele deve emparelhe com um (ou mais) companheiros de equipe, explique o código para eles e receba opiniões e críticas construtivas sobre seu design, estilo de codificação, possíveis erros e problemas de segurança etc.

Quando o colega de equipe de revisão de código é você, eles aprendem muito mais com sua experiência do que quando você simplesmente reescreve o código deles (eles têm a chance de ouvir o motivo pelo qual o código deve ser alterado) e podem se sentir menos ofendidos.

Dar a eles a chance de também realizar revisões de código aprimorará ainda mais suas habilidades - vendo como outras pessoas escrevem código e por quê - e aumentará sua auto-estima.

Eles também aprenderão muito se você lhes der a chance de revisar seu código. Você pode aprender algo também - então não faça isso apenas para mostrar!


Eu concordo 100% com você, no entanto, gostaria de saber como aplicar isso na presença de prazos apertados. Você sugere fazer revisões de código, mesmo que possam consumir mais do nosso precioso tempo limitado (tanto no processo de revisão quanto nas correções feitas após a revisão)?
Phil

3
Eu não acho que um membro da equipe deva alterar o trabalho de outro membro da equipe sem sua cooperação / consentimento. A pessoa que escreveu o código deve ser responsável por ele e, a menos que o código contenha um erro crítico e o gravador original não esteja disponível, estar com uma agenda apertada não é motivo para alterar o código de outra pessoa. Se você achar o código muito confuso - comunique-o ao desenvolvedor e peça para ele limpá-lo para a próxima versão.
Uri Agassi

23
@ Phil Ao calcular um prazo, deve-se levar em consideração o tempo para as sessões de revisão de código. Não é uma etapa extra no topo do processo de desenvolvimento - é parte integrante do processo de desenvolvimento.
dj18

2
Além disso, o treinamento de juniores por meio de revisão de código pode ter uma certa quantidade de tempo agora (que, como diz o dj18, deve ser levada em consideração nos prazos e nas estimativas de qualquer maneira), mas será reembolsada no devido tempo muitas vezes, pois isso o libera. trabalho mais original. Se os seus prazos são tão apertado que você não tem a chance de fazer isso, cheira em vez de uma espiral da morte ...
Julia Hayward

2
@ JustinPaulson não me interpretem mal - o fato de alguém ter escrito algum código não o torna "dele". Uma semana depois, algum outro membro da equipe receberá uma tarefa que exigirá que ela modifique esse código, e ela definitivamente deve alterar o código para suas necessidades. No entanto, não vejo um caso de uso em que alguém deva "limpar" o código de outra pessoa para limpar, especialmente não como algo de última hora em um prazo apertado.
Uri Agassi

29

Eu já disse isso antes e direi novamente "o código de trabalho é mais valioso do que o bonito".

Se você alterar o código, são grandes as chances de alterar seu comportamento; se esse for o código testado, você acabou de invalidar todo o esforço de teste e precisará repetir os testes.

Por todos os meios, incentive seus alunos a escrever um código compreensível e limpo, mas se você quiser reescrever tudo o que eles escrevem, estará desperdiçando dinheiro de seus empregadores várias vezes. Eles precisam pagar pelos seus juniores, depois pagar por você para fazer o que eles já pagaram para seus juniores e depois pagar novamente por você para fazer o trabalho pelo qual realmente o contrataram.


11
"se este é um código testado, você acaba de invalidar todo o esforço de teste e precisará repetir os testes." Não, você não invalidou nenhum esforço de teste. Você apenas precisará executar novamente os testes, o que você deve fazer para cada confirmação de qualquer maneira. Se isso demorar tanto que seja considerado inviável, os testes são ruins e devem ser corrigidos.
L0b0

7
Deve-se notar que escrever continuamente códigos desleixados para "fazê-lo funcionar" levará a uma grande bola de barro . Tudo bem se for uma exceção, e não a regra. Se isso se tornar uma regra, você deve conversar com seu chefe que prazos não são a única coisa a considerar.
21414 Neil

20
O problema é que código feio se transforma rapidamente em código quebrado.
Telastyn

1
@ramhound - claro, mas o OP (e quase todo mundo) não está falando de código que simplesmente usa padrões antigos - eles estão falando de código desajeitado, inconsistente e de má qualidade.
Telastyn 17/03/14

1
@ JamesAnderson Essa é uma perspectiva extremamente míope. O código é escrito uma vez, mas é mantido por toda a vida útil do produto. A maioria dos códigos é refatoração. Quanto tempo você está realmente escrevendo o código em uma tela em branco antes de ajustá-lo e ver se ele é executado conforme o esperado? Portanto, você está refatorando, mesmo na primeira hora após iniciar uma nova aula. O custo da refatoração de código feio nas correções e aprimoramentos subseqüentes superará o custo de um pouco de tempo gasto com revisões de código e levará a equipe a um padrão claro.
22814 Scott Shipp

16
  • A resposta curta é não. Quando os tempos estão difíceis, às vezes você apenas tem que abaixar a cabeça e levar a bala estética. ;)

  • Uma resposta mais pragmática é cronometrar. Faça um orçamento de uma hora para analisar e limpar um aspecto específico do código. Depois faça o check-in e faça um trabalho real. Mas seja honesto consigo mesmo sobre mantê-lo restrito.

  • Às vezes, porém, um pouco de limpeza torna o trabalho mais rápido. Mesmo algumas alterações rápidas do tipo pesquisar e substituir tornam tudo muito mais acessível.

  • Desconfie de guerras de estilo. Especialmente em uma situação de prazo apertado, se você deseja desfazer algumas preferências estilísticas que o outro programador refaz, então é melhor esperar até ter tempo para realmente descobrir como deseja abordar essas questões. questões estilísticas cooperativamente. (O que significa que alguns dão e recebem.)

Mas há um valor de julgamento na resposta. Eu diria "moderadamente" importante. O código limpo pode realmente acelerar o trabalho e a qualidade do código é, afinal, parte da entrega. Acho que não consigo tocar no código (nem mesmo no meu) sem gastar algum tempo na limpeza. Mas certifique-se de que mexer com estilo e formato e guerras de estilo não se torne mais importante do que colocar o código em produção.


9

Ao fixar código e com prazo, normalmente utilizo duas regras:

O código é péssimo, mas é possível encontrar um problema em tempo razoável e corrigi-lo

Corrijo um problema e deixo o resto intacto .

O código é tão confuso que é realmente difícil encontrar um problema lá. Consertar algo causa quebras imediatamente outra coisa. Provavelmente seria mais rápido escrever esse código do zero do que corrigi-lo.

Então não tenho outra opção senão reescrever / refatorar até que o código esteja limpo o suficiente para localizar e corrigir o erro.

O caso limítrofe é:

O código é confuso e muito ruim. Ainda é possível corrigir um bug em um tempo razoável, mas a estrutura do código dificulta a manutenção. É provável que qualquer novo recurso introduza novos bugs ou cause uma diminuição significativa no desempenho.

Nesse caso, o código deve ser corrigido, mas somente quando novos recursos forem implementados, durante o tempo ocioso, nunca no tempo de correção de bugs, antes do prazo final!


O problema com o "caso limítrofe" é que outros módulos tendem a surgir que fazem uso desse código. Torna-se muito arriscado mudar, pois outros módulos podem agora contar com um comportamento "incorreto / indesejável". Então você acaba preso a um código que é realmente difícil de manter que o faz se encolher cada vez que o vê e que deseja ir a outro lugar em busca de emprego. No mínimo, o código incorreto precisa ser protegido por alguém que sabe o que está fazendo. Dessa forma, ele pode ser corrigido posteriormente, sem incorrer em tantos riscos quanto deixá-lo até que alguém tenha tempo para contornar o problema.
Dunk

6

Gostaria de saber em que momento do seu processo você está encontrando esse problema?

Estritamente falando, neste mundo ideal mágico que nenhum de nós habita, todo código promovido ou implantado deve ser perfeito. Às vezes não é preciso ser pragmático.

No entanto, se você tiver um processo de revisão de código, ele deve ser destacado antes do teste. Se você está constantemente cumprindo prazos, os problemas são estimados para entrega, o que significa que um componente-chave de qualquer processo de desenvolvimento - isto é, revisão de código - está sendo estrangulado?

Seus juniores nunca aprenderão a relaxar e absorver melhores maneiras de fazer as coisas, se você não reservar um tempo para fazer parte do processo de desenvolvimento deles. Parece-me que você não está fazendo isso.


4

Depende da cultura geral. Se prazos apertados forem esporádicos, aceite que você terá que fazer a limpeza mais tarde. Se eles são constantes, você está construindo estruturalmente uma dívida técnica e deve resolver o problema com a gerência. Se eles não abordarem suas preocupações, é melhor começar a procurar outras oportunidades de emprego, pois a cultura da empresa provavelmente se encontrará com os princípios darwinistas em breve.


3

Para ajudar a conter o problema no futuro, desenvolva um documento interno de Normas e Práticas de Codificação que todos os funcionários devem seguir.

Para o lote atual, limpe o código de acordo com o documento S&P ao refatorar o código, mas somente quando você refatorar.


Eu trabalhei para algumas empresas grandes e muito orientadas ao processo que estavam dispostas a gastar milhares de dólares em dinheiro para garantir que os padrões e práticas de codificação fossem atendidos. Eles nunca existiram até que as ferramentas automatizadas começaram a aplicá-las.
Dunk

@ Dunk As forças armadas dos EUA contam como "grandes e orientadas para o processo"? Eles usam S & Ps o tempo todo: stroustrup.com/JSF-AV-rules.pdf
Casey

Eles certamente contam como o padrão-ouro para padrões e práticas de codificação. Todo contrato exige isso. No entanto, por mais que as empresas tentem aderir a seus padrões e práticas, isso não acontece de maneira confiável e consistente. Há muita coisa acontecendo. É por isso que ferramentas automatizadas são necessárias se você deseja incluir a palavra "must" em sua sugestão, como fez. O DOD reconheceu a impossibilidade de aderir aos padrões por meios manuais e é por isso que o congresso aprovou uma lei em 2011 exigindo que os contratados de defesa comecem a usar ferramentas automatizadas para realizar essas verificações.
Dunk

Aliás, não estou dizendo que não há necessidade de padrões e práticas de codificação. É absolutamente necessário. Eu apenas tenho uma contenda com a parte "todos os funcionários devem seguir", a menos que você também mencione algo sobre impor isso por meio de ferramentas automatizadas.
Dunk

Equipe @Dunk O JSF-AV deve ter reconhecido isso, o documento menciona especificamente o uso de ferramentas automatizadas, como forma de fazer cumprir a S & Ps (em 2005)
Casey

2

Sou bastante inexperiente em programação. Como estudante, no entanto, muitas vezes me comprometo com a revisão por pares e parcerias em projetos. Se houver tempo suficiente para concluir um projeto, irei limpar o código de um membro da equipe para maior clareza e legibilidade. Muitas vezes, acho difícil peneirar as primeiras 100 linhas. Nesses casos, estou mais do que disposto a estender a mão para ajudar a ensinar a um colega programador melhores hábitos e códigos. Se não houver tempo suficiente, simplesmente copio / colo e trabalho meus projetos no cenário geral, lidando com suas interfaces ruins. Depois, tenho certeza de oferecer muitos conselhos sobre a técnica de codificação. Quando se trata de revisão por pares, as críticas construtivas (independentemente de quão indesejáveis) apenas beneficiam a mim e a ele a longo prazo.

No geral, se você tiver tempo de sobra, ensine seus recém-chegados a conduzir seu trabalho para que todos sejam benéficos. Reserve um minuto e ensine a eles o que funcionou para você e o que não funcionou. Se você não tiver tempo, deixe o trabalho deles por enquanto e não se esqueça de voltar para eles quando tiver chance. Diga a eles que existem maneiras melhores de fazer as coisas, principalmente se você trabalhar com elas no futuro.


2

Melhorar a qualidade geral é muito superior ao uso de uma única pessoa como um "filtro" para um grupo maior. Nessa nota:

  • A programação em pares funciona como uma versão aprimorada da revisão de código para entender como desenvolver - é como a diferença entre ler e fazer, contar e mostrar. Observar o código evoluir e discutir rapidamente as mudanças é imensamente útil para entender não apenas o como, mas o porquê da refatoração e do bom código. Na minha experiência, é mais rápido do que desenvolver sozinho, uma vez que as idéias são lançadas continuamente, terminando com um resultado geral de qualidade superior e melhor compreensão do código e do pensamento da outra pessoa.
  • As ferramentas de fiapos podem verificar se o estilo de codificação está sendo seguido. Isso ensina a todos como formatar o código, e os erros devem cair rapidamente assim que os desenvolvedores se lembrarem do padrão.
    • Faça parte do processo de construção para garantir que seja corrigido antes de confirmar.
    • Use modelos de linguagem para garantir que seu CSS, HTML, JavaScript e código do servidor possam ser verificados separadamente.
  • As ferramentas de validação podem verificar se a saída gerada é sã. Isso também deve fazer parte do processo de compilação.

2

A melhor prática seria ter um guia de estilo de codificação e revisões regulares, para que, quando você se aproxima de um prazo, não se depare com esse problema.

Minha recomendação é que você mostre liderança e encabeça a revisão regular do código. O gerenciamento não é empurrado de cima para garantir que as revisões regulares de código ocorram, mas minha experiência é que elas ficarão impressionadas quando um programador se preparar para agendar e realizar revisões regulares de código.

Existem muitos benefícios para o seu pessoal, que irá:

  • aprenda melhor estilo
  • siga melhores práticas
  • aprender a pesquisar o que estão fazendo

E alguns benefícios para você, você será:

  • mais eficiente durante depurações de última hora (o que sempre acontece)
  • reconhecido como especialista e líder por sua equipe e gerência

1
O problema com os guias de estilo de codificação é que eles tendem a se transformar em livros. A maioria das pessoas está disposta a aprender e seguir um conjunto de regras bastante modesto. Infelizmente, em algum momento esses guias sempre crescem além da capacidade das pessoas de aprender e lembrar de todas as regras. Você precisa de uma ferramenta que faça verificações de estilo automaticamente, ponto final. As revisões de código não devem ser para a verificação gramatical, devem ser para encontrar erros e mal-entendidos.
Dunk

Como programador do Python e líder de revisão de código, imprimi o PEP 8 e o guia Python Style do Google pelo menos uma dúzia de vezes para serem distribuídos. O que quer que os programadores não aprendam com eles, ficará atrás daqueles que o fazem. Dito isso, concordo que um verificador de estilo também é uma boa prática, se você puder implementá-lo.
Aaron Hall

Eu não uso o Python, por isso não conheço as ferramentas disponíveis, mas se você está confiando nas revisões de código para aplicar suas regras de estilo, está desperdiçando centenas (se não milhares) de horas por ano para algo que você pode ser feito por você, basicamente, sem custo de tempo. Eu certamente não iria adiante e implementaria uma versão caseira. Eu gastaria o dinheiro para comprar uma versão comercial que será MUITO MELHOR do que qualquer coisa que possa ser construída em casa em pouco tempo. Até as ferramentas caras se pagam muitas vezes.
Dunk

O Python, sendo a cornucópia de código aberto que é, possui todos os tipos de ferramentas gratuitas (pylint, pep8, pyflakes), algumas das quais combinamos e melhoramos, que, desde que temos milhares de desenvolvedores, são realmente dimensionadas.
Aaron Hall

1
: Eu estava me referindo ao seu snippet "se você pode implementá-lo". Se você pudesse comprar um verificador de estilos, esse é o caminho a seguir. Se sua equipe pode implementar algo tão útil quanto isso em um tempo razoável, é necessário que haja uma empresa / código aberto que já tenha feito isso. Portanto, seria muito mais econômico simplesmente comprá-lo. Tenho certeza de que seria melhor e mais atualizado do que uma versão doméstica "não produtiva". Se você possui milhares de desenvolvedores, subestimei bastante a quantidade de economia que uma ferramenta automatizada de verificação de estilo / segurança proporcionaria.
Dunk

2

Eu posso ver o motivo nas respostas "não conserte o que está funcionando" e "não perca seu tempo com o que não é importante para o cliente". Os PMs estão preocupados com os riscos e isso é bom.

Também entendo que a maioria das pessoas não aceita esse tipo de correção. Eu também entendo isso.

Dito isso, acredito que a maioria dos prazos é artificial. Os sistemas reais vivem cada vez mais do que os prazos e o mau design que você faz hoje o ajudará para sempre e sempre. As pessoas correm para entregar algo em alguns meses e passam anos depois disso corrigindo algumas decisões ruins em um código que está sendo executado na produção.

Dívida tecnológica é a palavra. Um dia voltará e alguém pagará por isso.

Então, na IMO, acho que você está certo em corrigir o design quebrado e ser profissional (especialmente para os juniores) também significa que você deve saber como receber críticas e aprender com elas, mesmo que não seja educado. De fato, a maior parte da vida não é educada.


0

Qualquer resposta direta será extrema. Claramente, há casos em que o prazo é tão apertado que você deve usar código feio e há casos em que o código é tão feio que vale a pena perder o prazo para melhorá-lo. O que você precisa é de métodos para julgar em que você está, e talvez métodos para definir prazos realistas que permitam tempo para escrever um código melhor.

Não salve a limpeza para mais tarde. A menos que você habitualmente tenha períodos sem nada a fazer além de refatorar, não há "mais tarde" em que, de alguma forma, se torne mais prioritário arrumar o código do que é agora. A rotina é "vermelho, verde, refatorar", não "vermelho, verde, fazer algo completamente diferente por duas semanas, refatorar". Realisticamente, você não mudará o código até a próxima vez que o revisar por algum outro motivo, e provavelmente também estará dentro de um prazo. Suas opções reais são para corrigi-lo agora ou deixá-lo.

É claro que o código com estilo é melhor que o código com estilo incorreto, supondo que você planeje lê-lo novamente. Se você planeja nunca mais lê-lo novamente, não o arrume . Envie a primeira coisa que passa nos testes. Mas esse é um cenário bastante raro, para a maioria dos programadores isso acontece quase nunca. Ignorando esse caso, somente você tem os detalhes do seu caso real para avaliar quanto custa para consertar versus quanto custa (em manutenção futura aumentada) para não consertá-lo.

Há certas coisas que não são mais difíceis de corrigir no momento em que o código requer manutenção, do que devem ser corrigidas agora. Na verdade, isso não beneficia muito você a corrigir agora. Os mais óbvios são triviais para corrigir (erros de espaço em branco e similares) e, portanto, é difícil imaginar que você tenha tempo para fazer esta pergunta, mas não para corrigi-la ;-) Para aqueles que não são triviais e são desse tipo, então OK , você tem um código que não é ideal, mas deve ser pragmático. Funciona e você está dentro de um prazo. Use-o.

Há certas coisas que são consideravelmente mais fáceis de corrigir agora do que serão mais tarde quando (a) não estiverem tão frescas na mente de todos; (b) outras coisas foram escritas que dependem ou imitam. Eles são muito mais valiosos para corrigir agora, portanto, priorize-os. Se você não tiver tempo nos prazos para corrigi-los, precisará pressionar o máximo possível por prazos mais longos, porque está criando dívidas em sua base de código que provavelmente terá que pagar na próxima visita o código.

O método preferido de correção de código é através de um processo de revisão. Comente os problemas que você tem com ele e envie-o de volta ao júnior para mudar . Você pode dar exemplos do que você quer dizer e deixar o junior para encontrar todos os casos no código ao qual eles se aplicam, mas não basta terminar o código para eles. Se o fizer, não lhes dará meios para melhorar.

Você deve escrever problemas comuns em um guia de estilo que diga "não faça isso, faça isso" e explique o porquê. Em última análise, é permitido que o motivo seja "para tornar nosso código esteticamente consistente", mas se você não estiver preparado para escrever suas regras com alguma justificativa, provavelmente não deverá aplicá-las. Apenas deixe cada programador livre para escolher.

Por fim, cuidado com a tendência de ajustar as coisas indefinidamente. Os retornos diminuem e você precisa aprender com a experiência em que eles ainda são bons. É absolutamente essencial que você forme uma idéia realista do que é bom o suficiente, ou então não poderá ter essa negociação na qual se assegura de que seus prazos lhe dêem tempo para criar código "suficientemente bom". Gaste seu tempo com coisas que não são boas o suficiente.


0

Como muitos disseram antes, tudo o que você joga no ar sempre volta. Eu acredito em forte uniformidade em uma base de código. É claro que algumas coisas realmente não importam muito. Convenções de nomenclatura em variáveis ​​locais dentro de um procedimento, por exemplo. No entanto, para qualquer coisa estrutural, ela deve ser corrigida imediatamente, antes da mesclagem final no tronco principal. Pode ser um pouco ruim quando você olha para o procedimento ou classe individual, mas se todo mundo cometer código "levemente feio", ele realmente se tornará realmente feio como um todo.

Código feio que funciona geralmente funciona bem 90% das vezes, mas desmorona nas bordas. Certificar-se de que não é geralmente simples o suficiente, seguindo apenas algumas regras simples. Primeiro, deve ser obrigatório para todo programador definir e documentar restrições exatas para cada procedimento ou bloco funcional que produzem.

Segundo, para todo procedimento, deve haver um teste contra essas restrições. Esse deve ser um teste de unidade simples que o programador pode (e precisa) executar localmente contra seu procedimento antes de confirmar. Obviamente, isso é mais fácil de gerenciar com um conjunto de testes adequado, mas mesmo sem um teste deve ser gravado e possivelmente confirmado em uma classe parcial que pode ser excluída da compilação.

Em terceiro lugar, um conjunto de ambientes de desenvolvimento padronizados com ferramentas pré-configuradas é inestimável. Um servidor TS é excelente para isso. Todo mundo tem as mesmas ferramentas exatas (e versões), as mesmas configurações e as mesmas atualizações. Instale uma ferramenta de refatoração como CodeRush ou Resharper, pré-configurada para seus padrões e instrua os programadores a rejeitar quaisquer confirmações que ainda tenham avisos. Agora você pode usar o tempo de revisão de código de sua equipe para realmente melhorar o conjunto de regras com base nos comentários deles, e sua equipe se corrige felizmente sem que você precise limpar constantemente posteriormente. Também é muito mais fácil para um programador receber críticas de código de uma ferramenta adequadamente configurada do que de um colega ou chefe, onde os padrões podem parecer arbitrariamente definidos ou não serem entendidos adequadamente. Se o IDE informar que seu código é de má qualidade, ninguém discutirá com isso e será corrigido. Você descobrirá que a qualidade do código aumentará drasticamente e a equipe como um todo gastará MUITO menos tempo refatorando e limpando após algumas semanas. Os programadores também se acostumarão com as regras e deixarão de escrever códigos de porcaria.

Por fim, a solução simples aqui é simplesmente incentivar os programadores a melhorar. Programadores são por definição competitivos. Todo mundo quer ter o código mais bonito ou mais rápido. Uma boa maneira de motivar todos, melhorar a produtividade e erradicar o incompetente é calcular um quadro de pontuação semanal ponderado para todos, obtendo pontos por comprometimentos rejeitados e prazos quebrados, por exemplo. Mostre o N superior na reunião semanal da equipe, talvez até almoce para quem é o primeiro na média do mês.


0

Eu sugiro usar uma ferramenta de revisão. Se você possui um repositório baseado em Git, pode usar a ferramenta de revisão Gerrit . Após algumas confirmações rejeitadas, a equipe aprenderá os padrões que você deseja seguir e as confirmações futuras não exigirão nenhum trabalho adicional de você.

As confirmações aguardam a sua aceitação. Se vir alguma linha que deva ser reescrita, você pode escrever comentários e seus colegas de equipe podem corrigir o código por conta própria, com base em seus requisitos. É realmente uma boa maneira de aprender os padrões de codificação dos membros da equipe .

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.