Cet article a fait l'objet d'une traduction automatique.

Nettoyage du code

9 tactiques utiles pour rembourser la dette technique

David Laribee

Dans le décembre 2009 délivrance de MSDN Magazine, j'ai donné conseils permettant d'identifier et de création d'un cas pour s'attaquer à dette technique. En résumé, je pense qu'il est important d'identifier la dette est susceptible de nuire à vous dans un avenir proche. Introduction d'excellence technique aux parties touchées rarement de votre base de code ne vous aidera pas à réaliser des gains de productivité demain.

En outre, j'espère que vous comprenez l'importance de l'obtention de licence et achat-dans de gestion de l'importance du paiement des dettes et certains outils de base à la création de cas solide pour le même.

Maintenant activer let’s notre attention vers tactiques qui peut vous aider à rembourser la dette techniques à taux d'intérêt élevé. Il existe de nombreuses tactiques éprouvées dans le traitement des technique dette. Un catalogue complet des modèles, outils et techniques pour wrangling code difficile n'est pas bien abordée de cet article. Au lieu de cela, j'allez fournir certaines astuces plus applicables que 've ajouté à mon répertoire au cours des années.

Apprendre, apprentissage, apprentissage

Si vous savez que vous rencontrez des problèmes, mais vous ne savez pas comment les résoudre, il peut être temps d'acquérir de nouvelles connaissances et compétences qui vous permettra de vous élever votre code de la muck. Apprendre, comme on dit, est fondamentale.

Apprentissage peut prendre de nombreuses formes. Vous pouvez être amené à une aide extérieure sous forme de consultants ou à des cours de formation. Il est possible d'en sortir avec livres.

Essayez d'impliquer votre équipe dans le processus d'apprentissage. Par exemple, vous pouvez démarrer un club du livre au sein de votre équipe. Peut-être que vous pouvez reprendre arrière les avantages d'un cours ou conférence sous la forme d'une présentation instructive.

Une technique collaborative et pratique impliquant l'ensemble de l'équipe consiste Dojo codage. Une base Dojo codage implique un défi de programmation de prélèvement et qui s'attaquer en tant que groupe. Je 've expérimentées avec une paire de rotation suivie par une galerie cacahuète. Dans cette méthode, deux membres de l'équipe travaillent ensemble sur une tâche de programmation, avec des intervalles de “ balise ” où autres membres de l'équipe de saisir la dojo comme une autre personne quitte.

Si vous plus adaptées à votre rythme ou que vous voulez démarrer un club du livre, il y a quelques bonnes textes que je CAN recommande en la matière d'amélioration de la facilité de maintenance du code hérité (legacy).

Avec justesse intitulée volume ’ Michael Feathers, Utilisation efficace avec du code existants (Prentice Hall 2004), offre une approche basée sur des modèles pour taquiner hors code hérité (legacy). Il effectue l'instruction que code hérité (legacy) constitue du code non testé. Il est difficile à modifier, et vous ne pouvez pas être sûr que vos modifications ne sont pas introduire de défauts de régression. Dans ce manuel, vous trouverez un certain nombre de stratégies ciblées et tactiques de réduction de couplage dans votre code et rend plus testable.

Kyle Baley et Donald Belcham posséder un des plus récentes livres sur la scène, T Développement d'applications Brownfield dans .NE (Manning Publications, 2010). Ils adoptent une approche systémique pour améliorer la soi-disant brownfield (plutôt que de nouveaux développements. ou nouveau) codebases. L'un des avantages de ce manuel est que, alors que les approches qu'ils conseillent sont largement applicables, leurs exemples de code sont conçues autour de Microsoft .NET Framework, un avantage susceptible aux lecteurs de cet article. J'aime assez comment ils adoptent une approche de pratiques de l'équipe également. Autrement dit, alors que vous apportez des modifications dans une base de code sauvage, la confiance vous recevrez par la mise en œuvre de certains principes de base comme l'intégration continue et contrôle de version est important de son poids en or.

Diplomatie

Il représente une probabilité élevée le code désordonné à que vous avez à faire face a été écrit par une personne actuellement de votre équipe. Il est important que vous prendre en compte lors de raisonnement sur le code dans son état actuel. Sentiments hurt entraîner defensiveness qui, à son tour, aboutit à ralentir va dans le train amélioration.

