Les béquilles en programmation — ce qu'elles sont, causes et quand elles sont justifiées

Qu'est-ce qu'une « béquille » en programmation

Une béquille (crutch) est une solution logicielle qui fonctionne mais est faite « à la hâte » : elle résout un problème spécifique mais n'élimine pas sa cause, ne suit pas l'architecture du projet et peut se casser au moindre changement dans l'environnement. La métaphore est juste — comme une vraie béquille, ce code aide à « marcher » mais ne guérit pas la « jambe ».

Les développeurs « étayent avec des béquilles » les bugs, les incompatibilités de versions, les particularités de plateforme et les exigences urgentes des clients. Une béquille typique est une béquille conditionnelle : si iOS 15, ajoute une marge ; si Huawei, cache le bouton. Ces vérifications se multiplient et transforment le code en un « gâteau en couches » de branches plateforme et version.

Les béquilles existent à différentes échelles : d'une seule ligne avec une condition de béquille à un module wrapper entier qui « corrige » le comportement d'une bibliothèque. Il est important de comprendre qu'une béquille n'est pas toujours mauvaise : entre de bonnes mains, c'est un outil qui permet de livrer un produit à temps. Le problème commence quand la béquille reste dans le code pour toujours.

Pourquoi les béquilles apparaissent : causes et contexte

La raison principale de l'apparition des béquilles est le conflit entre la solution idéale et les contraintes réelles du projet. Le développeur sait comment faire correctement, mais le temps, l'argent ou les limitations techniques l'en empêchent. Il en résulte une solution de compromis qui « fonctionne simplement ».

Examinons quatre raisons principales pour lesquelles les développeurs recourent consciemment aux béquilles. Comprendre ces raisons aide à traiter les béquilles non comme une erreur mais comme un outil pragmatique qui doit être géré.

Délais

La raison la plus fréquente. La sortie est demain, le bug ne se reproduit que sur un modèle spécifique, et le corriger architecturalement prendrait deux semaines. Une béquille conditionnelle prend une heure et résout le problème. Après la sortie, l'équipe promet de revenir et de réécrire correctement. « Rien n'est plus permanent qu'une solution temporaire » — c'est exactement à propos de ces béquilles.

Incompatibilité de versions

La bibliothèque A nécessite Android 12, mais votre application supporte Android 10. La solution est d'écrire un wrapper qui vérifie la version de l'OS et sélectionne le chemin d'exécution. C'est une béquille car lors de la mise à jour de la bibliothèque, le wrapper devra être réécrit. Mais l'alternative — abandonner la bibliothèque ou le support des anciens appareils — pourrait être pire.

// Béquille pour compatibilité API 29
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

Dépendances tierces avec bugs

Une bibliothèque dont dépend le projet a un bug, mais sa mise à jour pourrait prendre des semaines (PR nécessaire, révision de code, publication). Au lieu d'attendre, l'équipe écrit un wrapper qui corrige le comportement de la bibliothèque à la volée. Lorsque la version corrigée de la bibliothèque est publiée, le wrapper est supprimé. S'il n'est pas supprimé, c'est déjà un problème architectural.

Compréhension incomplète du système

Un nouveau développeur dans un projet legacy ne comprend pas pourquoi le code fonctionne ainsi. Au lieu de comprendre, il ajoute une nouvelle condition par-dessus les existantes. C'est le type de béquille le plus dangereux car l'auteur ne réalise pas que c'est une béquille. Le seul remède est la révision de code et la programmation en binôme pour les nouveaux membres de l'équipe.

Quand une béquille est justifiée : approche pragmatique

Ce n'est pas chaque béquille qui est mauvaise. Dans le développement réel, la pureté absolue du code est inaccessible et souvent peu pratique. Une approche pragmatique reconnaît que les solutions temporaires font partie du processus, mais exige la conscience, la documentation et un plan de suppression. Une béquille est justifiée lorsqu'elle résout un problème métier plus rapidement qu'une solution architecturale propre.

Les critères d'une béquille justifiée : elle résout un problème spécifique, elle a un responsable (quelqu'un chargé de sa suppression), et il existe un plan de réusinage. Si au moins une de ces trois conditions manque, la béquille se transforme en dette technique. Des outils comme les commentaires TODO avec un ticket dans le tracker sont la méthode de documentation minimale.

