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

Eu tenho que estender um módulo existente de um projeto. Não gosto da maneira como isso foi feito (muitos anti-padrões envolvidos, como código de copiar / colar). Não quero realizar um refator completo por vários motivos.

Eu devo:

• criar novos métodos usando a convenção existente, mesmo que eu ache errado, para evitar confusão para o próximo mantenedor e ser consistente com a base de código?

ou

• tente usar o que me sinto melhor, mesmo se estiver introduzindo outro padrão no código?

Precison editado após as primeiras respostas:

O código existente não está uma bagunça. É fácil de seguir e entender. MAS está introduzindo muitos códigos padrão que podem ser evitados com um bom design (o código resultante pode se tornar mais difícil de seguir). No meu caso atual, é um bom e velho módulo DAO JDBC (modelo de mola interno), mas eu já encontrei esse dilema e estou procurando outro feedback do desenvolvedor.

Não quero refatorar porque não tenho tempo. E mesmo com o tempo, será difícil justificar que todo um módulo funcionando perfeitamente precise ser refatorado. O custo de refatoração será mais alto que seus benefícios. Lembre-se: o código não é confuso ou é complexo demais. Não consigo extrair alguns métodos lá e introduzir uma classe abstrata aqui. É mais uma falha no design (resultado do extremo 'Keep It Stupid Simple', eu acho)

Portanto, a pergunta também pode ser feita da seguinte maneira:
você, como desenvolvedor, prefere manter um código chato e estúpido OU OU ter alguns ajudantes que farão o código chato no seu lugar?

A desvantagem da última possibilidade é que você terá que aprender algumas coisas e talvez também precise manter o código chato e estúpido até que uma refatoração completa seja concluída)

A refatoração é melhor realizada em pequenas etapas e, de preferência, apenas se você tiver testes de unidade para cobrir o código. (Portanto, se você ainda não possui testes, lembre-se de escrevê-los primeiro e, até então, siga as refatorações mais simples, mais infalíveis e de preferência automatizadas. Uma grande ajuda nisso é Trabalhar de maneira eficaz com o código legado de Michael Feathers.)

Em geral, tente melhorar um pouco o código sempre que você o tocar. Siga a regra dos escoteiros ( criada por Robert C. Martin ) deixando o código mais limpo do que o encontrado. Ao adicionar um novo código, tente mantê-lo separado do código incorreto 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 insira seu novo código. Dessa forma, você cresce gradualmente ilhas maiores de código (er) dentro da base de código existente.

Atualizar

O custo de refatoração será mais alto que seus benefícios. [...] Você, como desenvolvedor, prefere manter um código chato e estúpido fácil OU ter alguns ajudantes que farão o código chato e estúpido em seu lugar?

Enfatizei o que acredito ser o ponto chave aqui. Sempre vale 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, portanto, devemos usá-los com sabedoria. Gaste esse precioso pouco tempo em refatoração, onde ela traz mais benefícios com o mínimo de esforço.

Como uma mente criativa, é claro que eu preferiria produzir código perfeito, bonito e elegante e reescrever tudo que não se assemelha aos meus ideais :-) Na realidade, porém, sou pago para produzir software que resolva problemas reais para seus usuários, então eu deve pensar em produzir o maior valor pelo seu dinheiro a longo prazo.

O benefício da refatoração aparece apenas se houver economia suficiente em tempo e esforços para entender, manter, corrigir e estender o código a longo prazo . Portanto, se um pedaço de código - por mais feio que seja - raramente ou nunca é tocado, não há bugs conhecidos e não conheço nenhum recurso futuro que possa exigir que eu toque nele, prefiro sair em paz.

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

Ser consistente ajuda apenas o próximo desenvolvedor quando o código circundante estiver em boa forma. Pense em quanto tempo você levou para entender o código em questão e encontrar os "pontos de extensão" certos para adicionar suas alterações. Se você seguir a tendência atual, o próximo cara precisará entender o código existente e seu novo código quando ele precisar 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á de menos esforço para adicionar suas alterações. Pense desta maneira. Suponha que o próximo cara é você. O que você prefere ver ao revisitar esse bloco de código, a mesma bagunça que está vendo agora ou algo mais logicamente construído?

A consistência tem uma alta prioridade. Obviamente, todo mundo em sã consciência prefere uma solução DRY elegante em todos os lugares, em vez de uma clichê copiada e colada em qualquer lugar, mas você realmente prefere duas abordagens diferentes na mesma base de código a uma aplicada de maneira consistente? E se alguém inventa uma solução ainda mais inteligente e também a aplica de maneira inconsistente? Então você tem três maneiras diferentes de fazer a mesma coisa.

Eu vi muitos códigos confusos resultantes dos desenvolvedores encontrarem uma "maneira melhor" de fazer algo, mas não aplicá-lo consistentemente em uma base de código. Se fizer parte de uma estratégia planejada e coordenada aplicar gradualmente um novo padrão ao longo do tempo, pode funcionar, mas todos os padrões implementados de maneira inconsistente correm o risco de piorar o sistema geral.

Talvez você possa considerar a refatoração em etapas menores, para 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ê de uma classe auxiliar. Pode parecer muito feio porque não foi projetado, mas cresceu, mas você pode corrigir isso agora porque possui todo o código em um só lugar.

Qualquer refatoração que elimine código duplicado é 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 futuras implementações. Graças à refatoração, o funcionamento interno não é mais visível; portanto, deve ser mais fácil entender, não mais difícil de seguir.

Na minha opinião, é um equívoco comum que o código refatorado seja mais difícil de seguir. Geralmente, esse é um argumento de pessoas que estão familiarizadas apenas com o que está sendo refatorado, e não com 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 posteriormente e estão automaticamente disponíveis em qualquer lugar do seu aplicativo. Este é um enorme ganho que geralmente é altamente subestimado. Em geral, a refatoração total de um componente não leva tanto tempo. (dias em vez de meses) Ao comparar isso com o tempo perdido devido a erros, tendo que entender o código que poderia ter sido refatorado, o custo da refatoração se torna mínimo.

Atualização relacionada à resposta de Péter Török: não é adiada a refatoração "porque leva tempo", o tempo para refatorá-la posteriormente aumenta? 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 pergunta totalmente diferente. :)

Você não pode criar uma nova interface / classes que funcione como uma fachada em relação ao 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 recortar e colar. Isso não requer refatoração, mas fornece o começo de uma base para refatoração futura.

Você, como desenvolvedor, prefere manter um código chato e estúpido fácil OU ter alguns ajudantes que farão o código chato e estúpido em seu lugar?

Eu não entendo a pergunta revisada. Eu acho que a maioria das pessoas, como eu, preferiria não manter "código estúpido e chato". 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 no momento. Boa escolha. Tenho problemas com a arrogância de um desenvolvedor de saber o que é melhor para os negócios. Uma grande refatoração às escondidas ... porque você conhece melhor que seu chefe? Qualquer gerente capaz pode avaliar os benefícios.

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