Quão importante é limpar o código de outra pessoa quando se depara com um prazo apertado? [fechadas]

Eu acredito que você está olhando para o problema da maneira errada - você está perdendo uma grande oportunidade de ensinar os juniores a escrever um código melhor.

Se você costuma reescrever o código deles, pode dar aos seus juniores a impressão de que você não valoriza o trabalho deles, o que abaixa sua moral e não os ajuda 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. Não tem que ser sobre cada código comprometido, e não (eu diria que não deveria) ter que ser conduzido apenas por você - sempre que um membro de sua equipe termina uma tarefa grande o suficiente ele deveria emparelhar com um (ou mais) de seus companheiros de equipe, explicar o código para eles e receber opinião e críticas construtivas sobre seu design, estilo de codificação, possíveis bugs e problemas de segurança, etc.

Quando o companheiro de equipe de revisão de código é você, eles aprenderão muito mais com sua experiência do que quando simplesmente reescrevem o código (eles têm a chance de ouvir o motivo em que o código deve ser alterado) e pode ser menos ofensivo.

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

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

Eu já disse isso antes e vou dizer de novo "código de trabalho é mais valioso do que código bonito".

Se você alterar o código, as chances são altas de que você alterará seu comportamento. Se esse código for testado, você invalidará todos os esforços de teste e precisará repetir os testes.

Por todos os meios, incentive seus juniores a escrever um código claro e compreensível, mas se você for reescrever tudo o que eles escrevem, então você estará desperdiçando o dinheiro de seus empregadores várias vezes. Eles têm que pagar pelos seus juniores, depois pagar para você fazer o que eles já pagaram aos seus juniores, e depois pagar por você mais uma vez para fazer o trabalho que eles realmente o contrataram.

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

• Uma resposta mais pragmática é registrá-la no tempo. Reserve uma hora para percorrer e limpar um aspecto específico do código. Em seguida, verifique e faça algum trabalho real. Mas seja honesto consigo mesmo sobre manter isso restrito.

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

• Desconfie de guerras de estilo. Especialmente em uma situação de prazo apertado, se você vai desfazer algumas preferências estilísticas que o outro programador irá refazer, então é melhor esperar até que você tenha tempo para realmente resolver como você quer lidar com essas questões estilísticas de forma cooperativa. (O que significa alguns dar e receber).

Mas há um valor de julgamento na resposta. Eu diria "moderadamente" importante. Código limpo realmente pode tornar o trabalho mais rápido, e a qualidade do código é, afinal, parte do produto final. Eu não acho que posso tocar código (mesmo o meu) sem gastar algum tempo em limpeza. Mas certifique-se de que se preocupar com estilo e formato e guerras de estilo não se torne mais importante do que colocar o código em produção.

Ao corrigir o código e ter um prazo final, uso normalmente duas regras:

The code is awful but it's possible to find an issue in reasonable time and fix it

Eu corrijo um problema e deixo o restante intacto .

The code is so messy that it's really hard to find an issue there. Fixing something causes breaks immediately something else. It would be probably faster to write that code from scratch than fixing it.

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

O caso borderline é:

The code is messy and really bad. It's still possible to fix a bug in reasonable time, but the code structure will make it really hard to maintain. Any new feature is very likely to introduce new bugs or cause significant performance decrease.

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

Eu estaria interessado em saber em que ponto do seu processo você está encontrando esse problema?

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

No entanto, se você tiver um processo de revisão de código, ele deve estar destacado antes do teste. Se você está constantemente em conflito com os prazos, os problemas das estimativas de entrega significam que um componente-chave de qualquer processo de desenvolvimento - ou seja, revisão de código - está sendo estrangulado?

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

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, do que você está estruturalmente construindo dívida técnica e você deve assumir o problema com a gestão. Se eles não resolverem suas preocupações, é melhor começar a procurar outras oportunidades de emprego, já que a cultura da empresa provavelmente se reuniria com os princípios darwinianos em breve.

Para ajudar a reduzir o problema no futuro, desenvolva um documento interno de padrões 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 enquanto refaz o código, mas somente quando refatora.

