Dans l'ensemble: comment allons-nous maintenir les anciens systèmes? [fermé]

NEW YORK - Avec une explosion qui a fait trembler les gratte-ciels, un tuyau à vapeur de 83 ans a envoyé un message puissant selon lequel les kilomètres de tubes, de fils et de fer sous New York et d'autres villes américaines vieillissent et pourraient devenir dangereusement instables.

Juillet 2007 Histoire d'une pipe à vapeur en rafale à Manhattan

Nous avons entendu parler de la pourriture des logiciels et de la dette technique .

Et nous avons entendu des personnes comme:

• "Oncle Bob" Martin - Qui nous a mis en garde contre " les conséquences d'un désordre ".
• Michael C. Feathers - Qui nous a donné des conseils pour «Travailler efficacement avec le code hérité» .

Il est donc certain que la communauté du génie logiciel est consciente de ces problèmes.

Mais j'ai l'impression que notre société globale n'apprécie pas comment ces problèmes peuvent affecter les systèmes et applications de travail.

Comme le note Steve McConnell :

... Contrairement à la dette financière, la dette technique est beaucoup moins visible, et les gens ont donc plus de facilité à l'ignorer.

Si cela est vrai, et je le crois, je crains que les gouvernements et les entreprises ne reportent l'entretien et la fortification réguliers contre les pirates jusqu'à ce qu'il soit trop tard. [Tout comme NYC et les tuyaux de vapeur.]

Ma question:

• Existe-t-il un moyen d'éviter l'équivalent logiciel de NYC et les tuyaux de vapeur?

Un problème clé lié à la maintenance des anciens systèmes est le manque de personnes qui a) sont à jour sur ces systèmes et b) sont disposés à continuer à les entretenir.

J'ai récemment posé une question dans le même sens sur la question de savoir si les programmeurs plus jeunes étaient intéressés par les mainframes. Le consensus penche vers non.

Le maintien de systèmes hérités est considéré comme un suicide professionnel. Dans de nombreuses entreprises où l'inertie règne, il y a peu d'investissement dans la formation du personnel pour rester au top de ces systèmes, ce qui conduit à des points de défaillance uniques du côté du personnel. Beaucoup de gens que je connais qui travaillent sur des systèmes similaires recherchent des voies de sortie car ils ne voient aucun avenir à long terme dans les systèmes et ne voient que des préjudices professionnels.

Dans certaines industries, les réglementations de maintenance des données peuvent être un facteur clé garantissant que les systèmes existants sont raisonnablement surveillés. C'est particulièrement le problème dans le secteur financier, je pense. À ma connaissance, ces règlements sont généralement limités dans le temps.

Cependant, je pense que dans la pratique, ce qui va se passer est:

Il y aura un point sur le graphique où le coût de la transition vers un système plus moderne qui vous permet de contourner les inconvénients d'un système hérité tombera en dessous du coût de maintenance du système hérité car il est moins cher.

IBM vend beaucoup de mainframes en ce moment, et ils travaillent très dur pour s'assurer que leurs grosses machines n'obstruent pas des pans de jeunes professionnels. Mais je ne pense pas que ce soit suffisant à ce stade. Ils ont quelques USP en termes d'empreinte carbone et de puissance de traitement réelle.

Cependant, pour chaque personne qui achètera un ordinateur central IBM parce que vous pouvez y exécuter Linux, cela coûte moins cher en électricité et est très efficace, vous en aurez plusieurs autres qui choisiront une batterie de serveurs car ils connaissent mieux ce monde. et il en est de même de nombreux autres programmeurs.

En fin de compte, beaucoup dépend de l'industrie impliquée. Je travaille dans une industrie particulière qui a été très dépendante des mainframes pendant des années et des années et ils sont encore largement utilisés. Mais les solutions hébergées sont de plus en plus populaires, ce qui permet de consolider les compétences dans les grandes entreprises - cela supprime certains des problèmes rencontrés par les entreprises individuelles en termes de points de défaillance - et, en outre, certains fournisseurs recherchent très fortement des solutions non basées sur le mainframe pour les problèmes inhérents à cette industrie.

Donc, je suppose qu'en résumé, ce que je dis, c'est que dans l'ensemble, il y aura une évolution vers la migration des systèmes hérités dès qu'un point de maintenance économique par rapport à la migration tombera en faveur de la migration. Cependant, il sera largement invisible pour beaucoup de gens car ce n'est pas nouveau et génial et n'a pas un visage très public comme le fait une prochaine grande chose. Cette migration peut se faire vers des fournisseurs de services ou vers des technologies plus récentes (en particulier lorsque les fournisseurs de services sont ceux directement affectés).