Exemple d'une béquille justifiée

Un bug critique dans la branche de release qui doit être corrigé avant le déploiement de demain. La solution propre nécessite un réusinage architectural et prendrait deux semaines. La béquille : ajouter une vérification nil et envoyer le correctif en hotfix. Conditions de justification : un ticket de réusinage a été créé dans le tracker, un responsable a été désigné et la béquille est marquée d'un commentaire. Deux semaines plus tard, l'équipe revient à la tâche.

// TODO: IT-1234 — supprimer cette béquille après le réusinage d'AuthService
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

Comment distinguer une béquille temporaire d'un problème architectural

La frontière entre une béquille consciente et un problème architectural (dette technique) passe par deux paramètres : la conscience de la décision et l'existence d'un plan pour l'éliminer. Une béquille est toujours une solution temporaire avec une durée de vie connue. La dette technique est la conséquence de nombreuses béquilles laissées sans attention.

Quand une béquille devient un problème

La situation s'aggrave lorsque le nombre de béquilles dépasse une masse critique. Chaque nouvelle béquille augmente la « fragilité » du système : un changement à un endroit en casse un autre. Finalement, le développement ralentit, les bugs se multiplient et un nouveau développeur ne peut pas comprendre le code sans l'aide de l'auteur. À ce stade, les béquilles cessent d'être des solutions temporaires et deviennent un problème architectural.

Signes d'une crise de béquilles

Si le code contient cinq vérifications imbriquées de la version de l'OS, du fabricant de l'appareil et de la présence d'une bibliothèque spécifique — ce n'est pas une béquille, c'est un problème architectural. Si l'ajout d'un correctif provoque trois régressions dans des modules connexes — les béquilles ne sont plus locales. Si les révisions de code sont régulièrement rejetées à cause d'« encore une béquille » — il est temps de planifier le réusinage.

• La même béquille se répète à trois endroits ou plus — il est temps de créer une solution unifiée
• Une béquille vit plus de trois sprints sans plan de suppression — c'est déjà de la dette technique
• Un nouveau développeur ne comprend pas pourquoi le code fonctionne ainsi — la béquille n'est pas documentée
• La suppression de la béquille provoque une réaction en chaîne d'erreurs — la dépendance à la béquille est devenue architecturale

Réusinage des béquilles : stratégie et pratique

Réusiner les béquilles est le processus de remplacement des solutions temporaires par des solutions architecturalement correctes. Cela prend du temps, donc une stratégie de priorisation est nécessaire : toutes les béquilles n'ont pas besoin d'être éliminées immédiatement. Une bonne stratégie consiste à évaluer chaque béquille selon deux paramètres : la fréquence des changements dans cette zone de code et l'impact sur les utilisateurs.

Stratégie de priorisation

Priorité élevée — les béquilles dans les modules fréquemment modifiés (logique métier, UI à usage général) qui ralentissent le développement et provoquent des régressions. Priorité moyenne — les béquilles dans les modules rarement modifiés mais avec un impact potentiel sur les utilisateurs (traitement des paiements, autorisation). Priorité faible — les béquilles dans le code legacy qui fonctionne de manière stable et n'est pas prévu pour modification.

Processus de suppression étape par étape

Étape 1 : inventaire — trouvez tous les TODO et FIXME liés aux béquilles. Étape 2 : évaluation — déterminez lesquels sont encore pertinents. Étape 3 : planification — planifiez le réusinage des béquilles dans un sprint, en commençant par les priorités élevées. Étape 4 : remplacement — implémentez la solution propre, supprimez la béquille et son commentaire TODO. Étape 5 : vérification — assurez-vous que les tests passent et qu'il n'y a pas de régressions.

# Trouver toutes les béquilles TODO dans le projet
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

Prévention de nouvelles béquilles

La meilleure façon de lutter contre les béquilles est de ne pas en créer inutilement. Avant d'écrire une béquille, posez-vous trois questions : puis-je implémenter une solution propre dans un délai raisonnable ? Existe-t-il une alternative qui n'est pas une béquille ? L'équipe aura-t-elle le temps de revenir et de réécrire cela ? Si la réponse à au moins une question est « non » — réfléchissez à nouveau avant d'« étayer » le code.