Je fais une étude sur les limitations de refactoring sur l'amélioration de l'architecture logicielle existante et je serais intéressé d'entendre vos expériences où vous avez trouvé que le refactoring n'était pas suffisant ou encore trop immature pour atteindre vos objectifs.Quelles sont les limites du refactoring?
Le code de refactoring qui n'a pas de suite de tests unitaires peut être risqué. Si le projet dispose déjà d'une suite de tests unitaires établie, à condition que vous mainteniez une approche TDD, il ne devrait pas y avoir de raison de s'inquiéter.
refactorisation peut être risqué
refactorisation est souvent difficile parce que le refactorer est souvent la même personne que le concepteur d'origine. Par conséquent, il n'a pas la même expérience dans le système et les décisions qui ont été prises en compte dans la conception originale. Vous courez toujours le risque que les bogues évités dans la conception originale puissent se glisser dans le nouveau design.
Cela peut être particulièrement vrai quand un nouveau ou un jeune membre de l'équipe, pas entièrement expérimenté avec ce système, décide d'injecter de la technologie ou des idées new-cool-wizbang dans un système par ailleurs stable. Souvent, lorsque les nouveaux membres de l'équipe ne sont pas bien intégrés dans l'équipe et ne reçoivent pas suffisamment de conseils, ils peuvent commencer à forcer le projet dans des directions non voulues par toute l'équipe.
Ceci est juste un risque, mais il y a aussi une chance que l'équipe se trompe et que le nouveau membre de l'équipe, s'il était en charge et autorisé à faire son travail, ferait une amélioration sérieuse.
Ces problèmes surviennent souvent au sein d'une équipe travaillant sur des systèmes hérités. Souvent, il n'y a pas d'améliorations à apporter au monde, donc l'équipe est conservatrice avec son design. Leur but est d'empêcher l'injection de nouveaux bogues et de réparer les anciens avec quelques fonctionnalités supplémentaires. Un nouveau membre de l'équipe pourrait venir perturber le panier de pommes en insistant sur le fait qu'il réécrit certains sous-systèmes du code. De nouveaux bogues sont créés et les utilisateurs d'un produit relativement stable sont contrariés parce que le logiciel, de son point de vue, devient le pire. Par conséquent, si votre objectif est la stabilité à long terme sans modification majeure des fonctionnalités, le refactoring majeur n'est souvent pas ce que vous recherchez. Si vous avez des changements de fonctionnalité plus importants dans le brochet, ayez une base d'utilisateurs qui s'attend à ce que votre produit ne soit pas encore complètement cuit (c'est-à-dire que vous êtes dans une sorte de bêta), alors c'est beaucoup mieux envisager un refactoring sérieux car les avantages à long terme de la conception supérieure seront payants et vous êtes moins susceptible de perturber une grande base d'utilisateurs.
Doug, refactoring sans une suite de tests unitaires établie pourrait bien être un risque élevé pour un nouvel œil sur le code, mais s'il existe une suite de tests unitaires, le risque peut être atténué quelque peu. – Kev
Tous les gestionnaires n'aiment pas l'idée de refactorisation. À leurs yeux, le temps nécessaire pour refactoriser n'est pas utilisé pour ajouter de nouvelles fonctionnalités. Vous devez donc convaincre votre responsable que vous en avez besoin ou vous pouvez le masquer lors de l'ajout de fonctionnalités. Ainsi, le risque est de prendre trop de temps pour refactoriser.
Un problème de refactoring survient lorsque vous ne pouvez pas modifier l'interface externe de vos classes. Dans ces cas, vous êtes très, très limité quant à ce que vous pouvez refactoriser.
Je ne suis pas certain que votre question soit valide. Vous posez des questions sur les limites du refactoring. Cependant, le refactoring implique la réécriture du code. Comment peut-il y avoir des limites à ce que vous réécrivez? Vous pouvez remplacer complètement l'ancien code au cours d'un refactoring massif, pièce par pièce. Effectivement, vous pouvez terminer le refactoring sans un seul caractère du code original, bien que cela soit vraiment extrême. Compte tenu de cette fin extrême des possibilités de refactoring, comment pouvez-vous supposer qu'il peut y avoir des limites?Si tout le code final peut être complètement nouveau, vous n'avez pas plus de limitations que si vous aviez écrit le code final à partir de zéro. Cependant, écrire le même code à partir de zéro vous donne moins de base pour continuer, moins de possibilités de développement itératif, et donc je dois répondre avec une contre-question: Est-ce que le refactoring n'a pas moins de limitation que n'importe quelle réécriture?
donc la question pour vous est, le code de réécriture peut-il être considéré refactoring? Fowlers l'a défini comme une manière disciplinée de nettoyer le code, donc je suppose que seules les modifications où vous êtes sûr qu'aucun comportement n'est modifié (basé sur un modèle) comptent comme refactoring – ilcavero
À l'excellente réponse de Kev - "Travailler efficacement avec le code hérité" par Michael Feathers devrait être une lecture obligatoire pour les personnes travaillant dans le génie logiciel.
Vous devriez écrire votre question un peu plus clairement. Voulez-vous dire la fonctionnalité de refactoring d'un IDE spécifique? – Horcrux7
OP pose des questions sur la méthodologie de refactoring. Le refactoring et l'IDE ne sont pas intrinsèquement liés. Oui, beaucoup d'IDE ont des helpers de refactoring mais c'est le code qui est refactorisé par le programmeur, pas les outils IDE. – Kev
peut-être que cela devrait être un wiki communautaire? –