Acredito muito na regra dos escoteiros :
Sempre verifique um módulo mais limpo do que quando você fez o check-out. "Não importa quem seja o autor original, e se sempre fizermos algum esforço, por menor que seja, para melhorar o módulo. Qual seria o resultado? Acho que se todos seguissem essa regra simples, veríamos o fim da implacável deterioração de nossos sistemas de software.Em vez disso, nossos sistemas gradualmente se tornariam cada vez melhores à medida que evoluíam.Também veríamos equipes cuidando do sistema como um todo. do que apenas indivíduos cuidando de sua própria pequena parte.
Também acredito muito na ideia relacionada de Refatoração Oportunista :
Embora existam lugares para alguns esforços agendados de refatoração, prefiro incentivar a refatoração como uma atividade oportunista, realizada sempre e onde o código precisar ser limpo - por quem quer que seja. O que isso significa é que, a qualquer momento, alguém vê algum código que não é tão claro quanto deveria ser, deve aproveitar a oportunidade para corrigi-lo ali mesmo - ou pelo menos dentro de alguns minutos
Observe particularmente o seguinte trecho do artigo de refatoração:
Desconfio de qualquer prática de desenvolvimento que cause atrito para a refatoração oportunista ... Meu senso é que a maioria das equipes não faz refatoração suficiente, por isso é importante prestar atenção a qualquer coisa que esteja desencorajando as pessoas a fazê-lo. Para ajudar a esclarecer isso, fique atento a qualquer momento em que você se sentir desencorajado de fazer uma pequena refatoração, uma que, com certeza, levará apenas um ou dois minutos. Qualquer barreira desse tipo é um cheiro que deve desencadear uma conversa. Portanto, anote o desânimo e traga à equipe. No mínimo, isso deve ser discutido durante sua próxima retrospectiva.
Onde trabalho, há uma prática de desenvolvimento que causa atritos pesados - Revisão de Código (CR). Sempre que mudo algo que não esteja no escopo da minha "tarefa", sou criticado pelos meus revisores por dificultar a revisão. Isso é especialmente verdadeiro quando a refatoração está envolvida, pois dificulta a comparação de diferenças "linha a linha". Essa abordagem é o padrão aqui, o que significa que a refatoração oportunista raramente é feita, e apenas a refatoração "planejada" (que geralmente é muito pouco, muito tarde) ocorre, se é que existe.
Eu afirmo que os benefícios valem a pena e que três revisores trabalharão um pouco mais (para realmente entender o código antes e depois, em vez de olhar para o escopo restrito de quais linhas foram alteradas - a própria revisão seria melhor apenas por causa disso. ) para que os próximos 100 desenvolvedores que leem e mantenham o código se beneficiem. Quando apresento esse argumento, meus revisores dizem que não têm problemas com minha refatoração, desde que não esteja no mesmo CR. No entanto, afirmo que isso é um mito:
(1) Na maioria das vezes, você só percebe o que e como deseja refatorar quando está no meio de sua tarefa. Como Martin Fowler coloca:
Ao adicionar a funcionalidade, você percebe que algum código que está adicionando contém alguma duplicação com o código existente, portanto, é necessário refatorar o código existente para limpar as coisas ... Você pode conseguir algo funcionando, mas percebe que seria melhor se a interação com as classes existentes tiver sido alterada. Aproveite a oportunidade para fazer isso antes de se considerar terminado.
(2) Ninguém vai olhar favoravelmente para você liberando CRs "refatorando" que você não deveria fazer. Um CR tem uma certa sobrecarga e seu gerente não quer que você "perca seu tempo" em refatoração. Quando está incluído na alteração que você deve fazer, esse problema é minimizado.
O problema é exacerbado pelo Resharper, pois cada novo arquivo que adiciono à alteração (e não posso saber com antecedência exatamente quais arquivos acabariam sendo alterados) geralmente está repleto de erros e sugestões - a maioria dos quais está no local e merece totalmente fixação.
O resultado final é que eu vejo código horrível e deixo lá. Ironicamente, sinto que a fixação desse código não apenas não melhorará minha classificação, mas na verdade os reduzirá e me pintará como o cara "sem foco" que perde tempo consertando coisas que ninguém se importa em vez de fazer seu trabalho. Eu me sinto mal por isso, porque realmente desprezo o código incorreto e não suporto vê-lo, muito menos chamá-lo de meus métodos!
Alguma idéia de como posso remediar esta situação?
your manager doesn't want you to "waste your time" on refactoring