É uma boa idéia agendar um horário regular para limpar o código? [fechadas]

Estou gerenciando uma pequena equipe de desenvolvedores. De vez em quando, decidimos que vamos passar um dia ou dois para limpar nosso código.

Seria uma boa idéia agendar um horário regular, digamos 1 semana a cada 2 meses, para limpar nossa base de código?

Não.

Corrija-o enquanto estiver trabalhando:

• Se você esperar para refatorar a parte em que está trabalhando, esquecerá muito e precisará gastar tempo para se familiarizar novamente.
• Você não vai acabar com o código "gold-plating" que acaba nunca sendo usado porque os requisitos foram alterados

Minha opinião pessoal: é absolutamente necessária para 90% dos projetos.

Especialmente para projetos que são fortemente direcionados pelas vendas, geralmente há um grande impulso para incluir novos recursos em cada versão, e você inevitavelmente acaba comprometendo seus melhores instintos e introduzindo alguns kludges / hacks aqui e ali.

Eventualmente, você acumulou 'dívida técnica' suficiente por meio desses pequenos compromissos e acaba gastando bastante tempo trabalhando em torno das falhas na base de código e não consegue usar todo o seu potencial.

Geralmente, existem dois tipos de problemas gerados desta maneira:

• Pequenos que podem ser facilmente corrigidos, mas podem ser sistêmicos, por exemplo, parâmetros nomeados incorretamente, tratamento incompleto de erros, etc. Eles normalmente terão pouco impacto fora do bloco de código em que aparecem. A melhor maneira de lidar com isso é revisar o código e verificar o código enquanto ele está sendo gravado / modificado. Como outros já declararam, não é necessário reservar um ciclo especial de refatoração para corrigir esses erros.
• Grandes, que podem ter surgido a partir de especificações incompletas ou decisões ruins de design desde o início, ou dois desenvolvedores / equipes criando duas soluções diferentes para o mesmo problema. Geralmente, são muito mais difíceis de corrigir e exigem um esforço conjunto para consertar. Como resultado, eles geralmente são adiados, até que se tornem um incômodo perpétuo. Esses tipos de problemas exigem um período de tempo dedicado para correção.

Geralmente, tento reservar tempo para um ciclo puro de refatoração / correção de bugs a cada 3 a 4 ciclos. Eu sempre peço aos meus desenvolvedores que me digam quando também se sentem frustrados com a base de código. Nem todo desenvolvedor precisa trabalhar no esforço de limpeza - você geralmente (mas nem sempre) pode escalonar um pouco as equipes, portanto, apenas uma equipe está trabalhando na limpeza a qualquer momento.

Meus desenvolvedores ordenaram seu código antes do check-in (Subversion) ou da fusão com o principal ramo de desenvolvimento (Git).

Eu tenho que fazer o seguinte:

• Remover comentários irrelevantes
• Certifique-se de que seus métodos, argumentos e variáveis ​​sejam nomeados adequadamente
• Verifique se há estrutura para suas classes e se os itens estão encapsulados, como devem ser
• Refatorar para melhorar a legibilidade e reduzir qualquer cheiro de código

Para projetos maiores, o código é revisado formalmente antes da fusão do ramo de desenvolvimento para o ramo principal.

Penso que "dedicar tempo" significará que é algo que pode ser adiado ou adiado devido à quantidade de trabalho envolvido. Ao fazer com que os desenvolvedores façam isso por check-in (o que equivale a uma solicitação / problema de mudança no JIRA), é muito mais gerenciável.

Não na minha opinião. Se você deixar muito tempo entre a dívida com a tecnologia e a corrigi-la, perderá o contexto do problema. Leva mais tempo para consertar e tende a ficar pior. Mais importante, as pessoas deixam as janelas quebradas porque não é "semana da limpeza".

Pessoalmente, negocio a limpeza técnica da dívida em cada sprint, se souber que criamos alguns no sprint antes. Mantém a dívida fresca na mente das pessoas. Limita a quantidade de código usando o código do problema para facilitar a refatoração. Impede que a dívida técnica se acumule. E isso ajuda a empurrar os desenvolvedores a darem um tapa em algo juntos, porque eu vou fazê-los fazer isso no próximo sprint (então é melhor fazê-lo bem em primeiro lugar).

Eu diria que sim definitivamente, com uma ressalva: isso deve ser feito com frequência, preferencialmente semanalmente. Acredito que uma revisão de código regular agendada, além de atuar sobre os itens que saem da revisão de código, compensa muito rapidamente. Veja a resposta de pswg

