Parece que você está refatorando "apenas no caso", sem saber exatamente quais partes da base de código em detalhes serão alteradas quando o desenvolvimento do novo recurso ocorrer. Caso contrário, você saberia se há uma necessidade real de refatorar os módulos frágeis, ou se você pode deixá-los como estão.
Para dizer isso: acho que isso é uma estratégia de refatoração condenada . Você está investindo tempo e dinheiro da sua empresa para algo em que ninguém sabe se ela realmente retornará um benefício, e você está no limite de tornar as coisas piores introduzindo bugs no código de trabalho.
Aqui está uma estratégia melhor: use seu tempo para
-
adicione testes automáticos (provavelmente não testes unitários, mas testes de integração) aos módulos em risco. Especialmente aqueles módulos frágeis que você mencionou precisarão de um conjunto completo de testes antes de você alterar qualquer coisa lá.
-
refatorie apenas os bits necessários para colocar os testes no lugar. Tente minimizar qualquer uma das mudanças necessárias. A única exceção é quando seus testes revelam bugs - então corrija-os imediatamente (e refatore-os na medida em que você precise fazê-lo com segurança).
-
Ensine aos seus colegas o "princípio do escoteiro" (AKA "refatoração oportunista" ), portanto, quando equipe começa a adicionar novos recursos (ou para corrigir bugs), eles devem melhorar e refatorar exatamente as partes da base de código que precisam mudar, não menos, nem mais.
-
obtenha uma cópia do livro de Feather "Trabalhando efetivamente com código herdado" para a equipe.
Assim, quando chegar a hora de conhecer com certeza , será necessário alterar e refatorar os módulos frágeis (devido ao novo desenvolvimento do recurso ou porque os testes adicionados na etapa 1 revelam alguns bugs ), então você e sua equipe estão prontos para refatorar os módulos e, com maior ou menor segurança, ignorar esses comentários de aviso.
Como resposta a alguns comentários : para ser justo, se suspeitarmos que um módulo em um produto existente é a causa dos problemas regularmente, especialmente um módulo marcado como "don toque ", concordo com todos vocês. Ele deve ser revisado, depurado e, provavelmente, refatorado nesse processo (com o suporte dos testes que mencionei, e não necessariamente nessa ordem). Bugs são uma strong justificativa para a mudança, muitas vezes mais strong do que os novos recursos. No entanto, esta é uma decisão caso a caso. É preciso verificar com muito cuidado se realmente vale a pena mudar algo em um módulo que foi marcado como "não toque".