Quand les abstractions fuient

Dans le monde du logiciel, nous utilisons constamment des abstractions pour faciliter notre travail, car elles nous abstraient d’autres domaines et réduisent considérablement la complexité à laquelle nous devons faire face. Un exemple d’abstraction est les ORM. Un ORM nous permet d’abstraire l’application de la base de données utilisée. Au lieu de devoir écrire des requêtes (spécifiques au moteur de base de données) pour accéder aux données, l’ORM nous permet d’utiliser le langage de programmation que nous utilisons pour coder l’application, également pour accéder aux données. Quiconque a utilisé des ORM sait que dans de nombreux cas, l’abstraction fonctionne bien et apporte beaucoup de valeur, mais lorsque l’application nous oblige à récupérer plusieurs entités liées, entre autres exemples, c’est là que nous commençons à voir les limitations. Dans ces cas, il est courant que les ORM ne génèrent pas toujours les requêtes optimales, ou qu’ils nous obligent à écrire un code excessivement complexe, si bien que parfois nous finissons par écrire des requêtes directement dans le langage de la base de données sous-jacente. Cela signifie mettre de côté l’abstraction pour ces cas.

C’est à ces moments-là, quand les abstractions commencent à « prendre l’eau », qu’une compréhension des domaines ou couches abstraites devient nécessaire. Cependant, les développeurs deviennent souvent de simples utilisateurs d’abstractions et ne s’intéressent pas à ce qui se trouve en dessous. Parfois nous faisons cela par manque de temps, mais dans bien d’autres cas, c’est par manque de bases ou d’intérêt.

De nos jours, il y a une prolifération d’écoles qui vous apprennent à programmer à partir de zéro en quelques mois, en général ces écoles se concentrent sur l’enseignement des langages et des frameworks au niveau utilisateur. Tout est très pratique et presque dès le début, vous programmez. Mais quiconque a emprunté le chemin de l’apprentissage de la programmation sait que cela prend des années, pas des mois. Et que cela nécessite bien plus de connaissances que simplement savoir utiliser un framework. Ce n’est qu’une question de temps avant que les étudiants de ces écoles ne rencontrent les limitations des abstractions. Dans ces cas, ils auront deux options : essayer d’éviter le problème, avec un contournement aux effets plus ou moins graves ; ou reconnaître qu’ils doivent approfondir le domaine abstrait et y travailler. Et seul un de ces chemins les rapprochera du statut de programmeur.

Cependant, ce n’est pas un problème qui n’affecte que les étudiants en programmation, tous les développeurs qui programment des applications avec un minimum de complexité se heurteront tôt ou tard à ce problème. Et je pense que les programmeurs acceptent souvent les abstractions comme parfaites, nous « tombons amoureux » des abstractions. Et nous oublions que ce sont des outils pour nous faciliter la vie, et comme tous les outils, ils ont des limitations.

Aujourd’hui, nous sommes confrontés à ce qui est probablement l’une des plus grandes abstractions de l’histoire, à savoir les modèles de langage IA, qui permettent de générer du code source à partir du langage naturel. Cette abstraction est si puissante que beaucoup croient qu’il ne sera plus nécessaire de savoir programmer pour créer des logiciels. Cependant, ceux d’entre nous qui ont utilisé cette technologie pour générer du code savent qu’elle a encore des limitations significatives qui nécessitent de solides compétences en programmation pour les surmonter. Bien que l’abstraction soit susceptible d’être affinée au fil du temps, je pense qu’il pourrait être une erreur de croire que nous pouvons former une nouvelle génération de développeurs sans compétences en programmation, tout comme les ORM n’ont pas éliminé le besoin de compétences en bases de données.

Bien que la valeur des abstractions soit indiscutable, car elles nous permettent de nous élever et d’entreprendre des objectifs plus ambitieux avec moins d’effort et de complexité, je considère comme très important d’être conscient qu’elles ne sont pas que des vertus, et qu’elles ont aussi des limitations qui ne peuvent être ignorées. De tout cela, je tire deux conclusions : d’une part, le choix d’une abstraction doit être fait en analysant à la fois ses vertus et ses inconvénients, en étant prêt à les abandonner si cette analyse est défavorable, et d’autre part, nous devons garder à l’esprit que lorsque nous nous heurtons aux limitations des abstractions, nous devrons avoir une bonne connaissance du domaine sous-jacent pour apporter une réponse solide. Si nous ou notre équipe n’avons qu’une connaissance de niveau utilisateur, ce n’est qu’une question de temps avant que nous ne rencontrions des problèmes que nous ne pourrons pas résoudre de manière satisfaisante.