É uma boa ideia programar um horário regular para limpar o código? [fechadas]

42

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

Seria uma boa ideia agendar horário regular, digamos, uma semana a cada dois meses, para apenas limpar nossa base de código?

    
por user84667 18.03.2013 / 03:56
fonte

10 respostas

100

Não.

Corrija enquanto estiver trabalhando nisso:

  • Se você esperar para refatorar a parte em que está trabalhando, esquecerá muito disso e terá que gastar tempo para se familiarizar com isso novamente.
  • Você não vai acabar usando o código "gold-plating" que acaba nunca sendo usado porque os requisitos foram alterados
por 18.03.2013 / 05:19
fonte
21

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

Particularmente para projetos que são strongmente orientados pelas vendas, geralmente há um grande esforço para incluir novos recursos em cada lançamento, e você inevitavelmente acaba tendo que comprometer seus instintos melhores e introduzir alguns kludges / hacks aqui e ali.

Eventualmente, você acumulou 'dívida técnica' suficiente por meio desses pequenos comprometimentos que você acaba gastando um bom tempo trabalhando com as falhas na base de código e não consegue usar todo o seu potencial.

Normalmente, há dois tipos de problemas gerados dessa maneira:

  • Pequenos que podem ser facilmente fixados mas podem ser sistémicos, e. parâmetros nomeados indevidamente, tratamento incompleto de erros, etc. Eles normalmente terão pouco impacto fora do bloco de código onde eles aparecem. A melhor maneira de lidar com estes é revisões de código e verificando o código enquanto ele está sendo escrito / modificado. Como outros afirmaram, não há precisa reservar um ciclo de refatoração especial para corrigir esses erros.
  • Os grandes que podem ter surgido de especificações incompletas ou decisões de design ruins no início, ou dois desenvolvedores / equipes criando duas soluções diferentes para o mesmo problema. Estes são geralmente muito mais difíceis de corrigir e exigem um esforço concertado 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 serem corrigidos.

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

    
por 18.03.2013 / 04:07
fonte
11

Eu tenho meus desenvolvedores arrumando seu código antes do checkin (Subversion) ou mesclando com o branch de desenvolvimento principal (Git).

Eu os faço o seguinte:

  • Remover comentários irrelevantes
  • Assegure-se de que seus métodos, argumentos e variáveis sejam apropriadamente denominados
  • Verifique se há estrutura nas classes e se os itens estão encapsulados como deveriam
  • Refatore para melhorar a legibilidade e reduzir qualquer cheiros de código

Para os projetos maiores, o código é revisado formalmente antes de ser mesclado da ramificação de desenvolvimento para a ramificação principal.

Acho que "dedicar tempo" significa que é algo que pode ser adiado ou adiado devido à quantidade de trabalho envolvido. Por ter os desenvolvedores fazendo isso por um check-in (o que equivale a um pedido de mudança / problema no JIRA), é muito mais gerenciável.

    
por 18.03.2013 / 04:04
fonte
9

Não na minha opinião. Se você deixar muito tempo entre quando você encontrar a dívida de tecnologia e quando você consertá-lo, você perde o contexto de qual é o problema. Demora mais tempo para consertar e tende a ficar pior. Mais importante, as pessoas deixam as janelas quebradas porque não é "semana de limpeza".

Pessoalmente, negocio para limpeza da dívida técnica a cada sprint se eu sei que criamos alguns no sprint antes. Mantém a dívida fresca na mente das pessoas. Ele limita a quantidade de código usando o código do problema para que a refatoração seja mais fácil. Impede que a dívida técnica se acumule. E isso ajuda os desenvolvedores a não darem tapa em algo juntos, porque eu só vou fazer com que eles façam isso logo no próximo sprint (então, é melhor fazê-lo logo no início).

    
por 18.03.2013 / 04:18
fonte
4

Eu diria definitivamente sim, com uma ressalva: isso deve ser feito com frequência, preferencialmente semanalmente. Acredito que uma revisão de código regular programada, juntamente com a ação real sobre os itens que saem da revisão de código, é muito rápida. Veja a resposta de p.s.g.

1 semana a cada 2 meses definitivamente nã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 muito tempo, não estará mais em contato com o código e, geralmente, levará muito mais tempo para consertar / limpar / refatorar.

    
por 18.03.2013 / 11:35
fonte
1

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

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

    
por 18.03.2013 / 05:55
fonte
1

Acho que as duas respostas populares "Não" "Sim" são dois aspectos da mesma verdade. Lembre-se que o OP está falando sobre um grupo que ele está gerenciando, não apenas ele mesmo como um indivíduo. Não podemos supor que todos os desenvolvedores do grupo sejam bem disciplinados o suficiente para escrever um código limpo e de fácil leitura; e há a questão da 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 podem escrever códigos que seriam considerados limpos quando separados, mas impuros quando considerados em conjunto com outras pessoas (sem mencionar as interfaces que rangem).

Por outro lado, o "consertar enquanto trabalha" é, na minha opinião, um ideal para aspirar. Você pode fazer seu código sair ainda mais "consertado" por

  • cuidado cuidadoso com o peer
  • escrevendo testes unitários junto com o próprio código
  • adotando diretrizes de codificação
  • usando formatadores e linters automáticos (mas YMMV)
  • etc.

Agora, se a equipe do OP adota o acima, e se ele encoraja seus subordinados - por exemplo, durante as revisões de código e durante as sessões periódicas de limpeza de código - para tentar antecipar as armadilhas e evitar antecipadamente a fealdade, com o tempo, esperamos que ele precise de menos tempo de limpeza. (E então eles poderiam dedicar esse tempo à documentação, refatoração mais profunda e compartilhamento de conhecimento sobre o que eles escreveram e consolidaram.)

    
por 18.03.2013 / 13:17
fonte
1

Eu acho que agendar horários regulares é muito bom, seja uma tarefa em um projeto regular de estilo cascata ou histórias em um estilo á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 o cancelamento do dia de limpeza porque você está atrasado no projeto.

Tendo gerenciado um projeto que tinha uma quantidade enorme de dívida de código, trabalhá-los regularmente era a chave para fazer as coisas funcionarem sem problemas. Algumas de nossas coisas eram grandes, outras eram pequenas.

Depois de alguns meses desse tipo de trabalho, o líder da nossa equipe de operações me disse que tudo estava correndo bem.

Cada item pode não parecer muito, mas, assim como todas as dívidas, é exibido.

    
por 18.03.2013 / 15:27
fonte
1

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

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

Os gerentes têm que 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 façam sugestões que promovam más práticas. Eles podem literalmente dizer "vamos limpá-lo mais tarde" ou se funcionar, isso é bom o suficiente.

Você pode ter que começar dedicando um tempo específico para mostrar que isso é importante. Uma vez que você saiba que sua equipe é capaz de limpar seu código (não é um dado), então você pode tentar incorporá-lo com mais freqüência.

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

Pessoalmente, luto para resolver um novo problema e fazê-lo funcionar enquanto tento manter as coisas organizadas. Estou melhorando, mas geralmente faço uma pausa deliberada e limpo as coisas. É uma mentalidade diferente para mim. Eventualmente, as práticas sólidas se tornam hábitos.

    
por 18.03.2013 / 16:23
fonte
-1

Não, você deve fazer isso enquanto estiver codificando. Isso é chamado de refatoração se você estiver usando o 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 você não se lembra de cada parte do seu código.

Sugiro a refatoração, que é baseada na codificação do código necessário para que algo funcione e, assim que ele for reprojetado, otimize-o e torne-o bonito.

    
por 18.03.2013 / 16:23
fonte