1 semana a cada 2 meses definitivamente não é o suficiente. Isso fala com a maioria das outras respostas que responderam com 'Não' à sua pergunta. A essência da maioria dessas respostas é que, se você esperar demais, não estará mais em contato com o código e, em geral, leva muito mais tempo para corrigir / limpar / refatorar.

Não é tão claro se você quis dizer um exercício adicional de limpeza de código de vez em quando. Nesse sentido, sim. Quaisquer que sejam as práticas que seguimos, sempre ocorre alguma degradação.

Você não deve usar isso como desculpa para não fazer a coisa certa [Aplicando princípios do SOLID, testes de unidade relevantes, inspeções etc.] em primeiro lugar.

Penso que atualmente as duas respostas populares "Não" "Sim" são dois aspectos da mesma verdade. Lembre-se de que o OP está falando de um grupo que ele está gerenciando, não apenas de si mesmo como indivíduo. Não podemos supor que todos os desenvolvedores do grupo sejam disciplinados o suficiente para escrever um código limpo e de fácil leitura; e há a questão de pressão externa e metodologias de estilo ágil. Além disso, mesmo com os melhores esforços das pessoas, suas diferenças de estilo significam que elas podem escrever código que seria considerado limpo quando separado, mas impuro quando considerado junto com outras pessoas (para não mencionar as interfaces barulhentas).

Por outro lado, o "conserte enquanto trabalha nele" é, na minha opinião, um ideal a se aspirar. Você pode tornar seu código ainda mais "corrigido"

• cuidadoso CRing de pares
• escrever testes de unidade junto com o próprio código
• adoção de diretrizes de codificação
• usando formatadores e linters automáticos (mas YMMV)
• etc.

Agora, se a equipe do OP adotar o exposto acima, e se ele encorajar seus subordinados - por exemplo, durante revisões de código e durante sessões periódicas de limpeza de código - para tentar antecipar armadilhas e evitar a feiúra com antecedência, com o tempo, esperamos que precisará de menos tempo de limpeza. (E eles poderiam dedicar esse tempo à documentação, refatoração mais profunda e compartilhamento de conhecimento do que escreveram e consolidaram.)

Acho que agendar um horário regular é muito bom, seja uma tarefa em um projeto em estilo cascata regular ou histórias em um projeto ágil. Ter um horário definido pode não ser tão valioso quanto apenas trabalhar em sua programação. Isso permite que você faça isso como parte do cronograma versus cancelamento do dia da limpeza, porque está atrasado no projeto.

Ter gerenciado um projeto que possuía uma quantidade enorme de dívidas em código, trabalhando-as regularmente era essencial para que as coisas funcionassem sem problemas. Algumas de nossas coisas eram grandes, outras eram pequenas.

Após alguns meses desse tipo de trabalho, o líder da nossa equipe de operações me disse como tudo estava funcionando perfeitamente.

Cada item pode não parecer muito, mas, como todas as dívidas, ele aumenta.

A resposta ideal é Não, porque você toma as medidas necessárias para evitar que isso seja uma necessidade (limpe conforme você avança por vários motivos já mencionados).

Esse pode ser o objetivo no final, mas você pode ter uma equipe que está longe de colocar isso em prática.

Os gerentes precisam assumir alguma responsabilidade. Nem sempre é culpa do desenvolvedor. Os gerentes podem dizer uma coisa, mas começam a pressionar para que os projetos sejam concluídos e fazem sugestões que promovam más práticas. Eles podem literalmente dizer: "limparemos mais tarde" ou, se funcionar, isso é bom o suficiente.

Você pode precisar dedicar um tempo específico para mostrar que isso é importante. Depois que você souber que sua equipe é capaz de limpar o código (não um dado), tente incorporá-lo com mais frequência.

Eventualmente, você não precisa definir um horário.

Pessoalmente, luto para resolver um novo problema e fazê-lo funcionar enquanto tento manter as coisas arrumadas. Estou melhorando, mas muitas vezes paramos deliberadamente e limpamos as coisas. É uma mentalidade diferente para mim. Eventualmente, as práticas sólidas se tornam hábito.

Não, você deve fazer isso enquanto estiver codificando. Isso é chamado de refatoração se você estiver usando TDD. O problema quando você espera um mês ou dois para corrigir e limpar seu código é que você pode alterar o comportamento do código porque não se lembra de todas as partes do seu código.

Sugiro refatorar, que se baseia na codificação primeiro do código necessário para fazer algo funcionar e, assim que funciona, redesenha-o, otimize-o e torne-o bonito.