BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Plongée dans le dark code

Plongée dans le dark code

Favoris

Le dark code et le code legacy sont deux faces d'une des difficultés majeurs de toute entreprise créant des logiciels. Travailler sur du code legacy n'est pas toujours l'activité la plus glorieuse pour un développeur, et devient souvent un élément crucial de la bonne marche d'une entreprise.

Au fil du temps, le code devient un "gros tas de boue". Transmuter cet artefact devenu sale en un code lisible et évolutif tient souvent du chemin de croix et se solde souvent par un projet de refonte. Vous connaissez la suite de l'histoire.

Durant la Qcon London 2017, qui s'est tenue du 6 au 8 mars, une track complète était consacrée au sujet du Dark code et du legacy.

Nous revenons ici sur trois présentations de cette session avec :

  • Une analyse sur les stratégies pour la suppression de code.
  • Un outil de visualisation pour maintenir la qualité de code chez Tesla.
  • Une méthode "boule de cristal" pour découvrir les éléments les plus importants à refactorer.

Strategic Code Deletion

Michael Feathers introduit la track avec quelques pratiques permettant de supprimer du code. Il postule que tout développeur adore écrire du code, mais pas le supprimer. Un logiciel est un peu comme votre garage : si vous n'y prenez garde, vous avez tôt fait de ne plus pouvoir rentrer dedans.

Il y a souvent des tonnes de code non utilisées, ou qui produisent peu de valeurs. La manière la plus commune pour le travailler est la couverture de code, souvent insuffisante. Michael distingue :

  • Le code inatteignable : c'est celui qui n'est jamais utilisé.
  • Le code mort : c'est celui utilisé mais dont les résultats ne servent pas.
  • Le code à faible valeur : comme son nom l'indique, et il est très compliqué de le qualifier au vue des données actuelles.

La couverture de code est peu utile pour les deux premiers cas. A la place, vous pouvez utiliser des tests de mutabilité. Il y a plusieurs manières de comprendre votre code :

  • gprof ou ses équivalents.
  • Le stack sampling pour profiler les usages CPU des briques de code.
  • Enfin le "feature probing" qui consiste à poser des marqueurs et à les enregistrer, et à vérifier la présence de tous.

Le code mort ou le code inatteignable sont simples à travailler. Le code à faible valeur est plus complexe et implique la construction d'une stratégie. Il vous faut couper les points d'entrée, vérifier des échantillons et laissez le développeur nettoyer.

Michael postule qu'au lieu de nettoyer, la pratique usuelle est la réécriture systématique. C'est une option souvent utilisée alors que la compréhension du code est incomplète. Dans ce genre de cas, les questions clé sont :

  • Pouvez-vous trouver toutes les entrées et sorties ?
  • Réduisez-vous la conditionnalité : moins de conditionnalités rend le code plus simple ?
  • Pouvez-vous exécuter le code en parallèle : faites tourner le code ancien et nouveau en même temps pour vérifier que vous pouvez opérer le transfert ?
  • Avez-vous défini un périmètre sur la caractérisation des tests ?

Michael propose la démarche suivante pour définir les tests de caractérisation :

  • Commencer avec de nouvelles fonctions anonymes tant que vous ne savez pas trop ce que fait le code.
  • Une fois que vous avez compris, renommer le test.
  • Ceci permet de définir et documenter les comportements actuels et démarrer une conversation sur ce que le code devrait faire.
  • Trouver ce qui est essentiel.

La conclusion de Michael est qu'il est difficile de supprimer du code, et que c'est un bon levier d'apprentissage sur l'utilisation actuel du code et des systèmes.

Retour d'expérience sur les Quality Views chez Tesla

Colin Breck présente un retour d'expérience pour sortir du "Big Ball of Mud" (Foote and Yoder - 1999) et commencer à discuter avec vos clients avec les Quality Views. Quand vous travaillez chez Tesla, vous construisez des produits incroyables, et donc le logiciel sous jacent devrait être de la même teneur.

En règle générale, quand vous lancez un POC (ou un MVP, ou n'importe quel mot magique du moment), un bon développeur, explique Colin, utilise :

  • Des raccourcis : "bien sûr que c'est temporaire, sauf si ça marche".
  • Des incompréhensions : 90% du travail logiciel est invisible.

Le principe des Quality views est une manière de visualiser l'architecture d'un logiciel en s'inspirant de divers éléments :

  • La taille des boîtes des diagrammes standard.
  • Le nombre de serveurs des diagrammes classiques d'architecture.
  • La taille des données (en reprenant les cartes de Ménard).
  • Un niveau de confiance avec une couleur (code, test, déploiement, monitoring, alerting, securité, haute disponibilité, scalabilité, risque).

Exemple de Quality View

La narration autour de l'image permet d'engager une discussion et construire des actions communes. Et Colin propose d'itérer régulièrement sur cette vision pour avancer.

Colin conclut en posant que les Quality Views sont un moyen de sortir du système 1 de penser.

Ma boule de cristal pour prioriser la dette technique

Adam Tornhill, auteur de Your code as a crime scene présente ses méthodes pour travailler la dette technique.

Il part d'un constat sur ce concept emprunté au monde financier : une dette implique un taux d'intérêt qui est une fonction du temps. Si vous vouliez vraiment la gérer, il vous faudrait un espace temporel pour la faire fructifier. Cependant, en y regardant de plus près, la majorité de la dette technique n'est pas très technique. C'est un symptôme et non le problème.

Adam propose alors d'adopter une posture holistique, et une liste idéale d'informations pour choisir les intérêts à rembourser :

  • Où sont les plus forts taux d'intérêt ?
  • L'architecture est-elle congruente avec l'évolution du système ?
  • Y a-t-il des points de contention sur de la coordination inter-équipes ?

Ces informations ne sont pas du code, continue Adam. Et il manque une dimension temps et social qui se retrouve... dans la gestion de sources.

Pour avancer, Adam propose d'utiliser une cartographie en "HotSpot" :

  • Parcourrez les répertoires.
  • Positionnez une taille pour mesurer la complexité (n'importe laquelle, toute étant mauvaise).
  • Ajoutez de la couleur pour la fréquence de changement.

Ces Hotspots ne sont pas toujours suffisants, il faut parfois aller plus loin, continue Adam. C'est un peu comme un rayon X, qui répond à la même pratique au niveau des fonctions, et permet d'agir.

Adam propose également d'étendre ce fonctionnement aux patterns d'architecture : il vous reste à ajouter la complexité, et utiliser des critères de regroupement sur les fichiers autour d'un comportement ou domaine. D'après Adam, les Hotspots permettent d'identifier les forces gravitationnelles de votre base de code.

Un autre aspect de la démarche est de travailler sur le couplage temporel, c'est à dire les modules changés au même moment. Avec une architecture en couche, il observe que 30 à 70% des changements se propagent à toutes.

Adam propose les outils suivants pour cette vision :

La suite, d'après lui, est de rentrer dans les aspects sociaux du code :

  • Il existe des déperditions dans les processus qu'il est au mieux, possible de réduire. L'un des aspects principaux est la diffusion de la responsabilité : plus le groupe est important, plus la probabilité que quelqu'un vienne aider est faible. Dans le logiciel, cela s'appelle le "code ownership". Il serait possible de le mesurer (d'Ambros, Lanza et Gall), voire même de mesurer la loi de Conway.
  • Le reste consiste à l'ajustement des indicateurs, en particulier sur les risques et la sécurité).

Evaluer cet article

Pertinence
Style

Contenu Éducatif

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT