Il y a 12 ans -
Temps de lecture 1 minute
Livre blanc : Maîtrisez votre dette technique
Le 4 Juin 1996, à 9h35 le vol 501 de la fusée Ariane 5 effectue son premier décollage. Quelques secondes plus tard, le système de guidage inertiel reçoit trop d’informations et se met hors service, car reconnu défaillant. L’ordinateur de bord est alors notifié qu’un dysfonctionnement est en cours et compromet les informations concernant la trajectoire de la fusée. Cette modification de la trajectoire entraîne l’arrachage d’un moteur d’appoint, déclenchant l’auto destruction de la fusée. Des analyses plus approfondies ont démontré que le système de guidage inertiel est lui même la cause de cet échec. Conçu à l’époque pour Ariane 4, il n’était plus nécessaire pour Ariane 5. Maintenu actif pour des raisons de commodité, ce système s’est avéré être à l’origine d’un des bugs informatiques les plus coûteux de l’histoire.
Au-delà du caractère spectaculaire de cet exemple, il est intéressant de noter que l’origine du dysfonctionnement réside dans un module développé pour une version antérieure de la fusée et devenu obsolète. Ce vestige de code, maintenu dans l’application sans être nécessaire pour son fonctionnement, est l’une des formes de ce que Ward Cunningham désigne sous le terme de dette technique.
A travers ce document, nous découvrirons en quoi la dette technique ralentit la productivité des équipes et nuit aux projets. Nous mettrons en évidence ses mécanismes sous jacents et les leviers d’actions dont nous disposons. Enfin, nous montrerons comment elle se gère au quotidien, par l’instauration de bonnes pratiques de développement et la mise en place d’outils, pour enfin aborder quelques stratégies complémentaires, mais essentielles pour venir à bout de la dette technique.
Télécharger le Livre blanc « Maîtrisez votre dette technique » rédigé sous Xebia devenue l’entité Engineering de Publicis Sapient.
Commentaire
4 réponses pour " Livre blanc : Maîtrisez votre dette technique "
Published by Fabian Piau , Il y a 12 ans
Pour Sonar, il faut ajouter un plugin pour connaitre la dette technique du projet (le montant en dollars sur le dashboard): http://docs.codehaus.org/display/SONAR/Technical+Debt+Plugin
Et cette page : http://docs.codehaus.org/display/SONAR/Technical+Debt+Calculation explique comment elle est calculée (plutôt intéressant de savoir ce qui se cache en dessous)
Published by inf0mag , Il y a 9 ans
Bonjour,
dans votre livre vous parlez des refactorings majeurs qui selon votre définition « concernent des modifications de code pouvant grandement impacter d’autres
portions de codes, avec potentiellement des conséquences sur le comportement de l’application »
Je ne comprends pas en fait !
Les refactorings sont par définition des restructurations de l’application sans toucher à son comportement externe, les refactorings majeurs touchent au comportement de l’application, pourquoi les considérer dans ce cas comme refactorings ?
D’autre part, tous les changements que peut subir un système (ajout, modification, changement d’environnement ..) peuvent être appliqués en utilisant des opérations de refactorings ?
Merci
Published by Nicolas Jozwiak , Il y a 9 ans
Bonjour,
Dans le livre j’ai pris le parti de faire la distinction entre les refactorings :
– mineurs pour les renommages et détections de portion de code similaires. En résumé nous faisons confiance à notre IDE pour ces opérations.
– majeurs pour les simplifications algorithmiques par exemple. Si l’on cherche à simplifier un algorithme ou le rendre plus performant, il y a un risque de changer son comportement, et donc celui d’une partie de l’application. Avoir des tests permet de s’assurer des éventuelles régressions.
Concernant votre dernière question, il est tout à fait possible et même conseillé d’utiliser du refactoring pour les changements apportés à un système.
Nicolas (Xebia)
Published by inf0mag , Il y a 9 ans
Bonjour,
Si quelqu’un vous pose la question : quelle est la différence entre refactorings, model checking et tests logiciels (ou encore l’intérêt et le rôle de chaque méthode), comment vous répondez ?
Merci