D'après mon expérience, en particulier dans les réseaux, il y a une tendance à supprimer la dépendance aux systèmes hérités.

La plupart des entreprises ignorent déjà la dette technique et ne réalisent même pas que les choses vont mal jusqu'à ce qu'elles s'effondrent littéralement autour d'elles et les mettent en faillite (si jamais elles arrivent à ce point). J'ai vucela arrive, et ce n'était pas joli; ce qui l'a aggravé, c'est le fait que j'ai essayé à plusieurs reprises de sensibiliser les propriétaires d'entreprise à l'augmentation de la dette technique et qu'elle devrait être corrigée, et chaque fois qu'elle était rejetée en raison de la réticence à consacrer le temps et les ressources nécessaires pour la réparer il. Le résultat final était qu'après plus de 10 ans, le système a finalement échoué de manière catastrophique (après mon départ) et ils n'ont pas pu récupérer et ont fait faillite, car ils étaient trop stupides pour réaliser pendant ces dix années que dépenser un peu d'argent pour résoudre le problème aurait été mieux que de l'ignorer complètement. Je pouvais me plaindre pendant des heures de la stupidité absurde de cette entreprise, et ce qui me faisait le plus mal, c'était qu'elle aurait pu être évitée entièrement si les propriétaires n'étaient pas juste pour faire un profit rapide en coupant tout le reste entièrement.

Il est incroyablement difficile d' essayer de dire une entreprise si leurs systèmes sont mal écrits et ont besoin d' un refactoring lourd (sinon une ré - écriture totale qui est normalement le cas , car il est si mal). La plupart du temps, ils vous abattront même si vous les avertissez qu'il est difficile d'apporter des modifications ou d'ajouter de nouvelles fonctionnalités (dans le bon sens, je veux dire, pas seulement de superposer plus de merde sur la pile), ou même de vous considérer comme un au détriment de l'entreprise, car vous voyez des problèmes avec le système dans son état actuel.

Je suis honnêtement arrivé à la conclusion que c'est une bataille perdue et qui ne vaut pas la peine d'être combattue. Les gens assez intelligents pour connaître la dette technique n'ont pas besoin d'en être informés deux fois et sont conscients des dangers dès le départ, et tout le monde n'écoutera aucune raison ni aucun avertissement avant qu'il ne soit de toute façon trop tard. La meilleure option (et bien sûr la plus irréaliste) serait de laisser la sélection naturelle entrer en jeu et de laisser les ignorants disparaître, ne laissant que les intelligents. Je ne connais plus de façon concrète de le gérer, car tout ce que j'ai personnellement essayé dans le passé a été soit complètement ignoré, soit réduit ma valeur aux yeux de l'entreprise (pour "se plaindre") ou même a entraîné ma résiliation parce que j'étais «trop concentré» sur la réparation de «ce qui n'est pas» cassé et personne d'autre n'avait l'état d'esprit approprié pour voir qu'il était cassé.

Les kilomètres de tubes, de fils et de fer sous New York et d'autres villes américaines vieillissent et pourraient devenir dangereusement instables.

Pour l'anecdote, le même argument a été avancé à Paris au 16-17ème siècle. Tant de trous et de tunnels avaient été creusés en dessous (en plus des trous naturels en raison de la géologie de la région) qu'un bâtiment occasionnel s'effondrerait.

Au moment où des blocs entiers de la ville s'effondraient dans le sol, des directives avaient été données pour remplir les trous et les tunnels inutiles de gravier et d'os (ils avaient également des problèmes de cimetière surpeuplés). La ville a survécu de cette façon jusqu'à ce que le béton soit inventé.

Mon point ici est que de nombreuses organisations ont tendance à attendre la dernière minute pour effectuer la maintenance des logiciels, mais les codeurs (comme les ingénieurs civils) font souvent le travail, rapidement et bien.

Nous avons survécu au bug Y2k. Le bogue Y2036 obligera de nombreuses organisations à mettre à niveau leur matériel et leurs logiciels. Le monde pourrait se terminer en 2012. Mais les informaticiens ne sont pas des sociologues ou des critiques littéraires .

