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

À la pointe

Des catastrophes de logiciels : Récupération et les stratégies de prévention

Dino Esposito

 

Sophistiquée que cela puisse sembler, nos vies dépendent des logiciels. En tant qu'utilisateurs des différents services nous-mêmes, nous savons très bien que les logiciels fonctionnent comme prévu peut enregistrer réellement notre journée. Mais le logiciel devient plus complexe, car il a modéliser la complexité des processus du monde réel. Les développeurs, les architectes et les responsables informatiques doivent remédier à ce problème.

Dans cet article, j'examinerai les pratiques qui vous permettent de corriger un système de sonde détérioré et afficher les modèles qui peuvent empêcher un système de grandir de façon incontrôlée. Le terme « gros ballon de boue » (BBM) a été créé il y a des années pour faire référence à un système de dépendances cachées en grande partie non structurés et rembourrées avec entre les parties, avec beaucoup de duplication de données et le code et une identification claire des couches et des préoccupations — une jungle de code spaghetti. Pour en savoir plus sur le BBM, je recommande un excellent élément de travail par Brian Foote et Yoder de Joseph à partir de l'Université de l'Illinois à Urbana-Champaign, que vous pouvez télécharger à partir de http://bit.ly/nfPe2Y. Dans ce document, les auteurs ne financières un BBM en tant que le problème pire jamais ; Ils conseillent simplement que les architectes et développeurs être prêt à faire face le risque BBM et apprenez à les garder sous contrôle.

La dynamique des systèmes logiciels

Quelque trente ans auparavant, au début de l'ère de logiciels, applications étaient beaucoup plus faciles à écrire à celle d'aujourd'hui. Nous n'avions aucun besoin d'interfaces utilisateur graphiques. Nous n'avions pas à vous soucier grand-chose esthétique, distribution a besoin, problèmes d'évolutivité ou de préoccupations de déploiement. Et, le dernier mais certainement pas moins, nous avons eu beaucoup moins implémenter la logique métier.

Dans le temps, développement de logiciels a été prise au sérieux et impliqué les grands esprits. Assez étonnamment, dans le début des années 90 nous disposait déjà la plupart des modèles disposés et principes d'architecture et de développement de logiciels. Sans doute, très peu a été « inventé » depuis. Principes tels que la séparation des préoccupations et inversion de dépendance, paradigmes de programmation (OOP) et orienté objet et l'orientation de l'aspect et les pratiques telles que la conception pour la testabilité n'ont pas été développés dans ces dernières années. Beaucoup d'entre eux sont de nouveau détecté et appliqués par les développeurs et architectes d'aujourd'hui, mais ils ont existé depuis des décennies.

Mais pourquoi ont ces principes et pratiques été située dans une sorte de limbo ans ? Il peut y avoir plusieurs raisons à cela, mais un refrain développeur commun est, « Il fonctionne, alors, pourquoi dois-je améliorer (et alors payer le coût de gaspiller une durée supplémentaire)? »

La dynamique différente du Java et Microsoft mondes

Dans le milieu des années 1990, l'avènement de l'orientation de l'objet et des langages tels que Java (plus de C++) invité de nombreuses sociétés de restructurer leurs logiciels, déplacement de plus en plus grands blocs de logique métier de bases de données et les mainframes. Les développeurs de Java, en particulier dans l'environnement d'entreprise, devaient traiter plus complexe que celui trouvé dans le développement rapide d'application (RAD) généralement associé à la programmation de Visual Basic. Il n'est pas surprenant qu'aspect-orientation, mappeurs de l'objet/relationnel (par exemple, la mise en veille prolongée) et les infrastructures d'injection de dépendance (par exemple, ressort) — ne pas de mentionner une longue liste de programmation outils (tels que NUnit, Ant, Javadoc, apôtre et ainsi de suite) — a été créée dans le monde Java. Ils ont été créés par les développeurs pour les développeurs lisser l'impact de la complexité des outils.

En même temps, dans le monde Visual Basic, RAD était rage. Visual Basic aidé les entreprises à créer nice ports front-end de procédures stockées lorsque vous N'utilisez pas de code mainframe. L'avènement des services Web créé une façade supplémentaire et a produit le code mainframe le nom beaucoup mieux de « services hérités ».

La programmation orientée objet par rapport à un débat RAD au cours des dernières 15 ans était une contention raisonnable. Lorsque Microsoft a introduit des fonctionnalités orientées objet dans Visual Basic, il était vraiment difficile d'expliquer aux développeurs Pourquoi diable que ces fonctionnalités bizarre étaient si importantes. Et ils n'étaient pas, en fait donnés relativement faible degré de complexité de ces applications minces.