Essayez de désamorçage la situation avec anecdotes d'erreurs que vous avez effectuées dans le passé. Rester professionnelle, éviter les attaques personnelles et encourager l'auteur du code d'origine de faire des suggestions sur comment vous pouvez ouvrir sur améliorer.

Puis à nouveau, il est tout à fait possible que vous êtes parmi les développeurs qui ont contribué de votre désordre. Je veux vous répétez après moi : “ Je ne suis pas mon code. Je suis tous les jours de formation et suis dédié à la recherche d'un meilleur moyen de progresser. Je ne permettra pas critiques ’ Mes collègues ou mon propre auto reposer en termes de contribuant mon équipe à améliorer. ”

En fait, prend de temps d'obtenir sur ces problèmes. Je trouve la meilleure raison et parler des améliorations consiste à se concentrer sur la présente et future plutôt que le passé à proximité. Quel peut être ce code ? Que voulez-vous voir deviennent des ?

Un peu diplomatie et compte de placement émotionnelle d'autres personnes en travail a déjà été validée sera passent un long, long chemin vers l'avenir.

Introduire une forme

Une partie du code n'est donc horrendous qu'il est difficile de comprendre ce qui se passe du tout. Toutes les classes sont peut-être dans un espace de noms unique. Le code de base est sans doute ces tangled Web des dépendances qui dépasse la capacité de votre mémoire à court terme à préserver votre suite de la pile considérablement.

Symptômes de telles impliquent souvent un diagnostic de dette à l'architecture et les niveaux de conception et non au niveau de l'implémentation. Dans la mesure où je suis concerné, ceci est le type de dette plus insidieux et entraîne généralement les coûts de plus grandes de modification.

Brian Foote et Joseph Yoder appel architectures aucune forme visible, dans laquelle tout ce dont dépend tout le reste, la “ bille big de boue ” (laputan.org/mud ) :

“ Une grande boule de boue est un par hasard, même légère, structuré système. Son organisation, si un appel à qui, dépend plus de substitution à la conception. Pourtant, sa popularité durable ne peut pas simplement être le signe d'un ignorer général pour l'architecture. ”

Je vous parie mon dernier dollar que la plupart des applications de logiciel en production aujourd'hui sont volumineuses balles de boue. Ceci n'est pas nécessairement un jugement de valeur. Il existe des milliards de lignes de code épouvantable existent dans le monde qui effectue des personnes beaucoup et d'argent. Il est évident que big balles de boue comblez les rêves de champagne et caviar souhaits d'un grand nombre un propriétaire de l'entreprise et un actionnaire.

Le problème est que les applications de balle de boue deviennent plus en plus coûteuses à modifier. Alors que l'environnement métier reste dynamique, le logiciel devient fixe. La stratégie standard de traitement des Ceci est le logiciel équivalent d'une bombe nucléaire : la réécriture importante. Il existe de nombreux risques associés à réécritures volumineuses et il est souvent préférable de tenter d'améliorer la conception du système en place.

Avant de commencer à employer certaines techniques de niveau inférieur, il est souvent intéressant de présenter une forme de votre système. L'exemple classique est celui d'une architecture en couches. Cela signifie généralement parle de l'interface utilisateur aux services et services parler à un type de modèle et le modèle, à son tour, communique avec votre couche de persistance.

Mise en forme votre code en couches peut être une activité très faible fidélité. Commencez par l'organisation du code en espaces de noms nommé d'après les couches de votre architecture.