Oh, et comme le dit le dicton en attendant: écrivez du code comme si le prochain mainteneur était un psychopathe vicieux qui sait où vous vivez.

J'oublie, que considérons-nous le code hérité de nos jours? Le code de l'an dernier, le code de la dernière décennie ou le code du siècle dernier?

L'argent anime la conversation autour de la maintenance des systèmes existants. La dette technique prend la forme d'un coût accru pour changer le système.

J'ai travaillé avec des systèmes mal conçus et intelligemment conçus. Ce qui est intéressant, c'est que les coûts de maintenance ne varient pas beaucoup. Les plus gros problèmes sont les architectures incorrectes pour l'utilisation actuelle, qui apparaissent généralement dans les problèmes de mise à l'échelle ou lorsqu'un changement majeur est souhaité. Vous ne convertissez pas facilement une zone majeure de code de thread unique à multi-thread.

Les problèmes les plus importants que je rencontre sont les langages de développement utilisés. Les systèmes plus anciens sont écrits dans des langues moins populaires aujourd'hui, vous devez donc vous entraîner davantage ou engager des ressources plus chevronnées (coûteuses) et rares. Dans les deux cas, en raison de la plus petite réserve, vous avez également du mal à trouver des personnes qualifiées qui ont tendance à entraîner autant de problèmes que de solutions.

Quant à la réécriture promise, la plupart des systèmes qui ont fait d'énormes investissements ne justifient pas une réécriture. Il est étonnant de voir combien de temps un logiciel peut continuer à fonctionner et à être amélioré. Les changements de matériel (certains systèmes pris en charge par ma société utilisent du matériel spécialisé) ont tendance à être notre plus gros problème. La capacité d'amélioration n'est souvent limitée que par les mécanismes d'intégration du code hérité avec de nouvelles fonctionnalités.

C'est déjà un gros problème. Et cela ne montre aucun signe de changement.

Dans les années 60 et 70, les grandes institutions de toutes sortes sont passées de la comptabilité sur papier à la comptabilité sur systèmes informatiques. À une écrasante majorité, ils ont choisi COBOL. La plupart utilisent encore des versions mises à jour de ces systèmes COBOL. Voir http://cis.hfcc.edu/faq/cobol pour quelques statistiques à ce sujet

