Réconcilier la règle du boy-scout et la refactorisation opportuniste avec les revues de code
Je suis un grand partisan de la règle du scoutisme :
Vérifiez toujours un module plus propre que lorsque vous l'avez vérifié. "Quel que soit l'auteur d'origine, que se passe-t-il si nous faisons toujours des efforts, aussi petits soient-ils, pour améliorer le module. Quel serait le résultat? Je pense que si nous tous suivaient cette règle simple, nous verrions la fin de la détérioration incessante de nos systèmes logiciels. Au lieu de cela, nos systèmes iraient de mieux en mieux au fur et à mesure de leur évolution. Nous verrions également des équipes prendre soin du système dans son ensemble, plutôt que de simples personnes qui s'occupent de leur petite petite partie.
Je crois aussi beaucoup à l'idée connexe de Refactoring Opportuniste :
Bien qu'il y ait des places pour certains efforts de refactoring planifiés, je préfère encourager le refactoring comme une activité opportuniste, effectuée à tout moment et partout où le code doit être nettoyé - par qui que ce soit. Cela signifie qu'à tout moment, quelqu'un voit du code qui n'est pas aussi clair qu'il devrait l'être, il doit en profiter pour le corriger immédiatement - ou du moins en quelques minutes
Notez en particulier l'extrait suivant de l'article de refactoring:
Je me méfie de toutes les pratiques de développement qui causent des frictions pour une refactorisation opportuniste ... Mon sentiment est que la plupart des équipes ne font pas assez de refactoring, il est donc important de faire attention à tout ce qui décourage les gens de le faire. Pour aider à éliminer cela, sachez que chaque fois que vous vous sentez découragé de faire un petit refactoring, celui qui, vous en êtes sûr, ne prendra qu'une minute ou deux. Une telle barrière est une odeur qui devrait susciter une conversation. Prenez donc note du découragement et discutez-en avec l'équipe. À tout le moins, cela devrait être discuté lors de votre prochaine rétrospective.
Là où je travaille, il y a une pratique de développement qui provoque une friction lourde - Code Review (CR). Chaque fois que je change quelque chose qui n'est pas dans le cadre de ma "mission", mes critiques me reprochent de rendre le changement plus difficile à réviser. Cela est particulièrement vrai lorsque la refactorisation est impliquée, car elle rend difficile la comparaison des différences "ligne par ligne". Cette approche est la norme ici, ce qui signifie que le refactoring opportuniste est rarement effectué et que seul le refactoring "planifié" (qui est généralement trop peu, trop tard) a lieu, le cas échéant.
Je prétends que les avantages en valent la peine et que 3 examinateurs travailleront un peu plus dur (pour comprendre le code avant et après, plutôt que de regarder l'étendue étroite des lignes modifiées - l'examen lui-même serait mieux en raison de cela seul ) afin que les 100 prochains développeurs qui lisent et maintiennent le code en bénéficient. Quand je présente cet argument mes critiques, ils disent qu'ils n'ont aucun problème avec mon refactoring, tant qu'il n'est pas dans le même CR. Cependant, je prétends que c'est un mythe:
(1) La plupart du temps, vous ne réalisez quoi et comment vous souhaitez refactoriser que lorsque vous êtes au milieu de votre mission. Comme le dit Martin Fowler:
Au fur et à mesure que vous ajoutez la fonctionnalité, vous vous rendez compte que le code que vous ajoutez contient une certaine duplication avec du code existant, vous devez donc refactoriser le code existant pour nettoyer les choses ... Vous pouvez obtenir que quelque chose fonctionne, mais réalisez que ce serait mieux si l'interaction avec les classes existantes était modifiée. Profitez-en pour le faire avant de vous considérer comme terminé.
(2) Personne ne vous regardera favorablement en libérant des CR "refactoring" que vous n'étiez pas censé faire. Un CR a une certaine surcharge et votre manager ne veut pas que vous "perdiez votre temps" à refactoriser. Lorsqu'il est fourni avec le changement que vous êtes censé faire, ce problème est minimisé.
Le problème est exacerbé par Resharper, car chaque nouveau fichier que j'ajoute au changement (et je ne peux pas savoir à l'avance exactement quels fichiers finiraient par être modifiés) est généralement jonché avec des erreurs et des suggestions - dont la plupart sont parfaits et méritent d'être réparés.
Le résultat final est que je vois un code horrible, et je le laisse juste là. Ironiquement, je pense que la correction d'un tel code non seulement n'améliorera pas mon classement, mais en fait les diminuera et me peindra comme le gars "flou" qui perd son temps à réparer des choses dont personne ne se soucie au lieu de faire son travail. Je me sens mal à ce sujet parce que je méprise vraiment le mauvais code et ne supporte pas de le regarder, sans parler de l'appeler à partir de mes méthodes!
Avez-vous des idées sur la façon de remédier à cette situation?
OK, il y a donc maintenant plus de choses que ce qui convient pour un commentaire.
tl; dr
Votre intuition sur ce que vous devez faire (refactoring au fur et à mesure) est correcte.
Votre difficulté à implémenter cela - étant donné que vous devez contourner un mauvais système de révision de code - se résume à votre difficulté à manipuler votre code source et VCS. Plusieurs personnes ont dit que vous pouvez et devriez diviser vos modifications (oui, même dans les fichiers) en plusieurs validations, mais vous semblez avoir du mal à y croire.
Vous pouvez vraiment faire cela. C'est vraiment ce que nous proposons. Vous devriez vraiment apprendre à tirer le meilleur parti de vos outils d'édition, de manipulation des sources et de contrôle de version. Si vous consacrez du temps à apprendre à bien les utiliser, cela vous facilitera la vie.
Problèmes de politique de workflow/bureautique
Je ferais essentiellement la même recommandation que GlenH7 que vous créiez deux commits - un avec seulement des refactorings et (manifestement ou évidemment) aucun changement fonctionnel, et un avec les changements fonctionnels en question.
Il peut cependant être utile, si vous trouvez lots d'erreurs, de choisir une seule catégorie d'erreur à corriger dans un seul CR. Ensuite, vous avez un commit avec un commentaire comme "code de déduplication", "correction des erreurs de type X", ou autre chose. Parce que cela ne fait qu'un seul type de changement, vraisemblablement à plusieurs endroits, il devrait être trivial à revoir. Cela signifie que vous ne pouvez pas corriger toutes les erreurs que vous trouvez, mais peut rendre la contrebande moins pénible.
Problèmes VCS
Le fractionnement des modifications apportées à votre source de travail en plusieurs validations ne devrait pas être un défi. Vous n'avez pas dit ce que vous utilisez, mais les flux de travail possibles sont les suivants:
si vous utilisez git, vous disposez d'excellents outils pour cela
- vous pouvez utiliser
git add -ipour une mise en scène interactive à partir de la ligne de commande - vous pouvez utiliser
git guiet sélectionnez les morceaux et les lignes individuels à mettre en scène (c'est l'un des rares outils GUI liés à VCS que je préfère en fait à la ligne de commande, l'autre étant un bon éditeur de fusion à 3 voies) - vous pouvez effectuer de nombreuses minuscules validations (modifications individuelles ou correction de la même classe de bogues à plusieurs endroits), puis les réorganiser, les fusionner ou les diviser avec
rebase -i
- vous pouvez utiliser
si vous n'utilisez pas git, votre VCS peut toujours avoir des outils pour ce genre de chose, mais je ne peux pas vous conseiller sans savoir quel système vous utilisez
Vous avez mentionné que vous utilisez TFS - qui, je pense, est compatible avec git depuis TFS2013. Il peut être utile d'expérimenter l'utilisation d'un clone git local du référentiel pour fonctionner. Si cela est désactivé ou ne fonctionne pas pour vous, vous pouvez toujours importer la source dans un référentiel git local, y travailler et l'utiliser pour exporter vos validations finales.
vous pouvez le faire manuellement dans n'importe quel VCS si vous avez accès à des outils de base comme
diffetpatch. C'est plus douloureux, mais certainement possible. Le flux de travail de base serait:- effectuez toutes vos modifications, testez, etc.
- utilisez
diffpour créer un fichier correctif (contextuel ou unifié) avec toutes les modifications depuis le dernier commit - partitionnez cela en deux fichiers: vous vous retrouverez avec un fichier patch contenant des refactorings et un avec des changements fonctionnels
- ce n'est pas tout à fait trivial - des outils tels que le mode diff emacs peuvent aider
- sauvegarder tout
- revenir au dernier commit, utiliser
patchpour rejouer l'un des fichiers de patch, valider ces modifications- NB. si le correctif ne s'applique pas correctement, vous devrez peut-être corriger manuellement les morceaux défectueux
- répéter 5 pour le deuxième fichier de patch
Vous avez maintenant deux validations, vos modifications étant partitionnées de manière appropriée.
Notez qu'il existe probablement des outils pour faciliter cette gestion des correctifs - je ne les utilise tout simplement pas car git le fait pour moi.
Je vais supposer que les demandes de changement sont importantes et formelles dans votre entreprise. Sinon, effectuez simplement les modifications (si possible) en de nombreux petits commits (comme vous êtes censé le faire).
Avez-vous des idées sur la façon de remédier à cette situation?
Continuez à faire ce que vous faites?
Je veux dire, toutes vos pensées et déductions sont entièrement correctes. Vous devez réparer les choses que vous voyez. Les gens ne font pas assez de refactorisation planifiée. Et cet avantage pour l'ensemble du groupe est plus important que d'en incommoder quelques-uns.
Ce qui peut aider, c'est d'être moins combatif. Les révisions de code ne devraient pas être combatives "Pourquoi avez-vous fait ça?", Elles devraient être collaboratives "Hé les gars, pendant que j'étais ici, j'ai arrangé tout ça!". Travailler (avec votre lead/manager si possible) pour changer cette culture est difficile, mais assez vital pour créer une équipe de développement performante.
Vous pouvez également travailler (avec votre chef/gestionnaire si possible) pour faire valoir l'importance de ces idées avec vos collègues. Faites-le vous demander "pourquoi ne vous souciez-vous pas de la qualité?" au lieu de leur demander "pourquoi faites-vous toujours ces choses inutiles?".
J'ai beaucoup de sympathie pour votre situation, mais peu de suggestions concrètes. Si rien d'autre, je vais peut-être vous convaincre que, aussi mauvaise soit une situation, elle pourrait être pire. Cela peut TOUJOURS être pire. :-)
Tout d'abord, je pense que vous avez (au moins) deux problèmes avec votre culture, pas un seul. Un problème est l'approche de la refactorisation, mais les revues de code semblent être un problème distinct. Je vais essayer de séparer mes pensées.
Revues de code
J'étais dans un groupe qui détestait les revues de code. Le groupe a été formé en fusionnant deux groupes de parties distinctes de l'entreprise. Je venais du groupe qui faisait des revues de code depuis plusieurs années, avec généralement de bons résultats. La plupart d'entre nous pensaient que les révisions de code étaient une bonne utilisation de notre temps. Nous avons fusionné en un plus grand groupe, et pour autant que nous puissions le dire, cet "autre" groupe n'avait même jamais entendu parler des révisions de code. Maintenant, nous travaillions tous sur "leur" base de code.
Les choses allaient mal lorsque nous avons fusionné. Les nouvelles fonctionnalités étaient en retard de 6 à 12 mois, année après année. L'arriéré de bogues était énorme, croissant et épuisant. La propriété du code était forte, en particulier parmi les "gourous" les plus âgés. Les "branches de fonctionnalités" duraient parfois des années et s'étalaient sur quelques versions; parfois NOBODY mais un seul développeur a vu le code avant qu'il n'atteigne la branche principale. En fait, "branche de fonctionnalité" est trompeuse, car elle suggère que le code était quelque part dans le référentiel. Le plus souvent, c'était uniquement sur le système individuel du développeur.
La direction a convenu que nous devions "faire quelque chose" avant que la qualité ne devienne trop faible. :-) Leur réponse a été la révision des codes. Les revues de code sont devenues un élément officiel de "Thou Shalt", précédant chaque enregistrement. L'outil que nous avons utilisé était Review Board.
Comment cela a-t-il fonctionné dans la culture que j'ai décrite? Mieux que rien, mais c'était douloureux et il a fallu plus d'un an pour atteindre une sorte de niveau minimal de conformité. Certaines choses que nous avons observées:
- L'outil que vous utilisez a tendance à concentrer les révisions de code de certaines manières. Cela peut être un problème. Review Board vous offre de jolis différences colorées ligne par ligne et vous permet de joindre des commentaires à une ligne. Cela fait que la plupart des développeurs ignorent toutes les lignes qui n'ont pas changé. C'est bien pour de petits changements isolés. Ce n'est pas si bon pour les grands changements, les gros morceaux de nouveau code ou le code qui a 500 instances d'une fonction renommée mélangée à 10 lignes de nouvelles fonctionnalités.
- Même si nous étions dans une ancienne base de code malade qui n'avait pour la plupart jamais été révisée auparavant, il est devenu "impoli" pour un critique de commenter tout ce qui n'était PAS une ligne de changement, même pour signaler un bug évident. "Ne me dérange pas, c'est un check-in important et je n'ai pas le temps de corriger les bugs."
- Achetez un critique "facile". Certaines personnes examineront une revue de 10 fichiers avec 2000 lignes modifiées pendant 3 minutes et cliqueront sur "Expédier!". Tout le monde apprend rapidement qui sont ces personnes. Si vous ne voulez vraiment pas que votre code soit révisé en premier lieu, envoyez-le à un réviseur "facile". Votre enregistrement ne sera pas ralenti. Vous pouvez retourner la faveur en devenant un réviseur "facile" pour son code.
- Si vous détestez les révisions de code, ignorez simplement les courriels que vous recevez de Review Board. Ignorez les suivis des membres de votre équipe. Pendant des semaines. Jusqu'à ce que vous ayez 3 douzaines d'avis ouverts dans votre file d'attente et que votre nom apparaisse plusieurs fois dans les réunions de groupe. Devenez ensuite un réviseur "facile" et supprimez toutes vos critiques avant le déjeuner.
- Évitez d'envoyer votre code à un réviseur "dur". (Le genre de développeur qui poserait ou répondrait à une question comme celle-ci.) Tout le monde apprend rapidement qui sont les critiques "durs", tout comme ils apprennent les plus faciles. Si les révisions de code sont une perte de temps (™), lire des commentaires détaillés sur le code que vous possédez est à la fois une perte de temps (™) et une insulte.
- Lorsque les révisions de code sont douloureuses, les gens les repoussent et continuent à écrire plus de code. Vous obtenez moins de revues de code, mais chacune est GRANDE. Vous avez besoin de révisions de code plus nombreuses et plus petites, ce qui signifie que l'équipe doit trouver comment les rendre aussi indolores que possible.
Je pensais que j'allais écrire quelques paragraphes sur les revues de code, mais il s'avère que j'écrivais principalement sur la culture. Je suppose que cela se résume à ceci: les revues de code peuvent être bonnes pour un projet, mais une équipe n'obtient que les avantages qu'elle mérite.
Refactoring
Mon groupe méprisait-il le refactoring encore plus qu'il détestait les révisions de code? Bien sûr! Pour toutes les raisons évidentes déjà évoquées. Vous perdez mon temps avec une révision de code icky, et vous n'ajoutez même pas de fonctionnalité ou corrigez un bug!
Mais le code avait toujours désespérément besoin d'être refactorisé. La façon de procéder?
- Ne mélangez jamais un changement de refactoring avec un changement fonctionnel. Un certain nombre de personnes ont mentionné ce point. Si les revues de code sont un point de friction, n'augmentez pas la friction. C'est plus de travail, mais vous devez prévoir un examen séparé et un enregistrement séparé.
- Commencer petit. Très petit. Encore plus petit que ça. Utilisez de très petits refactorings pour enseigner progressivement aux gens que le refactoring et les révisions de code ne sont pas du mal. Si vous pouvez vous faufiler dans un minuscule refactoring par semaine sans trop de douleur, dans quelques mois, vous pourrez peut-être vous en tirer avec deux par semaine. Et ils peuvent être un peu plus gros. Mieux que rien.
- Nous n'avons eu essentiellement AUCUN test unitaire. Le refactoring est donc interdit, non? Pas nécessairement. Pour certaines modifications, le compilateur est votre test unitaire. Concentrez-vous sur les refactorisations que vous pouvez tester. Évitez les modifications si elles ne peuvent pas être testées. Peut-être passez-vous plutôt du temps à écrire des tests unitaires.
- Certains développeurs ont peur de refactoriser car ils ont peur de TOUS les changements de code. Il m'a fallu beaucoup de temps pour reconnaître ce type. L'écrire un morceau de code, jouer avec lui jusqu'à ce qu'il "fonctionne", puis ne voulez JAMAIS le changer. Ils ne comprennent pas nécessairement POURQUOI cela fonctionne. Le changement est risqué. Ils ne se font pas confiance pour faire TOUT changement, et ils ne vous feront certainement pas confiance. Le refactoring est censé concerner de petits changements sûrs qui ne modifient pas le comportement. Il y a des développeurs pour qui l'idée même d'un "changement qui ne modifie pas le comportement" est inconcevable . Je ne sais pas quoi suggérer dans ces cas. Je pense que vous devez essayer de travailler dans des domaines qui ne les intéressent pas. J'ai été surpris quand j'ai appris que ce type peut avoir une carrière longue et stable en tant que développeur de logiciels.
Pourquoi ne faites-vous pas les deux, mais avec des commits séparés?
Vos pairs ont raison. Un examen du code doit évaluer le code qui a été modifié par quelqu'un d'autre. Vous ne devez pas toucher le code que vous révisez pour quelqu'un d'autre car cela biaiserait votre rôle de réviseur.
Mais si vous voyez un certain nombre de problèmes flagrants, vous pouvez suivre deux options.
Si la révision du code était correcte, autorisez la partie que vous avez examinée à être validée, puis refactorisez le code lors d'un deuxième enregistrement.
Si l'examen du code présentait des problèmes qui devaient être corrigés, demandez au développeur de refactoriser en fonction des recommandations de Resharper.
Personnellement, je déteste l'idée des revues de code post-commit. La révision du code doit avoir lieu lorsque vous apportez des modifications au code. Ce dont je parle bien sûr ici, c'est de la programmation par paires. Lorsque vous vous associez, vous obtenez la révision gratuitement et vous obtenez une meilleure révision du code. Maintenant, j'exprime mon opinion ici, je sais que d'autres partagent cela, il y a probablement des études qui le prouvent.
Si vous pouvez amener vos réviseurs de code à s'associer avec vous, l'élément combatif de la révision de code devrait s'évaporer. Lorsque vous commencez à effectuer un changement qui n'est pas compris, la question peut être soulevée au moment du changement, discutée et des alternatives explorées, ce qui peut conduire à de meilleurs remaniements. Vous obtiendrez une révision de code de meilleure qualité car la paire sera en mesure de comprendre la portée plus large du changement, et de ne pas se concentrer autant sur les changements ligne par ligne, ce qui est ce que vous obtenez avec la comparaison de code côte à côte.
Bien sûr, ce n'est pas une réponse directe au problème des refactorings étant en dehors de la portée du changement en cours d'élaboration, mais je m'attendrais à ce que vos pairs comprennent mieux le raisonnement derrière les changements s'ils étaient là lorsque vous avez fait le changement.
En passant, en supposant que vous faites du TDD ou une certaine forme de refactor rouge vert, une façon de vous assurer que vous obtenez l'engagement de votre pair est d'utiliser la technique d'appariement de ping-pong. Expliqué simplement lorsque le pilote tourne pour chaque étape du cycle RGR, c'est-à-dire que la paire 1 écrit un test qui échoue, la paire 2 le corrige, la paire 1 refacteurs, la paire 2 écrit un test qui échoue ... et ainsi de suite.
Ce problème reflète probablement un problème beaucoup plus important avec la culture organisationnelle. Les gens semblent plus intéressés à faire "son travail" correctement qu'à améliorer le produit, probablement cette entreprise a une culture de "blâme" au lieu d'une culture de collaboration et les gens semblent plus intéressés à se couvrir que d'avoir une vision globale du produit/de l'entreprise .
À mon avis, vous avez tout à fait raison, les personnes qui examinent votre code ont complètement tort si elles se plaignent parce que vous "touchez" des choses en dehors de "votre mission", essayez de convaincre ces personnes mais ne soyez jamais contre vos principes, pour moi c'est la qualité la plus importante d'un vrai professionnel.
Et si la bonne chose vous donne de mauvais chiffres d'une manière stupide pour évaluer votre travail, quel est le problème?, Qui veut "gagner" ce jeu d'évaluation dans une entreprise folle?, Essayez de le changer !, et si c'est impossible ou vous êtes fatigué, trouvez un autre endroit, mais ne soyez jamais contre vos principes, c'est le meilleur que vous ayez.
Parfois, la refactorisation est une mauvaise chose. Pas pour les raisons que donnent vos réviseurs de code; il semble qu'ils ne se soucient pas vraiment de la qualité du code, et vous vous en souciez , ce qui est génial. Mais il y a deux raisons qui devraient vous empêcher de refactoring: 1. Vous ne pouvez pas tester les modifications que vous avez apportées avec des tests automatisés (tests unitaires ou autre) ou 2. Vous apportez des modifications à du code que vous ne comprenez pas très bien; c'est-à-dire que vous n'avez pas les connaissances spécifiques au domaine pour savoir quels changements vous devez apporter.
1. Ne refactorisez pas lorsque vous ne pouvez pas tester les modifications que vous avez apportées avec des tests automatisés.
La personne qui effectue votre révision de code doit être en mesure de s'assurer que les modifications que vous avez apportées ne cassent rien qui fonctionnait auparavant. C'est la principale raison de laisser le code de travail seul. Oui, il serait certainement préférable de refaçonner cette fonction longue de 1000 lignes (c'est vraiment une abomination!) En un tas de fonctions, mais si vous ne pouvez pas automatiser vos tests, il peut être très difficile de convaincre les autres que vous avez tout fait droite. J'ai définitivement fait cette erreur auparavant.
Avant de refactoriser, assurez-vous qu'il y a des tests unitaires. S'il n'y a pas de tests unitaires, écrivez-en! Refactorisez ensuite et vos réviseurs de code n'auront aucune excuse (légitime) pour être contrarié.
Ne refacturez pas les morceaux de code qui nécessitent des connaissances spécifiques au domaine que vous n'avez pas.
L'endroit où je travaille a beaucoup de code lourd en génie chimique. La base de code utilise les idiomes communs aux ingénieurs chimistes. N'apportez jamais de modifications idiomatiques à un champ. Cela peut sembler une bonne idée de renommer une variable appelée x en molarConcentration, mais devinez quoi? Dans tous les textes de chimie, la concentration molaire est représentée par un x. Le renommer rend plus difficile de savoir ce qui se passe réellement dans le code pour les personnes dans ce domaine.
Au lieu de renommer des variables idiomatiques, mettez simplement des commentaires expliquant ce qu'elles sont. Si elles sont pas idiomatiques, veuillez les renommer. Ne laissez pas les i, j, k, x, y, etc. flotter quand de meilleurs noms fonctionneront.
Règle générale pour les abréviations: si, lorsque les gens parlent, ils utilisent une abréviation, il est acceptable d'utiliser cette abréviation dans le code. Exemples de la base de code au travail:
Nous avons les concepts suivants que nous abrégons toujours lorsque nous en parlons: "Zone de préoccupation" devient "AOC", "Explosion de nuage de vapeur" devient VCE, des trucs comme ça. Dans notre base de code, quelqu'un a refactorisé toutes les instances appelées aoc à AreaOfConcern, VCE à vaporCloudExplosion, nPlanes à confiningPlanesCount ... ce qui a rendu le code beaucoup plus difficile à lire pour les personnes qui avaient les connaissances spécifiques au domaine. J'ai aussi été coupable de faire des trucs comme ça.
Cela ne s'applique peut-être pas du tout à votre situation, mais je pense à ce sujet.
Cette question présente désormais deux problèmes distincts: la facilité de révision des modifications dans les révisions de code et le temps consacré à la refactorisation.
Là où je travaille, il y a une pratique de développement qui cause de fortes frictions - Code Review (CR). Chaque fois que je change quelque chose qui n'est pas dans le cadre de ma "mission", mes critiques me reprochent de rendre le changement plus difficile à réviser.
Comme d'autres réponses l'ont dit - pouvez-vous séparer les enregistrements de refactoring des enregistrements de changement de code (pas nécessairement en tant qu'examens séparés)? En fonction de l'outil que vous utilisez pour effectuer la révision du code, vous devriez être en mesure d'afficher les différences entre des révisions spécifiques uniquement (Atlassian's Crucible le fait certainement).
(2) Personne ne vous regardera favorablement en libérant des CR "refactoring" que vous n'étiez pas censé faire. Un CR a une certaine surcharge et votre manager ne veut pas que vous "perdiez votre temps" à refactoriser. Lorsqu'il est fourni avec le changement que vous êtes censé faire, ce problème est minimisé.
Si le refactoring est simple et rend le code plus facile à comprendre (ce qui est tout ce que vous devriez faire s'il ne s'agit que d'un refactoring), la révision du code ne devrait pas prendre longtemps et devrait être une surcharge minimale qui est récupérée à la pelle lorsque quelqu'un doit venir revoir le code à l'avenir. Si vos patrons ne sont pas en mesure de résoudre ce problème, vous devrez peut-être les pousser doucement vers certaines ressources qui expliquent pourquoi la règle du scoutisme conduit à une relation plus productive avec votre code. Si vous pouvez les convaincre que la "perte [de] votre temps" permettra désormais d'économiser deux, cinq ou dix fois plus tard lorsque vous/quelqu'un d'autre reviendra pour travailler plus sur ce code, alors votre problème devrait disparaître.
Le problème est exacerbé par Resharper, car chaque nouveau fichier que j'ajoute à la modification (et je ne peux pas savoir à l'avance exactement quels fichiers finiraient par être modifiés) est généralement jonché d'erreurs et de suggestions - dont la plupart sont sur place et méritent totalement fixation.
Avez-vous essayé de porter ces problèmes à l'attention de vos collègues et de discuter de la raison pour laquelle ils méritent d'être résolus? Et certains d'entre eux peuvent-ils être corrigés automatiquement (en supposant que vous avez une couverture de test suffisante pour confirmer que vous n'avez pas cassé des choses avec le refactoring automatisé)? Parfois, ce n'est pas "la peine de votre temps" pour effectuer une refactorisation si c'est vraiment truc pointilleux. Est-ce que toute votre équipe utilise ReSharper? Si tel est le cas, avez-vous une politique commune sur les avertissements/règles appliqués? Si ce n'est pas le cas, vous devriez peut-être à nouveau démontrer où l'outil vous aide à identifier les zones du code qui sont des sources possibles de douleur future.
Moi aussi, je crois beaucoup à la règle du boyscout et au refactoring opportuniste. Le problème est souvent d'obtenir l'adhésion de la direction. Le refactoring s'accompagne à la fois de risques et de coûts. Ce que la direction oublie souvent, c'est que la dette technique aussi.
C'est la nature humaine. Nous sommes habitués à faire face à de vrais problèmes, pas à les éviter. Nous sommes réactifs, pas proactifs.
Le logiciel est intangible et il est donc difficile de comprendre que, comme une voiture, il a besoin d'entretien. Aucune personne raisonnable n'achèterait une voiture et ne la réparerait jamais. Nous acceptons qu'une telle négligence réduise sa longévité et, à long terme, soit plus coûteuse.
Malgré le fait que de nombreux managers le comprennent, ils sont tenus responsables des modifications apportées au code de production. Il y a des politiques qui facilitent le fait de partir assez bien seul. Souvent, la personne qui a besoin de convaincre est en fait au-dessus de votre manager et il ne veut tout simplement pas se battre pour mettre en production vos "bonnes idées".
Pour être honnête, votre manager n'est pas toujours convaincu que votre remède est, en fait, aussi grand que vous le pensez. (Huile de serpent?) Il y a de la vente. C'est votre travail de l'aider à voir les avantages.
La direction ne partage pas vos priorités. Mettez votre chapeau de gestion et voyez avec les yeux de la direction. Vous trouverez plus probablement le bon angle. Être persistant. Vous effectuerez plus de changements en ne permettant pas à la première réponse négative de vous dissuader.
Je me souviens il y a environ 25 ans de "nettoyer" le code sur lequel je travaillais à d'autres fins, principalement en reformatant les blocs de commentaires et les alignements de tabulations/colonnes pour rendre le code net et donc plus facile à comprendre (pas de changements fonctionnels réels) . Il m'arrive de comme un code propre et bien ordonné. Eh bien, les développeurs seniors étaient furieux. Il s'est avéré qu'ils utilisaient une sorte de comparaison de fichiers (diff) pour voir ce qui avait changé, par rapport à leurs copies personnelles du fichier, et maintenant cela donnait toutes sortes de faux positifs. Je dois mentionner que notre bibliothèque de codes était sur un ordinateur central et n'avait aucun contrôle de version - vous avez essentiellement écrasé tout ce qui était là, et c'est tout.
La morale de l'histoire? Je ne sais pas. Je suppose que c'est parfois que vous ne pouvez plaire à personne sauf à vous. Je ne perdais pas de temps (à mes yeux) - le code nettoyé était plus facile à lire et à comprendre. C'est juste que les outils de contrôle des changements primitifs utilisés par d'autres ont mis un peu de travail supplémentaire sur eux. Les outils étaient trop primitifs pour ignorer l'espace/tabulation et les commentaires redistribués.
Si vous pouvez diviser la modification demandée et le réorganisateur non demandé en (beaucoup) de validations distinctes, comme l'ont noté @Useless, @Telastyn et d'autres, alors c'est le mieux que vous puissiez faire. Vous travaillerez toujours sur un seul CR, sans la surcharge administrative de création d'un "refactoring". Gardez vos engagements petits et concentrés.
Au lieu de vous donner quelques conseils sur la façon de le faire, je préfère vous indiquer une explication beaucoup plus large (en fait, un livre) d'un spécialiste. De cette façon, vous pourrez en apprendre beaucoup plus. Lire Travailler efficacement avec Legacy Code (par Michael Feathers). Ce livre peut vous apprendre à faire le refactoring, entrelacé avec les changements fonctionnels.
Les sujets traités comprennent:
- Comprendre les mécanismes du changement logiciel: ajout de fonctionnalités, correction de bogues, amélioration de la conception, optimisation des performances
- Mise en place du code hérité dans un faisceau de test
- Écrire des tests qui vous protègent contre l'introduction de nouveaux problèmes
- Techniques pouvant être utilisées avec n'importe quel langage ou plate-forme, avec des exemples en Java, C++, C et C #
- Identifier avec précision où les changements de code doivent être effectués
- Faire face aux systèmes hérités qui ne sont pas orientés objet
- Gérer les applications qui ne semblent pas avoir de structure
Ce livre comprend également un catalogue de vingt-quatre techniques de rupture de dépendance qui vous aident à travailler avec des éléments de programme de manière isolée et à apporter des modifications plus sûres.
Si vous pouvez diviser le changement demandé et le refactor non demandé en deux demandes de changement distinctes, comme l'a noté @ GlenH7, alors c'est le mieux que vous puissiez faire. Vous n'êtes alors pas "le gars qui perd du temps" mais "le gars qui travaille deux fois plus dur".
Si vous vous retrouvez souvent dans une situation où vous ne pouvez pas les séparer, car le travail demandé a maintenant besoin du refactor non demandé pour être compilé, je suggère que vous insistiez pour avoir des outils pour vérifier automatiquement les normes de codage, en utilisant les arguments décrits ici (les avertissements Resharper à eux seuls peuvent être un bon candidat, je ne le connais pas). Ces arguments sont tous valides, mais il y a un extra que vous pouvez utiliser à votre avantage: avoir ces tests en fait maintenant votre devoir de passer les tests chaque commit.
Si votre entreprise ne veut pas "perdre du temps à refactoriser" (un mauvais signe de sa part), alors elle doit vous fournir un fichier "suppression d'avertissement" (chaque outil a son propre mécanisme) pour ne plus vous ennuyer avec ces avertissements. Je dis cela afin de vous fournir des options pour différents scénarios, même dans le pire des cas. Il est également préférable d'avoir des accords clairement définis entre vous et votre entreprise, également sur la qualité attendue du code, plutôt que des hypothèses implicites de chaque côté.