Manutenção de código: manter um padrão ruim ao estender o novo código para ser consistente ou não?

A refatoração é feita melhor em pequenos passos e, de preferência, somente se você tiver testes de unidade para cobrir o código. (Então, se você ainda não tem testes, esforce-se para escrevê-los primeiro e, até lá, siga as refatorações mais simples, mais infalíveis, de preferência automatizadas. Uma grande ajuda nisso é Trabalhando efetivamente com o código legado de Michael Feathers.

Em geral, tente melhorar o código sempre que tocá-lo. Siga a Regra de Escoteiros ( cunhada por Robert C. Martin ) deixando o código mais limpo do que o encontrou. Quando você adicionar um novo código, tente mantê-lo separado do código inválido existente. Por exemplo. não o enterre no meio de um método longo, em vez disso, adicione uma chamada a um método separado e coloque seu novo código lá. Dessa forma, você cresce ilhas gradualmente maiores de código limpo (er) dentro da base de código existente.

Atualizar

Refactoring cost will be heavier than its benefits. [...] You, as developer, do you prefer to maintain easy stupid boring code OR to have some helpers that will do the stupid boring code at your place ?

Eu enfatizei o que acredito ser o ponto chave aqui. Vale sempre a pena avaliar os custos e benefícios da refatoração antes de entrarmos nela. Como no seu caso, a maioria de nós tem recursos limitados para refatoração, então devemos usá-los com sabedoria. Gaste esse precioso tempo com a refatoração, onde ela traz mais benefícios com o mínimo de esforço.

O benefício da refatoração só aparece se houver economias de tempo e esforços suficientes para entender, manter, corrigir e estender o código a longo prazo . Então, se um pedaço de código - por mais horrível que seja - raramente ou nunca tocado, não há bugs conhecidos nele e eu não sei de nenhum futuro próximo que possa exigir que eu o toque, eu prefiro sair em paz.

Como você não tem tempo para refatorar e o código é sustentável, mantenha-o consistente. Na próxima vez, certifique-se de incluir a refatoração na estimativa.

Ser consistente apenas ajuda o próximo desenvolvedor quando o código circundante está em boa forma. Pense em quanto tempo você levou para entender o código em mãos e encontrar os "pontos de extensão" certos para adicionar suas alterações. Se você seguir a tendência atual, o próximo cara terá que entender o código existente, assim como o novo código, quando ele tiver que fazer alterações.

Se você refatorar o código em funções significativas, o próximo cara terá mais facilidade para compreender o que está acontecendo e precisará fazer menos esforço para adicionar as alterações. Pense desta maneira. Assuma que o próximo cara é você. O que você preferiria ver quando revisitar esse bloco de código, a mesma bagunça que está vendo agora ou algo mais construído logicamente?

Consistência tem alta prioridade. Obviamente, todos em sã consciência prefeririam uma solução DRY elegante em todos os lugares, em vez de clichê copiado e colado em todos os lugares, mas você preferiria duas abordagens diferentes na mesma base de código para ter uma aplicação consistente? E se alguém inventar uma solução ainda mais inteligente e também aplicá-la de forma inconsistente? Então você tem três maneiras diferentes de fazer a mesma coisa.

Eu vi um código muito confuso resultante de desenvolvedores encontrarem uma "maneira melhor" de fazer algo, mas não de aplicá-lo consistentemente em uma base de código. Se for parte de uma estratégia planejada e coordenada para aplicar um novo padrão gradualmente ao longo do tempo, pode funcionar, mas cada padrão implementado de forma inconsistente tem o risco de piorar o sistema como um todo.

Talvez você possa considerar a refatoração em etapas menores, de modo que cada etapa possa ser aplicada em toda a base de código de uma só vez. Por exemplo. extrair uma parte menor do clichê para uma função auxiliar em cada iteração. Com o tempo, você acaba com todo o clichê em uma classe auxiliar. Pode parecer muito feio porque não foi projetado, mas cresceu, mas você pode consertar isso agora porque você tem todo o código em um só lugar.

Qualquer refatoração que elimine o código duplicado é uma boa refatoração e não deve ser adiada a menos que um prazo seja iminente. O tempo gasto na refatoração uma vez é facilmente compensado pelo tempo ganho em implementações futuras. Graças à refatoração, o funcionamento interno não é mais visível, então deve ficar mais fácil de entender, não mais difícil de seguir.

Na minha opinião, é um equívoco comum que o código refatorado é mais difícil de seguir. Isso geralmente é um argumento de pessoas que estão familiarizadas apenas com o que está sendo refatorado, e não o resultado refatorado. Para os recém-chegados, o resultado refatorado será mais claro.

Quaisquer bugs / recursos podem ser corrigidos / implementados em um local central em um momento posterior e estarão automaticamente disponíveis em todos os lugares em seu aplicativo. Este é um ganho enorme que geralmente é altamente subestimado. Em geral, uma refatoração total de um componente não demora tanto. (dias em vez de meses) Ao comparar isso com o tempo perdido devido a bugs, tendo que entender o código que poderia ter sido refatorado, o custo da refatoração se torna mínimo.

Actualização relativa à resposta de Péter Török: Não é por adiar a refatoração "porque leva tempo", o tempo de refatoração aumenta mais tarde? A refatoração não deve demorar muito, quando feita com mais frequência.

Como explicar ao seu chefe que você passará alguns dias escrevendo código que não adiciona nada ao produto, é difícil, e é uma questão completamente diferente. :)

Você não pode criar uma nova Interface / Classes que funcione como Fachada sobre o código antigo, enquanto introduz seu novo código em seu próprio estilo que pode ser facilmente estendido?

Faça certo daqui para frente. Use funções em vez de cortar e colar. Isso não requer refatoração, mas dá a você o início de uma base para futuras refatorações.

You, as developer, do you prefer to maintain easy stupid boring code OR to have some helpers that will do the stupid boring code at your place ?

Eu não entendo a pergunta revisada. Eu acho que a maioria das pessoas, como eu, preferiria não manter "código chato estúpido". Eu não sei o que você quer dizer com ajudante, desculpe.

O pôster respondeu à sua própria pergunta, não fazendo grandes alterações agora. Boa escolha. Eu tenho problemas com a arrogância de um desenvolvedor que eles sabem o que é melhor para o negócio. Uma grande refatoração às escondidas ... porque você sabe melhor que seu chefe? Qualquer gestor competente pode avaliar os benefícios.

Se a refatoração não é uma opção, então a questão se torna mais uma discussão sobre a hora, o local, etc. corretos, para fazê-lo. Consistência é muito importante. No entanto, o código de longa duração geralmente se beneficia da "renovação". Outros discutiram isso ...