Le fichier.NET révolution

La version de Microsoft.NET Framework qui s'est passé à la fois cruciale. Il se produit lorsque parmi les grandes entreprises précédemment opté pour une approche RAD était vu suffisamment d'Internet et présentait des systèmes back-end suffisamment anciens pour justifier une reconstruction à la lumière de nouveaux processus commerciaux liés à Internet. En même temps, ces sociétés trouvent dans la plate-forme Microsoft une infrastructure fiable, puissante et extensible. Bien entendu, il a fallu quelques années seulement.NET d'être alors la même quantité énorme de complexité que des collègues de Java a rencontré des dix années précédentes. Plupart.NET expérimentés, ont augmenté, avec les principes RAD et l'approche RAD au développement.

Dans un monde RAD, vous avez tendance à préférer le code qui fonctionne et générer des applications en ajoutant des blocs qui sont principalement autonomes. (Et quand elles ne sont pas réellement autonomes, vous les faire de cette façon par code abusing et de duplication des données).

Le problème n'est pas avec RAD comme un paradigme de programmation. Le véritable problème qui est plus susceptible d'entraîner la fameuse BBM consiste à appliquer RAD (ou tout autre paradigme) sans les corrections que vous peuvent conserver la croissance de l'application et la multiplication ultérieure de la complexité, sous contrôle.

Désactivez les symptômes d'un BBM

Elle semble être une loi naturel de programmation que chaque unité du logiciel de n'importe quelle taille (fût-elle une classe, un calque ou un système complet) se dégradent. Dans leur livre précité, Foote et Yoder appellent « érosion structurelle » du logiciel. Personnellement, j'aime appeler la biodégradabilité du logiciel. Comme unités de logiciel sont maintenues ou modifiées, elles deviennent plus difficiles à maintenir ou de modifier davantage. Quel que soit le nom, aujourd'hui il est simplement une partie de l'affaire ; Vous ne pouvez l'ignorer et tenter de faire simplement entraînera des dommages.

Biodégradabilité du logiciel est bien connectée à une croissance ponctuelle des projets. Incorporation d'un nouvel impératif dans un système existant — qui a été conçu sans que cette exigence particulière — est toujours problématique. Cela ne signifie pas qu'il ne peut pas ou ne devrait pas, être effectué, il signifie simplement qu'en ajoutant un nouvel impératif, vous modifiez le contexte. Une seule modification n'ont généralement un impact considérable sur l'architecture, mais lorsque des changements se produisent fréquemment, le contexte du système évolue au fil du temps et Morphe en quelque chose qui nécessite probablement une architecture différente. Ce processus est également appelé exigences évolution du.

De même, croissance fragmentaire fait partie de l'affaire et n'est pas prêt à faire face à qui est un des deadly sins of architecture logicielle moderne. En ajoutant de nouvelles exigences un à la fois sans réexaminer ladite le système dans son ensemble à chaque étape, vous créez les conditions idéales pour une BBM.

Les symptômes courants vous indiquent sans équivoque que vous allez avoir un peu trop boue dans la boîte de vitesses de votre système ? Un BBM n'obtenir formé pendant la nuit et n'est pas si grave au début. Ces symptômes, je décrirai l'adressage aidera à empêcher de devenir trop volumineux.

Le premier alarme cloche sonne lorsque vous effectuez une modification dans une classe et finissez à la rupture du code dans une autre classe apparemment non lié. Il s'agit de l'effet nocif du logiciel rigid, qui se caractérise par un certain niveau de résistance au changement, qui détermine finalement de régression.

Un deuxième alarme anneaux bell lors de l'échec pour tenter de réutiliser une partie du code apparemment réutilisable. Si le même code ne fonctionne pas lorsqu'il est déplacé vers un autre projet, les causes probables sont difficiles à trouver dépendances ou classes étroitement couplées. Il s'agit également les causes principales de rigidité du logiciel.

Couplage étroit est intéressant car il vous permet d'écrire du code plus rapide et que le code s'exécutera probablement plus rapidement. Il est le cas, toutefois, rendre le code plus facile à maintenir. Dans un projet qui s'agrandit ponctuelle (par exemple, la grande majorité des projets actuels), la facilité de maintenance est de loin l'attribut logicielle principale à prendre en compte.

