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

(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.)

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

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

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!

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.

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.

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.

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.

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.

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

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.

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.

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.

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 .