Quais são as boas abordagens para limpar projetos antigos?

11

Eu tenho um software que escrevi há cerca de 2 anos e precisa de alguns recursos adicionados a ele. Percebi que está uma bagunça horrível e tenho vontade de mudar tudo, arrumar tudo, etc. Li o artigo Joel on Software sobre não começar de novo , então qual é o melhor caminho a seguir?

refactoring maintenance billy.bob
fonte
Com quais decisões da época você discorda hoje?

Respostas:

21

Você tem três opções básicas:

  1. Se o aplicativo for muito pequeno e uma bagunça real , recomeçar pode ser sua melhor aposta.

  2. Refatorar .

  3. Viva com a bagunça e corte os recursos adicionais.

Normalmente, a opção (2) é sua melhor aposta.

A quantidade de refatoração que você efetivamente depende do recurso que você coloca versus o valor que obtém. As perguntas a serem feitas incluem:

  1. Que tempo / orçamento está disponível?
  2. Quanta modificação você antecipa no futuro?
  3. Quem mais verá o código? (ou seja, códigos confusos prejudicam sua reputação?)
  4. Espera-se que mais alguém mantenha o código?
  5. Quais ferramentas de refatoração estão disponíveis para ajudá-lo?
  6. Qual é a sua experiência de refatoração?
  7. Que experiência você obterá com a refatoração?
  8. Que tipos de refatoração oferecerão mais benefícios?
  9. Quais testes automatizados já existem? Precisa ser escrito?
  10. Quanto teste manual será necessário?
  11. Como você se sentirá se deixar o código como está?

Na minha experiência, é muito fácil entrar em confusão durante uma sessão de refatoração. As lições mais importantes que aprendi são:

  1. Faça uma coisa de cada vez.
  2. Dê pequenos passos.
  3. Faça bom uso do seu controle de origem (verifique com frequência + inclua comentários).
  4. Faça uso de ferramentas automatizadas de refatoração.
  5. Conheça o IDE.
Kramii
fonte
6
Eu também gostaria de adicionar para evitar um estado quebrado por muito tempo. Eu já vi muitos projetos de código aberto morrendo rapidamente durante uma reescrita / reformulação ambiciosa. Um projeto não funcional mata a motivação rapidamente.
LennyProgrammers
2
Absolutamente. Em relação à reescrita / design ambicioso, eu me apaixonei por isso mais de uma vez. Agora, tento levar as coisas em etapas menores. Eu adicionei esta sugestão à minha resposta.
Kramii
Eu também acrescentaria que você não deve refatorar nada que não tenha um teste escrito para ele. Resista ao desejo de consertar tudo e apenas se concentre nas áreas que precisam ser alteradas para adicionar os novos recursos. Depois de fazer isso, decida quanto esforço adicional você deseja fazer para refatorar o restante.
TMN
1
@ TMN: Idealmente, sim. No entanto, você nem sempre precisa de um teste automatizado. (1) Se o código foi desenvolvido sem testes automatizados, pode não ser fácil / possível ajustar os testes de unidade até que você já tenha feito alguma refatoração (2) Pode ser caro escrever testes antes de fazer alterações localizadas e triviais. (3) Ferramentas automatizadas de refatoração + recursos IDE podem ajudar a impedir a quebra de código como resultado da refatoração.
Kramii
2
Eu acrescentaria - no seu controle de origem, coloque toda a refatoração em uma FILIA separada. Isso ajuda a fazer comparações sensuais passo a passo e grandes blocos. Isso pode ser inestimável se as coisas se transformarem em creme (o que elas farão).
quickly_now
5

Bem, pelo menos refatorar o suficiente para que o novo recurso possa ser adicionado com segurança. Ou seja, não piora ainda mais. O restante depende de restrições de motivação, orçamento e tempo - mas lembre-se de que a limpeza completa de uma bagunça pode levar mais tempo do que a criação original.

user281377
fonte
1
Essa é, obviamente, a famosa Regra dos Escoteiros: sempre deixe o código em um estado melhor do que você o encontrou.
Jörg W Mittag
2

Desta vez, enquanto conserta as coisas, certifique-se de documentá-lo. Da próxima vez que você ver o código, será muito mais fácil lembrar as coisas.

Manoj R
fonte
1

Depende, vai custar mais tempo mantendo-o porque é uma bagunça ou reescrevê-lo para que não seja uma bagunça e seja facilmente mantido. Pessoalmente, estou passando por isso agora, estou convertendo um site de intranet para o ASP.Net MVC3 porque o código antigo era uma pilha de porcaria (que eu escrevi) porque deveria ser descartável (sim, eu deveria saber melhor ) A velha pilha de porcaria ainda está aqui, e é uma dor de cabeça adicionando recursos e corrigindo bugs. O MVC é bonito e torna o trabalho realmente agradável, por isso está sendo reescrito.

Gelo preto
fonte