Sou relativamente inexperiente com programação. Como estudante, no entanto, muitas vezes me comprometo a rever e parcerias em projetos. Se houver tempo suficiente para concluir um projeto, irei em frente e limpe o código de um membro da equipe para obter clareza e legibilidade. Mais frequentemente do que não, eu vou achar difícil até mesmo vasculhar as primeiras 100 linhas ou mais. Nesses casos, estou mais do que disposto a estender a mão para ajudar a ensinar a um colega programador melhores hábitos e codificação. Se simplesmente não houver tempo suficiente, simplesmente copio / colo e trabalho meus projetos no quadro 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, a crítica construtiva (independentemente de como não é bem-vinda) só beneficia tanto a ele quanto a mim a longo prazo. Se eu colaborar com os mesmos indivíduos no futuro, posso ficar tranqüilo sabendo que eles tinham algumas diretrizes informativas em suas mentes, e apenas esperar que a próxima rodada seja muito mais fácil.

Em geral, se você tiver tempo de sobra, leve-a para ensinar seus recém-chegados a conduzir seu trabalho de modo que todos sejam benéficos. Tire um minuto e ensine o que funcionou para você e o que não funcionou. Se você não tem tempo, descubra o trabalho deles agora e não se esqueça de voltar para eles quando tiver a chance. Deixe-os saber que existem maneiras melhores de fazer as coisas, especialmente se você estiver trabalhando com elas no futuro.

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

• A programação em par funciona como uma versão simplificada da revisão de código para entender como se 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 como, mas o porquê da refatoração e do código bom. Na minha experiência, é mais rápido do que desenvolver sozinho, uma vez que as ideias são lançadas continuamente, terminando com um resultado geral de maior qualidade e melhor compreensão do código e do pensamento da outra pessoa.
• Ferramentas de lintagem podem verificar se o estilo de codificação está sendo seguido. Isso ensina todos como formatar o código, e os erros devem cair rapidamente quando os desenvolvedores se lembrarem do padrão.
  • Faça essa parte do processo de criação para garantir que ela seja corrigida antes de confirmar.
  • Use modelos de idioma para garantir que seu CSS, HTML, JavaScript e código do lado do servidor possam ser verificados separadamente.
• Ferramentas de validação podem verificar se a saída gerada é correta. Estes também devem fazer parte do processo de construção.

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

Minha recomendação é mostrar a liderança e liderar a revisão regular de código. O gerenciamento não é empurrado de cima para garantir que as revisões regulares de código aconteçam, mas minha experiência é que eles ficarão impressionados quando um programador progride para agendar e realizar revisões regulares de código.

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

• aprenda melhor estilo
• siga as práticas recomendadas
• aprenda a pesquisar o que está fazendo

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

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

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

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

Disse que, acredito que a maioria dos prazos é artificial. Sistemas reais vivem cada vez mais do que os prazos e o projeto ruim que você faz hoje irá lutar contra você para todo o sempre. As pessoas correm para entregar algo em alguns meses e passam anos depois de corrigir algumas decisões ruins em um código que está sendo executado na produção.

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

Então, IMO, eu acho que você está certa em consertar o design quebrado, e ser profissional (especialmente para os juniores) também significa que você deve saber como receber críticas e como aprender com elas, mesmo que não seja educado. Na verdade, a maior parte da vida não é educada de qualquer maneira.

Qualquer resposta direta será extrema. Claramente há casos em que o prazo é tão apertado que você deve usar um 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 é métodos para julgar em que você está, e talvez métodos para estabelecer 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 para fazer além de refatorar, não há "mais tarde" em que de alguma forma ele terá maior prioridade para 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 estiver revisitando-o por algum outro motivo, e provavelmente estará em um prazo final também. Suas opções reais são para corrigi-lo agora ou deixá-lo.