Enfin, une troisième alarme anneaux bell lorsque vous devez appliquer un correctif à une fonction, mais n'est pas crucial dans l'application d'un correctif idéal (ou ne parvenez pas à le faire), afin de vous avoir recours à une autre solution de contournement.

N'importe quel système peut survivre heureusement une occurrence (ou même quelques) de ces symptômes. Leurs mécanismes sous-jacents sont assez pervers, cependant. Si vous ne respectez pas une de ces symptômes, vous risquez de subir le risque de rendre le système plus compliquées.

Par exemple, considérons le deuxième problème (parfois appelé immobilité). Vous devez ajouter une nouvelle fonctionnalité et vous êtes tout à fait certain légèrement adapter et de réutiliser une fonction existante. Vous essayez et elle ne fonctionne pas parce que la classe vous attentes serait réutilisable est en réalité, étroitement liée à d'autres personnes. L'alternative que vous avez importe un jeu de fonctions dans plusieurs modules beaucoup plus vaste. Dans ce cas, une solution commune (mais naïfs) est de dupliquer certains codes sans jamais essayer d'une nettoyeur réutilisation des classes. Duplication du code résout le problème temporairement, mais simplement s'agrandit le BBM.

Causes possibles d'un BBM

Il est rare qu'un seul développeur créer un BBM. Au lieu de cela, un BBM a plusieurs causes, et a souvent la cause principale à estimer le niveau actuel de développement à l'extérieur. Gestionnaires exigeantes, ainsi que des clients qui ne connaissent pas vraiment ce qu'ils veulent communiquer aux informations incertaine et ambigu de développeurs. À moins que l'équipe dispose de beaucoup de rencontrer en général de développement de logiciels et dans le domaine spécifique, cela conduit automatiquement au choix arbitraire successivement fixé par le biais de compromis et les solutions de contournement. L'effet net est que l'architecture globale est assouplie à sa base.

Tout le monde impliquées dans un projet de logiciel peut faire beaucoup pour éviter un BBM et Lisser son impact spectaculaire. Examinons les étapes fondamentales à suivre lorsque vous vous trouvez immergé dans un BBM.

Une stratégie de récupération après sinistre

Lorsque vous êtes confronté à un BBM, la chose à faire idéaliste est simplement réécrire l'application en fonction des exigences révisées et choix d'une nouvelles architecture. Mais une réécriture complète n'est jamais une option que vous êtes autorisé à prendre en compte. Comment vous supporte la boue ?

Foote et Yoder utilisent une image évocateur pour introduire l'option raisonnable seulement vous avez dans ces cas : Sweep détritus sous le tapis et passez à votre propre vie. Mais je pense que je peux synthétiser une stratégie de récupération pour une reprise après sinistre de logiciel en trois étapes. La première étape s'arrête tout nouveau développement. La deuxième étape consiste à isoler les points douloureux aux couches (lorsque ne pas monté en cascade) et organiser les outils permettant de mesurer une régression sur ces points. Enfin, vous sélectionnez chacune de ces couches problème isolé et, avec une extrême précaution, essayez de refactoriser les à une architecture plus propre et plus faiblement couplée.

La seconde après avoir arrêté le développement sur un projet boueux, vous commencez à penser d'une série de tests pertinents. Immergé dans un BBM, la dernière chose que vous pensez de sont les tests unitaires classique. Les essais pertinents dans ce contexte sont tri de tests d'intégration qui s'étendent sur plusieurs couches et parfois niveaux. Ces tests sont lents à s'exécuter en premier lieu, mais — beaucoup plus important encore, ils peuvent être lents à écrire. Vous devez isoler les segments (probablement grande police) de comportement et les masquer derrière une façade qui peut être commandée par le biais de tests. Écriture d'une façade est peut-être pas facile, mais il est généralement au moins possible. Il est surtout une question de temps et du travail. Ces tests sont une aide appréciable pour les prochaines étapes, car ils vous fournissent un outil automatisé pour mesurer la régression avant de continuer avec l'étape finale. La dernière étape se compose de painstaking de travail où le premier problème résolu est couplage étroit de refactorisation.

Planification d'une stratégie pour empêcher un BBM

Prévention est toujours préférable à un traitement. Il existe trois vertus cardinal d'une équipe qui peuvent empêcher un stalemate BBM, que j'aborderai plus loin. Étant donné que la plupart des projets de nos jours être affectées à partir d'un niveau élevé de bidon exigences, croissance ponctuelle est un fait, pas simplement une possibilité. Pour empêcher un BBM, vous devez disposer d'une stratégie efficace pour faire face à la croissance ponctuelle de la fonctionnalité.

