Dans la mythologie de l‘heroic fantasy, le blob est un monstre gélatineux, de grande taille, dans lequel on ne parvient à distinguer aucune structure particulière. Tel un globule blanc, cette créature phagocyte tout ce qui s’en approche, et grossie à mesure qu’elle se nourrit. Le blob inspire la crainte, et personne ne souhaite vraiment s’en approcher.

Le code-blob, c’est une portion de code de l’application (généralement le corps d’une méthode ou d’une fonction) constituée d’un nombre important de lignes.

Les blocs conditionnels et les boucles sont de grande, voire de très grande taille. Le niveau d’imbrication est élevé. L’ensemble n’est pas structuré, et aborde d’un seul tenant de très nombreuses considérations : écriture dans un fichier texte, accès à une base de données, parsing d’un fichier XML, traitement métier, délimitation du périmètre transactionnel, libération des ressources, gestion d’erreur …

L’ensemble est très peu compréhensible. Certes, avec du temps et de l’énergie, on n’arrive effectivement à en acquérir une compréhension grossière. Le code ‘blob’ reste cependant très difficile à faire évoluer, à déboguer et à tester unitairement. En cas de problèmes de performances, le diagnostic est également considérablement complexifié.

Bien-sûr, personne ne souhaite vraiment intervenir dans un tel code. Ceux qui s’y frotte ajoutent généralement quelque lignes à la marge, et accumule les astuces pour ne pas risquer de perturber le fonctionnement de ce fragile édifice. Ce faisant, on nourrit le blob et il devient plus gros encore. Mais alors, pourquoi ne pas tuer le blob, plutôt que de le nourrir ?

Le problème est qu’en tuant le blob d’un coup net, il faut trouver une solution de rechange. Il faut soit réécrire, soit se lancer dans un refactoring plutôt ambitieux. Le coût d’une telle opération est difficile à justifier, d’autant plus qu’elle aboutit à des fonctionnalités strictement identiques. Cette approche contribue également à présenter la qualité uniquement sous la forme d’un coût, avec des bénéfices apparemment faibles.

Clairement, il est préférable de tuer le blob à petit feu : organiser progressivement l’intérieur du bloc, sortir progressivement les parties saines et les péreniser. Un tel travail n’est pas une tâche spécifique dans un planning, c’est un effort continu disséminé tout au long du projet. Au même titre que les tests unitaires, le maintien de la qualité du code est un effort réalisé lors de chaque tâche de développement.

Certes, on peut se trouver toutes les bonnes raisons du monde de remettre ce travail au lendemain. Mais il faut bien se dire qu’un code-blob nait de l’accumulation de petits efforts jamais entrepris. Annihiler un blob naissant ne prend que quelques minutes, tout au plus une demi-heure. Pas de quoi justifier un tâche dans un planning.