É claro que um código bem estilizado é melhor do que um código com estilo ruim, supondo que você planeje lê-lo novamente. Se você planeja nunca mais lê-lo, então não arrume-o . Envie a primeira coisa que passa nos testes. Mas esse é um cenário bastante raro, para a maioria dos programadores isso acontece aproximadamente nunca. Ignorando esse caso, só você tem os detalhes do seu caso real para julgar quanto custa consertar versus quanto custa (em manutenção futura aumentada) 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. Estes não beneficiam muito você para consertar agora. Os mais óbvios são triviais para corrigir (erros de espaço em branco e afins) e por isso é difícil imaginar que você tenha tempo para fazer essa pergunta, mas não para corrigi-los ;-) Para aqueles que não são triviais e são desse tipo, então OK , você tem algum código que não é ideal, mas você deve ser pragmático. Funciona e você está em um prazo. Use-o.

Existem certas coisas que são consideravelmente mais fáceis de consertar agora do que serão mais tarde quando (a) elas não são tão novas na mente de todos; (b) outras coisas foram escritas que confiam nelas ou as imitam. Estes são muito mais valiosos para corrigir agora, então priorize-os. Se você não tem tempo nos prazos para consertá-los, então precisa pressionar o máximo possível por prazos mais longos, porque está acumulando dívidas na sua base de códigos que provavelmente terá que pagar na próxima vez que visitar o código.

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

Você deve escrever problemas comuns em um guia de estilo que diz "não faça isso, faça isso" e explica por quê. Em última análise, a razão é permitida, "para tornar nosso código esteticamente consistente", mas se você não estiver preparado para anotar suas regras com alguma justificativa, então provavelmente não deve aplicá-las ou. Apenas deixe cada programador livre para escolher.

Finalmente, tenha cuidado com a tendência de ajustar coisas indefinidamente. Os retornos diminuem e você precisa aprender através da experiência, onde eles ainda são bons. É absolutamente essencial que você formule uma ideia realista do que é bom o suficiente, ou então você não pode ter essa negociação na qual você garante que seus prazos lhe darão tempo para criar um código "bom o suficiente". Gaste seu tempo em coisas que não são boas o suficiente.

Como muitos já disseram antes, o que você joga no ar sempre volta para baixo. Eu acredito em strong uniformidade através de 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 fusão final no tronco principal. Pode ser apenas um pouco malfeito quando você olha para o procedimento ou classe individual, mas se todo mundo comete um código "um pouco feio", ele realmente fica realmente feio como um todo.

O código feio que funciona normalmente funciona 90% do tempo, mas desmorona nas bordas. Certificar-se de que isso não é geralmente simples, seguindo apenas algumas regras simples. Primeiro, deve ser obrigatório para cada programador definir e documentar restrições exatas para cada procedimento ou bloco funcional que produzam.

Em terceiro lugar, um conjunto de ambientes de desenvolvimento padronizados com ferramentas pré-configuradas é inestimável. Um servidor TS é excelente para isso. Todos têm as mesmas ferramentas (e versões) exatas, 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 de que você rejeitará quaisquer commits que ainda tenham avisos. Agora você pode usar o tempo de revisão de código de sua equipe para melhorar seu conjunto de regras a partir do feedback deles, e sua equipe poderá se corrigir sem a necessidade de fazer uma limpeza constante depois disso. Também é muito mais fácil para um programador fazer críticas de código a partir de uma ferramenta configurada corretamente do que de um colega ou chefe, onde os padrões podem parecer arbitrariamente definidos ou não são compreendidos adequadamente. Se o IDE lhe disser que seu código é de má qualidade, ninguém vai discutir com ele e ele será corrigido. Você verá que a qualidade do código aumentará drasticamente, e a equipe como um todo gastará MUITO menos tempo em refatoração e limpeza após algumas semanas. Os programadores também se acostumarão com as regras e deixarão de escrever códigos ruins.

Sugiro usar uma ferramenta de revisão. Se você tiver um repositório baseado em Git, você pode usar a ferramenta de revisão Gerrit . Depois de alguns commits rejeitados, a equipe aprenderá os padrões que você deseja seguir e futuros commits não exigirão nenhum trabalho adicional seu.

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