Quand une abstraction logicielle mérite sa place

Une abstraction logicielle peut faciliter le travail avec un système, mais uniquement si elle masque les bons détails. Masquer du code ne suffit pas. La bonne question consiste à savoir si une structure partagée élimine des décisions qui ne devraient pas être prises de façon répétée tout en préservant les différences qui restent importantes.

L’abstraction devient ainsi un choix de conception plutôt qu’un rituel de nettoyage. Une équipe doit identifier la promesse qui est créée, les cas qui y correspondent et le travail nécessaire lorsqu’un cas n’y correspond pas. Les éléments les plus probants proviennent de changements concrets et de conditions opérationnelles, et non de l’élégance apparente de la structure lorsqu’elle est considérée isolément.

Demandez ce que l’abstraction apporte

Une abstraction est une interface simplifiée placée au-dessus des détails sous-jacents. Une interface, dans ce contexte, est l’ensemble des entrées, des sorties et des attentes par lequel une partie d’un système interagit avec une autre. Une abstraction utile donne à la partie appelante un problème plus restreint et plus stable à comprendre.

Commencez par nommer la décision qui disparaîtrait. Si plusieurs modules doivent formater des requêtes équivalentes, appliquer la même transition ou traduire le même état interne, une frontière partagée peut supprimer une duplication significative. Si la couche proposée se contente de donner un nouveau nom à une opération existante, sa valeur est moins évidente.

• Formulez la décision répétée dans un langage courant au lieu de faire uniquement référence au code répété.
• Identifiez les détails sous-jacents que les parties appelantes ne devraient plus avoir besoin de comprendre.
• Décrivez la promesse stable que l’abstraction ferait à chaque partie appelante.
• Laissez les différences visibles si leur combinaison exige des indicateurs, des exceptions ou des branchements cachés.

Commencez par une séquence de travail réelle

Un candidat utile apparaît souvent plus clairement lorsque l’équipe suit une tâche réelle depuis l’entrée jusqu’au résultat. Ce suivi doit inclure la validation, les changements d’état, les effets secondaires et la gestion des échecs. Un effet secondaire est une modification extérieure au calcul immédiat, comme le stockage de données ou l’envoi d’une requête.

L’objectif n’est pas de forcer tous les parcours à intégrer un seul flux de travail. Il s’agit de trouver les points de contrôle où plusieurs parcours nécessitent la même décision. Ces points de contrôle peuvent devenir des frontières entre modules, tandis que les étapes véritablement différentes restent explicites. Cette approche maintient l’abstraction liée au travail que le système doit déjà effectuer.

1. Choisissez une tâche représentative suffisamment bien comprise pour pouvoir l’examiner sans faire de suppositions.
2. Repérez chaque point où le code doit interpréter, valider, transformer, stocker ou signaler quelque chose.
3. Comparez une autre tâche pertinente et notez les décisions qui sont équivalentes, et non simplement proches.
4. Dessinez une frontière autour des décisions partagées, puis laissez les décisions différentes à l’extérieur.
5. Parcourez un cas délicat avant de vous engager en faveur de la forme proposée.

Mesurez le coût des deux côtés

L’abstraction remplace une forme de complexité par une autre. La répétition peut diminuer tandis que l’indirection augmente. L’indirection signifie que la compréhension d’une opération exige de la suivre à travers une autre couche. Ce compromis peut être pertinent lorsque la nouvelle couche centralise une règle significative, mais il l’est moins lorsque les lecteurs doivent passer d’un fichier à l’autre pour reconstituer une action simple.

L’évaluation doit inclure la maintenance en dehors du parcours principal. Prenez en compte le débogage, les tests, la migration, le signalement des erreurs et la suppression. Si l’abstraction est responsable d’une politique, elle doit également offrir un emplacement clair où cette politique peut être examinée et modifiée. Dans le cas contraire, la complexité a été dissimulée plutôt que réduite.

• Coût de lecture : une personne chargée de la maintenance peut-elle comprendre ce qui se passe sans ouvrir sans cesse l’implémentation sous-jacente ?
• Coût du changement : un changement courant devient-il local ou les parties appelantes doivent-elles encore coordonner leurs propres variantes ?
• Coût de l’échec : une erreur peut-elle être suivie jusqu’à la frontière pertinente avec suffisamment de contexte pour agir ?
• Coût de sortie : la couche pourrait-elle être supprimée ou remplacée sans réécrire des parties sans rapport avec elle dans le système ?

Définissez les frontières et les voies de sortie

Une frontière doit préciser ce dont elle est responsable et ce qui reste sous la responsabilité de la partie appelante. Cela réduit le couplage accidentel, c’est-à-dire une dépendance entre des composants qui n’a pas été conçue délibérément. Par exemple, une abstraction de stockage pourrait être responsable de la traduction des données tout en laissant la politique de nouvelle tentative au flux de travail appelant, si cette séparation correspond aux besoins opérationnels du produit.

Les voies de sortie méritent la même attention. Un cas inhabituel peut nécessiter un accès direct à une opération de plus bas niveau, une implémentation distincte ou une absence totale de participation à l’abstraction. Il n’est pas recommandé de fournir des contournements illimités. Il faut éviter de déformer l’interface commune jusqu’à ce qu’elle puisse représenter chaque cas hypothétique.

Testez la promesse face au changement et à l’échec

Le meilleur test repose sur un petit ensemble de changements plausibles. Demandez-vous ce qui se passerait si une entrée recevait un nouveau champ, si une dépendance renvoyait une erreur inconnue ou si un flux de travail nécessitait un point de contrôle supplémentaire. Il s’agit de sondes hypothétiques, et non de prévisions. Elles révèlent si l’abstraction représente un concept stable ou une similitude temporaire.

La fiabilité dépend également d’une responsabilité visible. Une carte de fiabilité peut montrer les états environnants que le système central gère, ceux qu’il signale et ceux qui nécessitent encore une intervention ailleurs. L’abstraction ne doit pas laisser entendre qu’elle résout des situations qui dépassent sa responsabilité. Il est plus facile de raisonner sur une promesse restreinte et exacte que sur une promesse étendue reposant sur des exceptions cachées.

Choisissez la plus petite promesse stable

Avant d’adopter une abstraction, formulez sa promesse en une phrase et confrontez cette phrase aux cas actuels, à un cas délicat et à un changement plausible. Comparez ensuite la structure proposée avec l’option plus simple consistant à conserver le code séparé. Si la couche élimine des décisions répétées et clarifie la responsabilité, elle a une raison pratique d’exister.

Si la promesse dépend de nombreuses conditions, conservez des implémentations séparées et réexaminez le modèle lorsque le comportement concerné sera mieux compris. Le choix ne se situe pas entre l’abstraction et le désordre. Il porte sur différentes manières de placer la complexité. Préférez la plus petite frontière qui facilite la recherche, la modification, le test et la suppression d’une règle importante.