Réplication de code et refactorisation

Question

Je voudrais entendre des opinions sur de petites quantités de réplication de code au sein de méthodes que vérifier pour la même condition par exemple.

While(condition){ 
...... do x 

} 

Normalement, s'il y avait un de ce genre de réplication je factoriser le code tel qu'il peut faire versioning un cauchemar, si les changements d'état, par exemple, vous devez changer tous les cas, pas un bon travail à faire . Cependant, que faire si la condition est relativement simple et n'est utilisée que dans 3 méthodes est-il sage de refactoriser,

Alors en résumé où les gens dessinent la ligne au code de refactoring?

Answer 1

Le refactoring n'est pas gratuit. Toute modification du code peut introduire des bogues. Donc, chaque développeur conscient réfléchit s'il a le temps d'examiner attentivement les changements et, dans de nombreux cas, décide de ne pas refactoriser.

Answer 2

Cela dépend de 2 choses, IMO - la taille de la duplication (combien de lignes sont concernées), et la localité des duplications - à quel point elles sont proches en termes de contexte. Si vous avez dupliqué le code dans plusieurs méthodes de la même classe, je considérerais même extraire les doublons d'une seule ligne dans une méthode séparée (en supposant que la ligne en question était une pièce facilement identifiable, facile à isoler, assez découplée de code). Sinon, si j'avais du code dans une partie d'un projet, et un morceau de code presque identique dans une zone (presque) non liée, je ne l'exclurais pas, car la marge de divergence future semblerait plus élevée. ...

Answer 3

La clé du refactoring est de le faire lorsque vous avez besoin de pour. Dans l'exemple ci-dessus, si vous avez 3 boucles while différentes avec la même condition, à savoir dans le futur vous pourriez vouloir des conditions différentes, si vous avez déjà refactorisé, alors vous avez introduit une situation d'erreur potentielle.

C'est une question de jugement, la même condition trois fois semble ok, la même condition 10 fois est un refactor évident, mais où est le point de basculement?

Answer 4

Personnellement, je suis habituellement assez agressif avec les refactorings. Je crois que si vous nettoyez votre code régulièrement, vous devez surtout faire des refactorings petits et simples. Si vous le laissez pendant un certain temps, cela devient si compliqué et difficile à maintenir.

Dans votre cas particulier, je refactoriserais définitivement si la condition a une signification commerciale raisonnable, car cela rendra le code plus lisible. Mais même s'il s'agit d'une question technique, je considérerais le refactoring à condition qu'il s'agisse simplement d'extraire une fonction ou une propriété.

Idéalement, vous devriez avoir des tests unitaires qui s'assureront que votre refactoring est toujours correct, de sorte que le coût de le faire devrait être vraiment quelques minutes, souvent plus petit que d'écrire cette réponse.

Answer 5

Une règle générale est le Rule of Three introduit par Martin Fowler dans le travail séminal Refactoring. La règle dit que deux choses qui sont fondamentalement les mêmes peuvent rester, mais une fois que vous en ajoutez un troisième, vous devez les refactoriser. En plus de faciliter les modifications futures, le refactoring aide à la lisibilité et rend l'intention plus évidente.