La litanie des logiciels gérables prétend que parfaite logiciels modernes dessert les besoins actuels et suffisamment souple pour répondre aux exigences futures. Le premier mérite de ces trois mentionnés plus haut est expérience du domaine. Lorsque vous ne peut pas avoir un expert du domaine réel de votre équipe, au moins vous avez besoin une personne ayant une connaissance approfondie du domaine — qui vous rend probable que l'expert dans le nouveau domaine. Expérience de domaine vous conduit au jugement sensible sur les fonctionnalités qui seront probablement nécessaires et demandé. Par conséquent, vous pouvez facilement anticipez tout en préservant le principe YAGNI (vous Ain't Gonna devez It) clairement à l'esprit.

L'approche de cartes (CRC) classe-responsabilité-collaboration m'a aidé à mieux comprendre les mécanismes de domaines, que j'ai rencontré pour la première fois. Je vois des cartes CRC plus comme un moyen de teach yourself du domaine, qu'une manière d'élaborer une conception appropriée. Conception, d'autre part, est correcte uniquement si validé par le client réel. Exemples d'utilisation — ou, mieux encore, un prototype — sont des options plus intelligemment.

Le prototype peut être un problème car les clients aiment que leur force vous permet d'étendre au lieu de démarrer à partir de zéro avec une nouvelle conception tellement. Prototypes sont généralement effectuées avec le code occasionnel délibérément écrit pour être rapide et, en tant que tel, dépourvues de principes et schémas. Vous souhaitez simplement démarrer avec le code d'accrochage.

La deuxième raison est devenu un meilleur développeur/architecte en apprenant les principes de concentré de développement de logiciels et les pratiques recommandées. Le défi ici consiste tout en apprenant à faire les choses simples correctement par défaut. N'ayez pas peur d'injection de dépendance et de programmation par interface. Validation de chaque classe contre les pièges de la programmation orientée objet. Assurer un fonctionnement correct via le code et d'analyse statique. Si vous n'êtes pas sûr (e) sur le fonctionne d'une fonctionnalité, rendre testable et écrire des tests. Conserver votre code maigre et moyenne, avec la plupart des méthodes plus que quelques lignes (avec échéance exceptions, bien entendu). Si ces pratiques deviennent partie intégrante de votre poitrine d'outil, le BBM reste un peu plus loin à partir de vos projets.

La troisième raison est sur la présentation de la durée de vie du projet. Pas de chaque projet doit élaborer un système qui dure depuis des décennies. Projets de courte durées ne nécessitent pas le même soin de conception. Vous pouvez aller plus vite sur ceux-ci et placer des soins dans leur mise en oeuvre avant de les rendre droite. Dans le logiciel, la complexité doit être contrôlé lorsqu'elle existe vraiment, not created où il n'existe pas et n'est pas supposé pour être. Le danger est toutefois, lorsque la profonde conviction initiale que le projet avait un court intervalle est invalidée par surprenant succès et à la demande et la création d'un marché. Si la version suivante se produit trop lentement, vous courez le risque d'un concurrent snatching le marché, ou vous courez le risque de création d'un BBM en raison d'exigences métiers vraiment étroite (et désespéré).

Récupération d'urgence de projet de logiciel

Le BBM est un anti-modèle courant, mais, dans une certaine mesure, il est un attribut qui peut être appliqué à presque tous les projets logiciels. Il provient de l'utilisation des outils erronés à maîtriser la complexité. Dans cet article, j'ai utilisé une expression — reprise après sinistre, qui est très répandu en informatique. La litanie des experts de reprise après sinistre, toutefois, peut être appliquée aux projets logiciels trop : montant en Dollars dépensé en prévention méritent d'être plus de montant en dollars dépensé en cours de reprise. Brûlent d'office de votre manager dès aujourd'hui !

Dino Esposito est l'auteur de « programmation Microsoft ASP.NET MVC » (Microsoft Press, 2010) et co-auteur de « Microsoft.NET: conception d'Applications pour l'entreprise » (Microsoft Press, 2008). Basé en Italie, Dino Esposito participe régulièrement aux différentes manifestations du secteur organisées aux quatre coins du monde. Suivez lui sur Twitter à twitter.com/despos.

Grâce à l'expert technique suivante pour la révision de cet article : Mircea Trofin