Livre blanc : Maîtrisez votre dette technique

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 ».

Publié par

Publié par Nicolas Jozwiak

Nicolas est delivery manager disposant de 12 ans d’expérience en conception et développement. Son parcours chez un éditeur avant son entrée chez Xebia lui a notamment permis de développer de solides compétences dans le domaine de la qualité et de l’industrialisation (tests, intégration continue, gestion de configuration, contrôle qualité). Bénéficiant d’une expérience très solide de mise en place des méthodes agiles et d’accompagnement d’équipes sur le terrain, il s’attache à mettre à profit quotidiennement son expérience qui est reconnue pour son approche pragmatique, proactive et pédagogique.

Commentaire

4 réponses pour " Livre blanc : Maîtrisez votre dette technique "

  1. Publié par , Il y a 5 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

  2. Publié par , Il y a 5 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)

  3. Publié par , Il y a 5 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

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.