Comment encourager une équipe à refactoriser
Je fais partie d'une équipe de ~ 20 personnes qui fait partie d'une très grande organisation. Nous utilisons la même base de code depuis environ 5 ans et en avons publié plusieurs projets dérivés.
J'ai eu quelques conversations 1: 1 avec des membres de l'équipe et la plupart d'entre eux sont également conscients des différentes odeurs de code et ne les aiment pas, mais le refactoring se produit rarement car il y a toujours quelque chose de plus important à faire. J'ai également demandé à la direction si nous pouvions avoir une planification ou un nettoyage plus délibéré de la base de code, mais on m'a essentiellement dit non. Tout le monde dans l'équipe programme à sa manière et il n'y a pas de coordination.
Je ne demande pas ici des techniques de refactoring; Je demande quelles sont les façons dont je peux aider à créer une culture de l'écriture pour la maintenabilité plutôt que la pure fonctionnalité. Remarque: je ne suis pas un gestionnaire, je ne peux donc pas simplement dicter des choses.
Ne demandez pas à la direction la permission de refactoriser. Ce n'est pas leur affaire. Vous pourriez tout aussi bien demander la permission d'aiguiser un crayon.
La direction ne comprend pas le refactoring. Ce n'est pas un besoin commercial. La direction ne devrait pas avoir besoin de le comprendre. Ce n'est pas leur travail. C'est le tien.
Le refactoring est un outil que vous utilisez pour satisfaire les besoins des directions. Ne demandez pas à la direction d'y penser. Je serais très inquiet si mon mécanicien me demandait quelle marque de clé utiliser sur ma voiture. Préoccupé, pas par l'outil, mais par le mécanicien.
Ce que vous devez faire, c'est conduire cette équipe vers de bonnes pratiques. Ne demandez pas à la direction de dicter cela. Même s'ils essaient, ils ne feront que le gâcher.
Vous devez établir la confiance avec l'équipe, leur montrer les avantages et les coûts et accepter que le changement ne se produise pas instantanément.
Parfois, une préoccupation transversale traverse de nombreuses classes et nécessite une refonte. Parfois, vous ne pouvez tout simplement pas justifier de le faire maintenant parce que maintenant vous avez juste besoin que cette petite chose soit modifiée.
Ça fait mal. Vous devez vivre avec travailler dans du code merde parce que vous n'avez tout simplement pas le temps. Cela prend donc de plus en plus longtemps.
Abe Lincoln est souvent cité comme disant: "Donnez-moi six heures pour abattre un arbre et je passerai les quatre premiers à affûter la hache."
Lorsque vous traitez avec la direction, ne préconisez pas d'aiguiser la hache. Discutez pour les six heures. Ne vous attendez pas à obtenir du crédit pour affûter la hache. Ne le faites pas du tout pour la direction. Faites-le pour ne passer que deux heures à combattre ce foutu arbre.
Comprenez la différence entre un simple refactoriseur et une réécriture. Trop souvent, les gens utilisent le mot "refactor" lorsque cela signifie vraiment une réécriture ciblée. Pensez à la différence de cette façon (par ordre de risque):
- Le refactoring est un petit changement facilement inversé qui n'a pas d'impact fonctionnel
- La réécriture ciblée est une réécriture ciblée d'un aspect d'une application qui affecte plusieurs parties du code
- La réécriture à pleine échelle jette l'ancien code source et recommence à zéro
La raison de la distinction ici est que certains correctifs de code ont un réel impact sur le calendrier. Chaque fois que vous voulez faire quelque chose qui a un impact sur le calendrier, vous avez besoin de l'adhésion. Il existe un moyen d'obtenir ce buy-in, mais vous devez le vendre comme une opportunité.
La refactorisation devrait être quelque chose que vous faites comme bonne pratique. Comme un boy-scout quitte son camping en meilleur état qu'il ne l'a trouvé (en nettoyant le gâchis des autres), ça arrive juste. De nombreux Java et C # IDE sont livrés avec des outils de refactoring intégrés, donc peu de choses comme le réordonnancement des listes de paramètres et le changement de nom du code sont mises à jour dans l'ensemble de l'application. Tant que ce que vous modifiez est un interne API (pas quelque chose avec lequel des tiers interagissent) il n'y a aucune restriction pratique.
Je pense qu'il est important de se rendre compte qu'une série de refactorisations bien ciblées peuvent avoir le même effet qu'une réécriture ciblée, mais sans le même niveau de risque. Je crois également que si vous ne pouvez pas faire d'autre travail dans un sprint autre que ce que vous appelez une refactorisation, ce dont vous parlez vraiment est une réécriture ciblée. Vous ne pouvez pas engager de l'argent de projet (c'est-à-dire du temps de développeur à faire une chose contre quelque chose d'autre) à quelque chose avec un impact aussi important sans l'adhésion des personnes dont les emplois sont en jeu. Un refactoring est le type de travail qui n'entraînera pas le respect des délais du produit.
Les réécritures ciblées doivent être définies et planifiées. C'est comme rénover une cuisine où il faut abattre un mur. Il y a des choses que vous devez faire pour prendre en charge l'infrastructure existante jusqu'à ce que le travail soit terminé et qu'une nouvelle prise en charge soit ajoutée. C'est généralement un niveau de risque acceptable qui comporte des avantages que vous n'aviez pas auparavant. Le code est en désordre pendant le processus, mais lorsqu'il est terminé, l'application dans son ensemble est mieux lotie.
La meilleure façon de vendre la réécriture ciblée est de la définir en fonction des nouvelles fonctionnalités que la réécriture permettra à votre équipe de réaliser.
Les réécritures à l'échelle entière doivent être évitées à moins qu'il n'y ait vraiment aucune option. C'est comme démolir une maison avant de la remplacer par quelque chose de complètement différent. À moins que vous ne sachiez très bien comment cette maison a été utilisée, vous courez le risque que la nouvelle maison ne réponde pas aux besoins du client.
Il y a des moments où une réécriture à grande échelle est en effet nécessaire, mais il faut beaucoup de recherche pour s'assurer que vous répondez à tous les besoins actuels de votre client lorsque vous avez terminé. Il y a beaucoup de détails qui existent dans le code existant qui a été écrit pour une fonctionnalité oubliée depuis longtemps qui est toujours importante. Il existe également des stratégies pour ce type de travail.
Un concept pour les réécritures à l'échelle entière consiste à utiliser le étrangleurmotif . Essentiellement, vous construisez la nouvelle application à côté de l'ancienne et utilisez la nouvelle lorsque vous le pouvez. De moins en moins de l'ancienne application existe, jusqu'à ce qu'elle soit entièrement remplacée. Cela permet au client de fournir des commentaires afin que vous ne manquiez aucun détail critique.
La refactorisation doit se produire dans le cadre du développement. Lorsque vous changez de comportement ou ajoutez une nouvelle fonctionnalité, le code affecté doit, si nécessaire, être refactorisé pour prendre en charge le changement proprement. Suivez la règle du boy-scout: laissez toujours le code en meilleur état que vous ne l'avez trouvé.
Vous ne devez pas refactoriser le code qui n'a pas besoin de changements de comportement. Vous ne devez pas effectuer de refactoring qui n'est pas lié à un bugfix ou à un nouveau développement. Ne pas estimer ou planifier la refactorisation séparément du développement. Comme l'écriture de tests unitaires et la révision de code, cela devrait être une partie naturellement intégrée de tout développement, pas une option négociable séparée.
Vous encouragez la refactorisation dans le cadre de la révision du code. Posez simplement la question simple si le code après le changement est au moins aussi propre que le code avant le changement. Sinon, améliorez-le avant de valider le code.
Ne soyez pas perfectionniste - du moins pas au début. Tant que chaque commit améliore un peu le code, les choses s'amélioreront à long terme.
Il est presque impossible de convaincre une entreprise de refactoriser, car les clients ne paieront pas pour le refactoring, mais les développeurs veulent toujours être payés pour le faire.
Je vous renvoie la question. Pourquoi vous voulez-vous refactoriser?
Améliorez le produit final
La refactorisation par définition ne signifie aucune modification du produit final. C'est donc un non starter
Accélérez le développement
Un choix populaire, "Si nous refactorisons cela, il sera plus facile de changer à l'avenir!". Bien sûr, une amélioration de 10% de la vitesse prendra 10 fois plus de temps avant de commencer à voir un retour. Il est difficile de montrer des chiffres qui correspondent à une victoire nette.
Autoriser les développeurs à programmer de la dernière façon?
C'est bien sûr la peur de la gestion, que les développeurs veulent juste de nouveaux jouets. Mais vous pouvez le faire tourner. "Nous sommes une entreprise technologique! À moins que nous n'utilisions les dernières nouveautés et que nous ne fassions les choses correctement, personne ne respectera nos produits. Nous devons être considérés comme à la pointe"
Dans quelle entreprise est votre entreprise?
Applications/sites Web sur mesure à commander
Il n'y a tout simplement aucune justification à la refactorisation, à moins que le client ne le demande spécifiquement ou que vous ayez besoin de changer de technologie pour mettre en œuvre leur exigence
Produit de base interne, par exemple. site e-commerce
Les principales préoccupations sont la fiabilité et les nouvelles fonctionnalités. "Refactoriser" pour améliorer la fiabilité ou peut-être pour ajouter une fonctionnalité "Si nous passons aux événements sur les MQ, nous pouvons envoyer des suggestions de produits basées sur l'apprentissage automatique, ainsi que le découplage de nos microservices"
Conseil informatique
Ici, la refactorisation des dernières idées et techniques pourrait être au cœur de votre argumentaire de vente. "Passez au cloud distribué-agile! (Maintenant avec le développement basé sur les camions)" Mais vous êtes plus susceptible de faire des projets greenfield ou POC où vous pouvez avoir tout ce que vous voulez.
Vous devez inclure la refactorisation dans vos conceptions. Je comprends la nécessité de "réparer" quelque chose qui ne semble pas approprié, mais vous devez être honnête en termes de ce que la refactorisation de code fini, testé, certifié et fonctionnel (en production) vous apportera, ainsi qu'à votre entreprise. Vous ne devriez pas changer quelque chose qui a fonctionné, qui n'a pas de bugs majeurs ou de problèmes de performances, et qui apporte de la valeur à vos parties prenantes. C'est très visible pour eux, et c'est pourquoi ils ne laisseront (très probablement) jamais le temps pour des changements inutiles.
Vous devez être intelligent à ce sujet. Vous fournissez (je pense) la maintenance de ce logiciel. Les nouvelles fonctionnalités nécessiteront une certaine conception, donc chaque fois que vous devez changer le code, ne faites pas de changement chirurgical et pragmatique et engagez-vous à créer la bonne solution au problème. Cela impliquera probablement une refactorisation des classes existantes.
Quelque chose manque à votre question, ce qui est probablement la raison pour laquelle vous ne pouvez pas la passer par la direction, est une démonstration de la besoin pour la refactorisation.
Le refactoring est un risque, vous devez donc montrer que le "retour attendu" est un net positif et que les dommages peuvent être atténués si les choses tournent au sud.
Cependant, si vous POUVEZ démontrer que le rendement attendu est supérieur au coût, alors personne ne sera certainement en désaccord avec vous.
Il est possible que le refactoring soit également hors du pouvoir de la direction - selon votre entreprise/vos projets, votre entreprise peut ne pas être propriétaire de la base de code sur laquelle vous travaillez. Travailler sur des modifications non demandées par le client peut être une rupture de contrat.
Je demande quelles sont les façons dont je peux aider à créer une culture de l'écriture pour la maintenabilité plutôt que la pure fonctionnalité
Avec une équipe de 20 personnes, je suppose que vous avez des réunions et (espérons-le) des révisions de code. Ce serait un bon moment pour partager vos préoccupations concernant les styles de codage (idéalement, une directive de codage existerait) et les modèles de conception. Encore une fois, vous devrez démontrer un avantage à cela! La modification des styles de codage nécessite des efforts de tous les membres pour changer, maintenir et appliquer, mais si les gens conviennent généralement que vous avez fait un argument valable, il ne devrait pas être difficile de continuer.
Si vous devez convaincre votre chef de file, il se peut qu'ils envisagent des choses (que vous devez les convaincre ne sera pas un problème):
・ Selon la complexité de votre code, le règne gratuit des refacteurs entraînera probablement beaucoup de "Pourquoi cette rupture ??" "Oooh! Je ne savais pas que c'était bizarre comme ça pour une raison!" (En d'autres termes, ce n'est pas l'idéal, mais parfois les choses sont comme elles sont pour une raison, une raison que le responsable connaîtra probablement et aura sous contrôle et ne voudra pas que les gens piquent)
・ Les tâches peuvent commencer à prendre plus de temps que le responsable prévu, donc le responsable doit être préparé pour cela (c.-à-d. Budget plus de temps)
PS, il semble que cela devrait être dans stackexchange WorkPlace plutôt que dans l'ingénierie logicielle
PPS, je pense que beaucoup de ces réponses semblent refléter son propre environnement de travail plutôt que le génie logiciel en général. Que vous possédiez ou non la base de code est important. Que votre produit soit en production ou non. Votre situation peut invalider bon nombre de ces réponses.
Attention aux aspects économiques de la refactorisation
Refactoring
- n'affecte pas les aspects fonctionnels (sinon c'est plus que du refactoring)
- par conséquent affecte uniquement les aspects non fonctionnels (également appelés attributs de qualité ) .
Il y a un coût inhérent associé au refactoring , et les avantages du refactoring doivent dépasser ce coût:
- le refactoring coûte du temps , et donc de l'argent (dans les environnements commerciaux)
- coût d'opportunité : ce temps pourrait être consacré à quelque chose de mieux (ajouter de la valeur fonctionnelle ou livrer plus tôt, ou améliorer les aspects qualité d'une autre manière)
- risque : le résultat pourrait être pire que ce que vous aviez auparavant, ou cela pourrait prendre plus de temps que prévu. Par conséquent, une marge de sauvegarde doit être ajoutée aux coûts de refactorisation.
Les avantages doivent également être quantifiés, en termes d'aspects de qualité améliorés attendus ( https://en.wikipedia.org/wiki/Non-functional_requirement ): le refactoring peut
- vous fait gagner du temps (et donc de l'argent) à l'avenir (pour la maintenance et l'ajout plus rapide de nouvelles fonctionnalités)
- ont des améliorations de qualité significatives qui peuvent être monétarisées (payées par les clients actuels ou futurs)
Donc, pour chaque refactoring, pensez à:
- Quels sont les avantages attendus et comment et quand paieront-ils de
- Combien de temps/argent vous avez à investir , plus l'augmentation du risque
Mauvaise situation: le code pourrait avoir besoin d'une refactorisation, mais les avantages de le faire sont marginaux, et il est tard dans le projet, et vous êtes dans un projet à prix fixe, à un coup qui ne sera pas poursuivi sauf pour de graves corrections de bugs.
Pour les petits refactorings : ces décisions peuvent être prises par les développeurs eux-mêmes comme par la règle boyscouts : laissez le code/terrain de camping en meilleur état que vous ne l'avez trouvé.
Pour des refactorings plus importants : l'attention de la direction (chef de projet) et le feedback (développeurs pairs) sont fortement conseillés avant de perdre un temps potentiellement précieux sur un refactoring. Les pairs développeurs peuvent obtenir des informations ou des conseils pertinents pour la refactorisation (qui peut généralement être effectuée de plusieurs manières), et des leçons peuvent être tirées (par vous et par d'autres).
Je vois plus de problèmes qu'un simple refactoring ici.
J'ai également demandé à la direction si nous pouvions avoir une planification ou un nettoyage plus délibéré de la base de code, mais on m'a essentiellement dit non.
Avez-vous parlé à votre chef d'équipe direct? La gestion est un terme très large et peut inclure tout, du chef d'équipe de plus de 20 personnes jusqu'à un PDG de toute l'entreprise ainsi que la gestion d'autres piliers de l'entreprise (alias opérations ou gestion d'entreprise; notez que tout PDG de niveau est généralement plus d'Ops/Bus également).
Essentiellement, la personne à convaincre est votre supérieur hiérarchique direct. Le responsable de l'équipe. Si vous parvenez à les convaincre, vous êtes sur la bonne voie. Ce sera alors leur décision s'ils veulent appliquer des changements sans en informer personne ou demander d'autres approbations. Ils sont également responsables de la construction de la culture du codage.
J'ai eu quelques conversations 1: 1 avec des membres de l'équipe et la plupart d'entre eux sont également conscients des différentes odeurs de code et ne les aiment pas
Cela signifie que vous avez en fait une base très solide. Dans la plupart des entreprises, il y a des réunions d'équipe et vous pouvez évoquer l'amélioration de vos pratiques de codage en général. Parlez dès le départ à 2 à 3 collègues qui, selon vous, pourraient être les plus intéressés, afin qu'ils puissent vous soutenir lors de la réunion. Cela renforcera votre position de discussion.
Préparez vos arguments. Recherchez l'analyse de l'impact sur le code, l'efficacité de la programmation, etc. lorsqu'il n'est pas écrit correctement. Le terme "dette technique" a déjà été mentionné dans d'autres réponses. C'est ce que vous devez rechercher en général.
Pensez également aux problèmes réels que vous ou vos collègues/toute une équipe avez rencontrés en raison de ces problèmes. Serez-vous en mesure de passer moins de temps si le code était uniforme? Y aura-t-il moins d'erreurs lors des intégrations de code?
Tout le monde dans l'équipe programme à sa manière et il n'y a pas de coordination.
Ceci, plutôt que la refactorisation elle-même, est la principale et la première chose à résoudre. Quel est l'intérêt de refactoring si vous revenez à la même (absence de) qualité de code dans 2-3 ans (au mieux). En réalité, votre refactoring sera plus lent que l'introduction du nouveau code, ce sera donc simplement une perte d'efforts. Concentrez-vous sur la façon d'améliorer la qualité du nouveau code dans la première ligne, convenez des pratiques à suivre, ajoutez des revues de code en tant que partie obligatoire de votre codage pour vous assurer que les pratiques sont suivies.
En d'autres termes - arrêtez de faire plus de dégâts (c'est-à-dire d'acquérir plus de dettes techniques). Bien sûr, vous aurez toujours des difficultés avec cela et parfois vous pourriez vous retrouver avec quelques écarts par rapport à la norme, mais chaque écart doit être immédiatement corrigé avant de passer au projet suivant.
mais le refactoring se produit rarement car il y a toujours quelque chose de plus important à faire.
Une fois que le point précédent est atteint, vous pouvez passer à la refactorisation.En réalité, faites-en une partie de vos pratiques de codage immédiatement mais seulement une fois les normes établies.
La refactorisation ne consiste pas à effectuer un énorme changement unique (encore une fois - comme déjà souligné dans d'autres réponses). Il s'agit de l'amélioration continue de parties du code voisines de ce que vous écrivez actuellement. Faites en sorte que vous répariez une ligne de code ou une fonction que vous êtes sur le point d'utiliser. Un à la fois. Assurez-vous d'avoir un test unitaire (si vous ne les écrivez pas, l'un fait également partie de votre refactoring).
Avec cette approche, il sera plus facile de mélanger le refactoring au travail quotidien. Vous devez en tenir compte lors de l'évaluation de la charge de travail pour le codage réel. Seulement si vous vous donnez le temps requis, vous pourrez le faire. Et personne ne s'opposera très probablement, car ils n'ont aucune idée de ce que vous faites vraiment. Bien sûr, tant que vos gestionnaires y consentent.
Ce n'est pas un problème d'équipe, car ce n'est jamais un problème d'équipe. Il s'agit d'un problème de gestion, et la question à laquelle vous devez répondre est la suivante: la direction comprend-elle ce qu'est la dette technique et pourquoi il est important de la rembourser - et plus important encore, s'en soucient-ils?
Dans la majorité des entreprises où les logiciels ne sont pas au cœur des préoccupations, la direction ne comprend pas ou ne veut pas comprendre les logiciels, car ils ne la considèrent pas comme importante. Si tel est votre scénario, vous devez préparer une présentation expliquant pourquoi vous avez besoin de refactoriser le logiciel (c'est-à-dire les risques de ne pas refactoriser) et de le présenter aux gestionnaires concernés. Soit ils vous rejoindront, auquel cas vous pouvez commencer à l'introduire progressivement, soit ils ne le feront pas - dans ce cas, vous devez soit continuer à gérer une base de code pourrie pour toujours, soit trouver un emploi ailleurs.
Si, cependant, vous travaillez dans une entreprise axée sur les logiciels où le refactoring n'est pas un objectif central, vous devez sortir de l'enfer, pronto. Il n'y a pas d'autre option, car de telles entreprises (et oui, j'ai travaillé dans l'une d'entre elles) ne changeront jamais leurs pratiques, indépendamment de ce qu'elles peuvent prétendre, car elles ne peuvent littéralement pas se permettre de passer leur temps autrement que de présenter l'offre la plus basse. au client suivant, et les offres les plus basses n'incluent pas le temps de refactoring.
Vous devez en faire une chose amusante et excitante à faire. Nous l'appelons "L'offensive qualité". Un analyseur de code fonctionne du jour au lendemain et génère des listes de choses qui pourraient être mieux faites. Ces tâches traînent à Jira, c'est un bon travail le vendredi après-midi pour en prendre une et faire vos affaires. Les débutants font cela à temps plein pendant une semaine, jusqu'à ce qu'ils aient l'impression de faire des choses. Il y a en fait une table à Jira pour combien de buglets quelqu'un a vaporisé dans une tâche avant de revenir. Et si vous obtenez cette petite goutte de passer du rouge au jaune au vert, vous êtes un héros, au fond de vous.
Après avoir fait cela un certain temps - combinez ces instructions if, commentez cette fonction, supprimez ce code inutilisé - vous vous rendez compte que vous le faites de toute façon lors du codage, juste pour éviter à quelqu'un d'autre le problème plus tard. Et il y a toujours la petite pensée lancinante "Je ne veux pas que Lint trouve des choses à se plaindre dans mon code".
Il est très important que personne ne soit blâmé pour les bogues pas tout à fait. Ils sont juste là, comme les rats dans les égouts, vous essayez de réduire leur nombre pour le bien commun.
Peu importe lequel des nombreux excellents outils que vous utilisez, obtenez-en un - peut-être une installation d'essai de 30 jours - et laissez-le déchirer. Vous devez ajuster ses paramètres jusqu'à ce qu'il vous donne une sortie utile. Essayez-en différents. Nous en avons en fait deux différents.