Le code d'abord : Les dangers d'une approche fondée sur le code d'abord

Le cadre de mappage objet-relationnel (ORM) propose une approche code-first comme option viable pour modéliser les structures de données. En réduisant une étape du développement d’une application commerciale, le cadre “code first” promet un moyen efficace de créer des logiciels sans trop de difficultés.

Mais il a ses avantages et ses inconvénients. Dans ce blog, notre équipe met en lumière certains des dangers de l’approche “code first”.

Comprenons d’abord le sujet en question.

Qu’est-ce que Code First ?

Traditionnellement, lorsque vous créez une application, en particulier une application commerciale, vous tenez compte de la structure des données. Vous développez une base de données avec l’aide d’une équipe aux compétences diverses qui, ensemble, élaborent le code, lequel est ensuite vérifié et exécuté. Nous utilisons deux méthodes différentes pour conceptualiser les environnements que nous essayons de formaliser avec des logiciels.

Deux mondes sont donc impliqués dans le processus de création d’une application :

• Modèle relationnel: Il s’agit d’un cadre de description d’un domaine. Il fonctionne avec la structure de la base de données, son code et les données au repos.

• Modèle d’objet: Le deuxième modèle est celui du code de l’application. Il s’agit de la représentation visuelle de l’application.

Nous devons vérifier la maintenance de ces deux mondes ensemble, mais séparément. Ces deux modèles ont leurs forces et leurs faiblesses dans la conception d’un domaine donné. Autrefois, lorsque les développeurs travaillaient sur des projets qui nécessitaient la modélisation de ces deux paysages, cela donnait lieu à ce que les informaticiens appellent une inadéquation d’impédance (problèmes dus à l’incohérence entre la base de données et le modèle de programmation). Tout cela peut entraîner de nombreux problèmes.

Même si l’application est construite avec un minimum de décalage d’impédance, des problèmes surgiront au moment de la modifier.

C’est alors que sont apparus les wireframes qui ont permis aux développeurs d’accéder plus facilement à la base de données à partir du code sans connaître la base de données. Ces cadres ont encore évolué et le code peut désormais être traduit dans la structure de la base de données.

Le maintien de deux mondes distincts pour la base de données et le code de l’application a rapidement disparu avec cette découverte. Les wireframes s’occupaient de la base de données en s’occupant du code. Vous n’avez plus qu’à travailler sur un seul monde, et c’est ce qu’on appelle une idée séduisante.

La méthodologie “code first” est partie de cette idée et a tiré parti de l’évolution technologique. Elle agit comme un marteau de forgeron, en rendant les différents domaines de modélisation opaques pour le développeur de logiciels. Ainsi, au lieu d’avoir deux environnements de travail distincts, les développeurs ne doivent travailler que sur un environnement de modélisation d’objets (OME).

En d’autres termes, si vous utilisez un cadre de travail où le code prime, vous allez définir l’environnement commercial en utilisant un seul langage de modélisation, qui sera un langage objet. Et le code que vous utiliserez fera de son mieux pour traduire vos engagements de modélisation dans l’espace relationnel ou l’espace que vous utilisez.

La nécessité de deux équipes distinctes pour créer une application ayant disparu, le slogan est devenu “il suffit de commencer à coder”. Construisez vos objets et les référentiels de base de données qui contiennent ces objets, faites persister ces objets, et tout se mettra en place comme par magie.

Comprendre à travers un exemple le fonctionnement du modèle Code-First

Supposons qu’un éditeur s’adresse à un développeur et qu’il ait besoin d’un nouveau système de suivi des livres et des auteurs. L’ancienne façon de construire le système consisterait à faire participer un analyste commercial au projet et à créer un modèle d’information canonique des livres et des auteurs. Ce modèle canonique est ensuite partagé avec les architectes des bases de données et des applications. Les deux développeurs récapituleront alors ce modèle en termes susceptibles d’être utilisés pour la construction d’une base de données et en termes susceptibles d’être utilisés pour la construction de la couche d’application. Par conséquent, les architectes de bases de données et d’applications parlent tous deux de la même chose, mais l’un travaille en dot net et l’autre en SQL.

Selon le code first, le BA continue à développer le modèle canonique, mais il ne le partage qu’avec un seul architecte. Ce développeur récapitulera le modèle dans un environnement objet. Ensuite, un cadre code-first construira le modèle objet dans un langage que la base de données persistante, souvent une base de données relationnelle ou une base de données objet, peut comprendre.

Les dangers du code d’abord

Les frameworks “code first” sont souvent utilisés dans de petits projets, et parfois les entreprises les étendent à des projets à grande échelle, ce qui est dangereux. Mais ce qui se passe dans les petits projets, c’est que les chefs d’entreprise mettent souvent directement un développeur au travail sur le projet sans aucune analyse préalable par un BA.

Le projet étant à plus petite échelle, le développeur se lance tête la première dans le codage. Il construit les objets qui représentent les besoins de l’application.

Entre-temps, le développeur et le propriétaire de l’entreprise oublient que l’application est un modèle du monde réel. La transition d’un monde réel à un monde virtuel est mieux réalisée par une personne hautement qualifiée. Un développeur et un architecte n’y parviennent pas, car ils sont formés à étayer un modèle dans l’espace numérique. En revanche, un analyste comprend comment modifier un modèle du monde réel pour l’adapter à l’espace numérique et apporte ce modèle aux développeurs. Ainsi, un risque important du “code-first” est d’ignorer l’analyse commerciale et de se précipiter sur le développeur.

Le deuxième risque est la performance du système. Ainsi, le cadre du code-first implique souvent qu’il y ait un mappeur objet-relationnel (ORM) dans le mélange. Le code-first permet au développeur de travailler dans un seul environnement de modélisation, l’OME. Cela signifie que nous dépendons d’un logiciel tourné vers l’avenir pour écrire des requêtes.

Chez DOOR3, nous avons aidé de nombreux clients qui s’étaient déjà lancés dans un projet d’application “code-first”, avaient construit quelque chose, l’avaient fait accepter en production, puis l’avaient vu s’arrêter. Après inspection, nous avons constaté que le code SQL avait été écrit d’une manière tellement sous-optimale par l’architecture code-first ou l’ORM que nous avons dû le remplacer par du code écrit à la main. La performance est donc un autre élément à surveiller lorsque l’on travaille avec le code-first.

Tout ceci peut également conduire à la maintenabilité de la performance. Bien qu’il soit plus facile de travailler avec le code first, une chose qui frustre beaucoup de développeurs est qu’il n’y a pas d’outil présent dans l’ORE en termes de réglage de l’application. Tout se fait par l’intermédiaire de l’ORE dans l’application. Dès que vous commencez à apporter des modifications unilatérales au niveau du stockage, vous pouvez casser l’ORM ou limiter l’ORM à cette section de modifications.

Conclusion

Nous avons donc discuté de ce qu’est l’approche “code first” et des risques cachés qu’elle comporte. Même si le modèle présente quelques problèmes d’efficacité, il reste très efficace pour créer des applications à petite échelle et stimuler la croissance. Si vous souhaitez en savoir plus sur nos services, contactez-nous.