Vous avez maintenant vos commandes marching : appliquer la règle que calques de niveau supérieur (couche d'interface utilisateur) peuvent dépendre uniquement le niveau suivant supérieur (couche de services). Moyen simple d'appliquer la règle consiste à déplacer vos calques dans des projets séparés dans Visual Studio. La solution ne sera pas compiler si vous n'en respectez pas la règle.

En faisant la passe de règle, vous avez diminué de couplage. Le modèle est n'est plus associé aux vues de votre application. En introduisant une forme, vous obtenez une cohésion. Classes à l'intérieur de votre couche tous travaillent à la même fonction que ce soit pour afficher des données à un utilisateur final ou pour encapsuler le comportement de l'entreprise.

Introduire façades entre couches et apportez les calques de niveau supérieurs telles que votre interface utilisateur dépendent des façades fournies par les calques de niveau inférieurs au lieu des classes granulaires dans les couches. Vous pouvez appliquer cette technique de ce processus incrémentielle et de façon opportuniste.

La puissance de l'imposition d'une forme sur la bille big monolithique de boue est que vous pouvez maintenant commencer à identifier les plus ciblées possibilités de paiement des dettes technique. Autrement dit, si vous effectuez beaucoup de travail dans, disons, CompanyX.ProductY.Model, vous pourriez consulter avec un outil d'analyse statique pour rechercher le meilleur couplé ou compliqué de classes.

Fermer support air avec des tests

Le processus de fabrication de modifications sans modifier le comportement du système est appelé de refactorisation. Il existe toute refactorisation des langages de modèle dédiés pour les deux orientée objet (refactoring.com ) et le code de base de données relationnelle (agiledata.org/essays/databaseRefactoringCatalog.html ) : Extraire la méthode, fractionner la table et ainsi de suite. Le fait de la question est, il est difficile d'appliquer ces méthodes granulaires et en toute sécurité lorsque vous ne comprenez pas totalement la base de code.

Comment commencer? vos modifications dans un projet hérité La première chose à remarquer est que, étant donné un choix, il est toujours plus sûr d'avoir tests autour des modifications apportées. Lorsque vous modifiez le code, vous pouvez introduire des erreurs. Mais lorsque vous parlerez votre code avec des tests avant de modifier le code, vous êtes plus de chances d'intercepter des erreurs.

La pratique de chirurgie au fusil, plongée headlong dans du code sans toute confiance réel modifications que vous introduisons ne sont pas prises également introduire des défauts dangereuses, n'est pas le seul moyen de forcer une modification.

Avant de commencer la modification du code, déterminer s'il existe une interface de disque dur dans le système par rapport à laquelle vous pouvez écrire des tests. Ces tests sont de la variété de boîte noire. C'est-à-dire, vous êtes un système d'alimentation, entrées et inspecter les sorties. Lorsque vous apportez vos modifications, continuellement exécuter les tests pour vérifier vos modifications n'ont pas été endommagé comportement existant.

Application de cette tactique peut être complexe lors de la résolution de parties de votre système étroitement couplés. Le coût des tests peut dépasser très bien l'avantage de la suppression de dette. Cette analyse coûts-avantages constante permeates le processus d'activation d'une base de code et, parfois, il est plus rentable vers le haut réécrire une application ou de la grande section de code base d'une application.

Mesure Observable Effects

Mesures autour de la zone de code que vous êtes amélioration de la génération. Pour des raisons d'argument, let’s que vous essayez de mieux organiser la logique d'entreprise principale de votre application. Il y a beaucoup de chemins d'accès à l'aide de membres dans les types de cet espace de noms : instructions imbriquées si switch instructions et similaires. Une mesure telles que la complexité cyclomatic vous donne une idée approximative d'indique si les efforts d'amélioration sont simplifiant votre code.

Vous pouvez obtenir des mesures extrêmement spécifiques des parties spécifiques de votre base de code à l'aide de l'outil d'analyse du code NDepend (ndepend.com ). NDepend fournit un langage de requête puissante code (CQL) sur les espaces de noms, types et membres dans vos assemblys .NET.

Considérez les instructions CQL dans figure 1. Notez que je suis détection mesures telles que couplage et de complexité (quelques-unes de la métrique des nombreux NDepend rend disponible) à l'intérieur d'un espace de noms particulier. Cela implique que je 've déjà introduit une forme pour que je CAN concentrer les efforts dans des zones définissables de mon code. Si je suis parvient à introduire de modifications positives, je should Voir mesures telles que couplage et de diminution de la complexité au fil du temps.

Figure 1 NDepend CQL

-- Efferent coupling outside a namespace
SELECT TYPES 
WHERE TypeCe > 0 
      AND (FullNameLike "MyCompany.MyProduct.Web")

-- Afferent coupling inside a namespace
SELECT TYPES 
WHERE TypeCa > 0 
      AND (FullNameLike "MyCompany.MyProduct.Web") 

-- Top 20 most complicated methods
SELECT TOP 20 METHODS 
WHERE CyclomaticComplexity > 4 
      AND FullNameLike "MyCompany.MyProduct.Web"

Un effet secondaire intéressant de cette tactique est que les mesures peuvent vous aider à maintenir les et maintenir la discipline une fois effacé de la dette.Ils vous donnera un système d'avertissement précoce vers la réintroduction de dette de nouveau dans une zone déjà améliorée.

Stream Improvement dédié

Vous Don ’t vivent dans un vide.Chances sont, au cours de vos efforts d'amélioration, vous serez invité à continuer à fournir de nouvelles fonctionnalités et modifications apportées aux fonctionnalités existantes.Pression de livraison entraîne sentiments d'être contraints.Mais la maintenance est un fait de la vie, que vous devez adopter plutôt que d'essayer de l'ignorer.

Un pour cette situation consiste à sécuriser l'approbation de l'entreprise et dédier les ressources — un individu, une paire ou une équipe entière — à l'amélioration des éléments de la dette simultanément avec proposant des fonctionnalités nouvelles.

Cela peut être une stratégie efficace mais est préférable lorsque l'ensemble de l'équipe (tous les développeurs et testeurs qui apporter des modifications à la base de code) prend une partie dans le progrès.Essayez régulièrement rotation personnes sous forme de paires.Le développeur qui a été dans le flux d'amélioration la plus longue fait pivoter, en laissant le développeur brève la paire de nouveau sur ce qui se passe.

En répartissant les connaissances vous obtenez plus proche de la propriété collective, ainsi réduire les risques et amélioration de conceptions.Parfois vous y trouverez des possibilités d'amélioration qui se trouvent directement en termes de fonctionnalités que vous essayez de remettre.Chaque fois que vous démarrez le travail sur une fonctionnalité nouvelle ou modifiée, il est recommandé pour passer en revue la liste pour déterminer si l'équipe n'a pas déjà identifié une zone pour amélioration croise le travail que vous allez faire.

Possibilités d'amélioration surviennent tous les temps, souvent identifiée à la volée et atteint avec quelques refactorings simples qui font la différence du prochain un coéquipier rencontre le code.

Il est une analyse coûts-avantages constante qui se passe lorsque l'amélioration de la base tout en offrant de nouvelles fonctionnalités de code existante.Si l'amélioration semble trop coûteuse, ajouter votre liste et discuter dans votre planification d'amélioration.

Effectuer une itération, effectuer une itération, effectuer une itération

Vous avez arrière payed certains dette.Temps de revenir à l'étape un et d'identifier, de hiérarchiser et de consensus sur l'objet suivant a besoin de fixation droite ?

Oui, mais il est un peu plus lui que mindlessly plowing votre liste.Vous devez être sûr de ne pas encourir de dette plus que votre résolution.Vous devez également régulièrement incorporer votre 
learnings dans futurs efforts en développement de nouveaux et des efforts d'amélioration similaires.

Opportunités d'amélioration d'une base de code, modifiez régulièrement.Qu'ils surviennent et leur importance ebbs et des flux.Motifs de la nature dynamique des dettes à intérêt élevé modifier d'une version à l'autre.

Ce qui est a fonctionné correctement pour m'est planification une courte réunion hebdomadaire avec aux développeurs de consulter les nouveaux éléments de dette et de hiérarchiser le retard des éléments de dette existante.Cela permet de conserver le consensus créées vivant et la liste fraîche.Là encore, j'avais donner la priorité à fixation de la dette est susceptible de ralentir votre version actuelle ou le projet.

Commencer la réunion en examinant les nouveaux éléments.Présenter l'identificateur de leur casse de la hauteur de ton et placez-la vote : est il mérite inclusion dans la file d'attente ou non ?Une fois que vous avez parcouru les nouveaux éléments, passez en revue les éléments anciens.Existe-t-il des travaux ne s'applique plus ?Sera il valeur immédiate ce travail, autrement dit, il supprimera obstacles quotidiennes ?Enfin, hiérarchiser l'opportunité par rapport aux autres — re-rang votre liste.L'élément supérieur dans la liste doit être l'amélioration suivante pour vous.

Maintenez la touche la ligne

Pendant que vous et votre équipe merrily payez vers le bas technique dettes à intérêt élevé, vous allez probablement également être des nouveaux logiciels.À mesure que vous découvrez les techniques de programmation solides et introduisez de nouveaux modèles dans votre code, pratique les connaissances acquises à l'avenir.Il est possible que travail additif sera PIEUX sur dette technique existant Création d'une inertie inescapable.

Il est important que vous avez défini des attentes pour votre entreprise des parties prenantes pour le nouveau travail.Une meilleure qualité prend plus de temps pour atteindre que rushed get il fait-style-code.Cela m'amène vers le concept de systèmes pensée introduit dans mon article de décembre 2009.Pour moi, ceci est un attribut culturel.Autrement dit, organisations peuvent penser durable à long terme ou continuez maintenant, avec un achat payer mentality ultérieure — l'oh donc fertiles élevage au sol de dette technique.Ne jamais oublier la question centrale, comment n'a nous terminer ici en premier lieu ?

Pendant que vous êtes apprentissage sur la façon d'améliorer une base de code, vous allez très probablement développer certaines normes de l'équipe qui s'appliquent au nouveau code.Je vous suggère de ces éléments dans un outil comme un wiki capturant et en maintenant les petites, informel de sessions de formation vous permet de partager vos découvertes avec votre équipe.Vous développerez également des techniques permettant de traiter les éléments d'amélioration similaire.Lorsque vous remarquez vous l'avez fait la même chose pour corriger un défaut dans la conception ou nettoyer la mise en œuvre trois ou quatre fois, le codifier en principe de votre équipe.Autrement dit, notez-le dans un endroit connu et, très simplement, indique personnes qu'il est il.

Travailler ensemble

Dette technique est un problème de personnes.Personnes, par manque de connaissances ou attentes irréalistes, créé le désordre et travaillez maintenant avec les conséquences.Et allez travaillant sous la forme d'un groupe pour le corriger.

Donnant des conseils comme ceci est tout bien joli et je serais surpris si vous, un logiciel professionnel et susceptible de celui qui est passionné de leurs engins n'étaient pas accord complet.

Un délai d'exécution réussie nécessite des modifications fondamentales dans le système de valeur de chaque personne impliquée — l'ensemble de l'équipe.L'aspect économique de qualité ont été éprouvées de rembourser au final, mais vous aurez à effectuer cette étape de la foi dans le court terme.Vous devrez remporter la Dame de pique et esprit afin de modifier une culture et qui peut être un travail difficile en effet.La suggestion plus utile qu'i CAN rendre est : ne pas aller il uniquement.Obtenir de l'équipe de l'effort et assurez-vous que tous les utilisateurs ont un intérêt dans les résultats.

La définition de le des objectifs tels que “ nous voulons couverture de 90 pour cent ” ou “ nous voulons faire piloté par test développement (TDD) tout le temps ” est relativement sans signification.S'attaquer les domaines qui vous ralentissent vers le bas l'et dans un avenir proche.Qui peut signifier présentation TDD et vivant par le rapport de couverture, ou c'est peut-être pas.Il peut s'avérer quelque chose plus primitifs comme assurant que votre équipe connaît les notions de base de l'analyse orientée objet et de la conception.

Démarrer la création d'une différence

Alors que j'espère que je 've vous donné quelques outils et techniques pour s'attaquer dette ou, au moins, effectuées certaines des idées implicites et expériences que vous avez eu explicite, il est important de réaliser que gérer les dettes technique est très bien un problème de produit à.Vous pouvez, par exemple, être dans un environnement qui ne présente pas un grand nombre d'approbation entre les parties de développement et de l'entreprise et la recherche que vous avez à votre cas avec la préparation d'un avocat d'évaluation de la hauteur de ton.

Il n'existe aucun processus d'out-of-box vous indiquerons comment pour piloter la dette, mais en ce qui concerne le lors de la et le où , aujourd'hui est bien de la journée pour démarrer la différence.Mars vers excellence technique peut être lent et bruts en début.Il est uniquement via des efforts soutenus, constante apprentissage et, au-dessus de tous, une attitude earnest vous allez extraire via difficiles heures remise code version de dette dans le noir.Je vous encourage à coller à l'aide du programme.Non seulement vous augmentez la valeur pour vos clients, mais vous s'étendent considérablement boîte à outils de votre artisan.

Dave Laribee coaches l'équipe de développement du produit de VersionOne Inc. Il intervient régulièrement lors d'événements de développeur locales et nationales et a reçu unMicrosoft Architecture MVP pour 2007 et 2008. Il écrit sur le réseau de blog CodeBetter à thebeelog.com.