De temps en temps, nous recevons des rappels aléatoires de cela, comme quand Arnold Schwarzenegger a découvert il y a quelques années qu'il ne pouvait pas simplement réduire le salaire de 200000 employés de l'État sans 6 mois de développement en premier (voir http: //www.infoworld. com / d / developer-world / californias-cobol-conundrum-067 pour vérification).

Compte tenu des risques de basculement, il est très difficile de justifier le changement de ces systèmes. Déjà. Cela a été la réalité de ma vie. Mais je ne vois aucune raison pour que ce fait change dans la vie de mes enfants. Ou la vie de leurs enfants non plus.

J'ai des amis qui ont conservé un code plus ancien qu'eux. J'ai une amie qui est retournée dans une entreprise 30 ans après qu'elle y ait travaillé la première fois, pour constater que ses programmes fonctionnaient toujours, inchangés, dans une langue dont elle ne se souvenait même pas!

Permettez-moi de terminer avec une histoire vraie de ce qui peut arriver.

Dans les années 1970, une entreprisea été fondée pour fournir un marché en ligne aux commerçants. Le PDP-11 était un bon rapport qualité / prix pour eux, alors ils l'ont choisi. Ils repoussaient les limites de performance d'une machine, ils ont donc écrit leur système dans un assemblage PDP-11 hautement optimisé. Quelques années plus tard, le PDP-11 a cessé d'être vendu. Cependant, les affaires allaient bien, les machines duraient et les remplacements d'occasion étaient faciles à trouver. Ils ont gardé leur plateforme. Quelques années après, les remplaçants sont devenus plus difficiles à trouver. Un projet majeur a été réalisé pour remplacer la plateforme de trading. Ça a échoué. Ils ont encore essayé. Et encore échoué. Une des principales causes de l'échec était que personne ne savait comment fonctionnait le système commercial et que personne ne pouvait plus lire l'assemblage du PDP-11. Puis le salut a frappé. Quelqu'un a créé un assembleur PDP-11 qui fonctionnait sous Linux.

C'est ainsi qu'en 2000, les transactions entrant dans une activité d'un milliard de dollars / an sont allées à des machines Linux, via un pont Ethernet-Decnet, vers des machines PDP-11 émulées qui exécutaient le commerce sur un système logiciel écrit en PDP hautement optimisé. 11 assemblage. Pour la vitesse.

Je n'ai eu aucun lien avec cette société au cours de la dernière décennie. Je ne peux donc pas vous dire s'ils fonctionnent toujours sur des PDP-11 émulés. Je sais que la décimalisation réduisait douloureusement leurs marges, alors ils ont eu encore un autre effort pour migrer. (J'ai seulement appris l'histoire parce que j'ai interviewé plusieurs personnes qui avaient été licenciées et j'ai demandé ce qui s'était passé.) Cependant, étant donné les échecs précédents, je donnerais mieux que la probabilité qu'ils n'aient pas réussi à remplacer ce système.

Cela ressemble à une préoccupation très réelle du point de vue d'un utilisateur. Pour que la pourriture soit retardée, ou mieux, évitée, le logiciel en question doit être libéré de ses entraves. Ses éditeurs auraient dû libérer le code source, ou être dans l'entreprise de maintenir et de mettre à jour les sources jusqu'à ce que son dernier utilisateur cesse de l'utiliser. Sinon, il y a de très bonnes chances qu'ils cessent leurs activités en raison de pourritures similaires dans le monde des affaires, laissant ainsi le logiciel entièrement ouvert aux pourritures.

C'est-à-dire que la durée des droits d'auteur et des licences restrictives devrait être très courte, à la fin de laquelle le logiciel et sa base de code entreraient dans le domaine public et y resteraient. Ainsi, ce qui permet à l'utilisateur de continuer à mettre à jour les sources ou d'embaucher quelqu'un pour le faire, ce qui retarde et / ou évite les pourritures.

Ou, si vous êtes un peu ouvert à l'idée de logiciels libres, vous pouvez écrire vos programmes sous une licence libre telle que l'AGPL ou la GPL ou d'autres licences de logiciels libres. D'après ce que j'ai vu, lorsque les sources d'un logiciel n'intéressent plus les développeurs pour l'améliorer pour une raison quelconque, la base de sources est cannibalisée et prend une nouvelle vie. Les paquets du système d'exploitation Debian ont tendance à suivre ce cycle de vie, pour autant que je sache.

Ayant pris en charge diverses applications gouvernementales et privées, je dirais que la plupart des entreprises et au moins le gouvernement américain sont bien conscients des dangers de laisser le code pourrir et de ne pas suivre les dernières tendances en matière de sécurité.

Nous devons régulièrement faire certifier nos logiciels pour diverses vulnérabilités et la plupart des systèmes électroniques gouvernementaux, même anciens, reçoivent des mises à jour régulières pour les maintenir en sécurité.

Bien sûr, il y a des exceptions, et les pirates sont toujours en mouvement, mais dans l'ensemble, je pense que les gens sont assez conscients que vous ne pouvez pas simplement jeter quelque chose là-bas et ne plus jamais y toucher.

Attention: ça va être un peu libre ...

Je pense qu'il y a 2 façons de considérer votre préoccupation.

Si vous y pensez, certaines navettes spatiales et satellites ont utilisé le même code qui les avait lancés à l'origine. En revanche, certains ont été conçus pour être mis à jour même s'ils sont (très) distants.

Ce qui compte, c'est l'environnement. Évidemment, tant que vous ne modifiez pas l'environnement, votre code ne deviendra pas obsolète. Dans ce cas, le code rot n'existe pas vraiment: le code lui-même (ou le binaire produit) ne peut pas pourrir. Il peut se casser si vous commencez à l'attaquer sous un angle complètement différent. Ce n'est pas qu'il pourrit, c'est qu'il ne s'adapte pas à son environnement. Considérez-le comme un problème évolutif.

Mais notre environnement change. Et d'une manière ou d'une autre, quelle est la clé de votre problème est également la solution. Notre environnement change si vite que, de nos jours, nous ne nous attendions pas à ce qu'une solution logicielle n'évolue pas avec le temps. Nous négligeons les projets logiciels qui n'ont pas été mis à jour au cours de la dernière année et gémirons sur l'assistance produit et client qui ne produit pas de feuille de route claire. Et même lorsque cela fonctionne bien - vous obtenez une feuille de route claire, un bon support, des mises à jour régulières ... - il y a toujours une chance maintenant qu'un challenger fasse surface, avec une croissance exponentielle. Nous faisons souvent l'erreur de penser que les grandes entreprises établies domineront toujours, précisément parce qu'elles dominent. Cependant, de la même manière que l'élément dominant d'un troupeau vieillit, le super-logiciel / matériel / quel que soit le fournisseur vieillit. Ou juste un peu paresseux. Et un challenger entre et retourne les choses encore plus vite que le dominant établi ne l'aurait fait 5 ou 10 ans auparavant. Ou le dominant prendra juste un bon coup, survivant à peine alors que nous voyons une perturbation du marché (économiquement parlant, avec des impacts sur différents domaines), puis les choses continueront. Peut-être que cela semble imparfait, mais en soi, c'est un processus organique.

Du point de vue de l'utilisateur, je suppose que le problème n'est pas si important. La pourriture du code ne se produira pas du point de vue de l'utilisateur, car il pourra utiliser une alternative (éventuellement avec une transition / migration transparente ... espérons-le).

Supposons maintenant que nous ne voyons pas les choses du point de vue de l'utilisateur, ou que nous parlons d'un système qui est immunisé - pour des raisons inconnues, développement gouvernemental, voyage spatial, etc ... - à la concurrence et est vraiment supposé pour être construit pour vivre / survivre très longtemps, nous devons regarder les textes que vous avez référencés. Et probablement un peu plus de littérature sur les systèmes fiables et les systèmes tolérants aux pannes. Même si nous voulons probablement aller plus loin. Nous ne voulons pas seulement la tolérance aux pannes, nous voulons des systèmes évolutifs.

Le problème avec l'évolution, c'est qu'elle introduit des changements, et les changements introduisent des points d'échecs. Examinons-les maintenant et ce que nous pouvons faire pour y remédier.

Nous pouvons toujours compter sur la métaphore infrastructure / architecture / ingénierie pendant que nous le faisons (après tout, nous sommes tous nous-mêmes des ingénieurs logiciels, bien qu'il n'y ait sans doute rien de tel que le génie logiciel ... pour l'instant). Il y a une raison pendant que le système de tubes est toujours actif (avec quelques pépins), alors que Big Ben fonctionne toujours (avec quelques pépins) ou que la Tour Eiffel est toujours debout. C'est parce que nous faisons avec des éléments vitaux (ou pas si vitaux) d'une infrastructure que nous devrions également faire avec un logiciel: une inspection continue. Ces entités n'ont pas nécessairement été conçues pour durer aussi longtemps, mais ont bénéficié d'une surveillance permanente et d'améliorations et de réparations en temps opportun lorsque cela était nécessaire. Appelez cela vos correctifs si vous le souhaitez.

D'un autre côté, certains modèles étaient destinés à durer et à fonctionner durablement sans interruption, même en sachant qu'une inspection continue ne serait pas possible. Dans ce cas, nous nous tournons vers un bon design et des modèles formels. Les éléments de fiabilité (disponibilité, fiabilité, sécurité, intégrité, maintenabilité) peuvent être quantifiés - pour un environnement donné. Les statistiques font le reste pour planifier le reste et l'avenir. Ce qui pose la question: est-il même possible pour nous de construire des systèmes qui seront évolutifs, au vrai sens du terme?

Jeff Langer dans Clean Code pose une question similaire ... sans référence aux tuyaux de vapeur:)

Et si vous pouviez suivre quatre règles simples qui vous aideraient à créer de bons designs pendant votre travail? Et si, en suivant ces règles, vous obteniez un aperçu de la structure et de la conception de votre code, ce qui facilitait l'application de principes tels que SRP et DIP? Et si ces quatre règles facilitaient l'émergence de bons designs?

Beaucoup d'entre nous estiment que les quatre règles de conception simple de Kent Beck sont d'une aide significative pour créer des logiciels bien conçus.

Selon Kent (dans Extreme Programming Explained), une conception est «simple» si elle suit ces règles:

• Exécute tous les tests
• Ne contient aucune duplication
• Exprime l'intention du programmeur
• Minimise le nombre de classes et de méthodes

Afin d'exécuter tous les tests ... nous avons besoin de tests pour fonctionner et c'est un énorme indicateur de la dette technique. Par exemple, s'il y a 10 000 cas de test dans un système comme Mercury Quality Center et qu'aucun de ces tests n'est automatisé, c'est un indicateur clair de la dette technique qui s'est constituée.

Et c'est là qu'intervient Feathers et son livre "Working Effectively with Legacy Code".