Pourquoi ajouter une couche supplémentaire à un ensemble souvent déjà bien garni? Éléments de réponse dans cet article.
Introduction
Aujourd’hui, chaque langage est entouré (submergé?) de frameworks plus ou moins aboutis, plus ou moins en vogue et plus ou moins maintenus. Il souvent complexe de choisir “le bon”, surtout si on attache de l’importance à la pérennité de l’application et à la formation des développeurs.
Écueils d’un projet sans framework personnel
Dans le cadre d’un projet important (plusieurs centaines de pages web), il est très facile d’utiliser un framework de plusieurs manières et rendre la maintenance rapidement complexe. L’affaire se complique encore si on ajoute des composants au dit framework (exemples au hasard: jQuery, Bootstrap). Et si plusieurs développeurs travaillent sur le projet, on multiplie d’autant les façons de faire la même chose.
Et donc au bout d’un moment, il devient impossible de changer de framework. Une fois que jQuery (toujours lui, au hasard) est implanté dans la plupart des pages pour lire et modifier les valeurs des champs, pour gérer les appels Ajax et l’animation de l’interface, le mal est fait. Et plus on avance dans le projet et pire c’est puisqu’on ne va pas hésiter à copier/coller un bout de code (appel Ajax, au hasard) voire rajouter un nouveau composant, au risque de générer un conflit dans certaines pages.
Alors, avec tout ça en tête, comment faire pour éviter un drame? Et bien c’est là qu’il faut mettre en place deux éléments.
Créer un framework d’abstraction
Un framework d’abstraction permet d’isoler votre application des autres frameworks. C’est lui qui va permettre de changer les frameworks de base sans trop de difficulté (c’est pas magique non plus hein! Virer Spring par exemple c’est à faire *avant* le début du projet sinon c’est trop tard).
L’autre responsabilité qui incombe à ce framework d’abstraction c’est d’unifier les pratiques et les composants. Côté front-end, il est fort utile de disposer d’une classe permettant de gérer des appels CRUD au back-end. En l’utilisant en lieu et place d’un appel Ajax, on évite d’avoir plusieurs formalismes (exemple: les paramètres dans une variable ou directement dans la méthode, avec ou sans gestion des erreurs, etc). Et surtout si on veut changer un élément (j’ai dû par exemple forcer l’ajout d’un paramètre aléatoire à chaque appel pour éviter la mise en cache trop sauvage de Chrome).
Ce même framework permet d’unifier les composants, comme les champs. On lit la valeur d’un champ texte différemment d’une liste ou d’un bouton radio. Avec son framework, on va unifier l’ensemble en ajoutant une classe “Field” qui va exposer deux méthodes: getValue et setValue. Dans chaque page, on déclare donc des champs et on les utilise, plus besoin de savoir de quel type de champ il s’agit. On peut même changer le type d’un champ (transformer une liste avec deux réponses en switch) sans rien changer au code Javascript.
Conclusion
Commencer un projet conséquent par mettre en œuvre un framework d’abstraction maison permet d’éviter pas mal de soucis tout en donnant plus de souplesse et en faisant économiser pas mal de temps et d’énergie.