Archives de
Mois : septembre 2016

Pilier Rails 4 – Un paradigme unique tu refuseras

Pilier Rails 4 – Un paradigme unique tu refuseras

Il est toujours tentant de choisir une seule idée centrale pour sous-tendre votre architecture et de la suivre jusqu’à sa conclusion logique. Cette méthode séduit plus d’un programmeur. Rails est à l’opposé de ce principe.

Rails n’est pas un tissu uni et lisse, mais plutôt un patchwork, composé d’une variété d’idées et de paradigmes, dont certains qui pourraient sembler incompatibles s’ils étaient combinés deux à deux. Mais Rails n’est pas un championnat de la meilleure idée où un seul vainqueur serait choisi.

Prenez les templates qu’on utilise pour construire le view dans notre graphe Rails MVC.  Par défaut, tous les assistants qui nous permettent d’extraire du code de ces templates sont juste une bouillabaisse de fonctions, très semblable à une soupe PHP. Mais cette bouillabaisse fonctionne parfaitement lorsqu’on doit présenter des fonctions individuelles qui n’ont que rarement besoin d’interagir.

Cela ne veut pas dire qu’on n’a pas besoin de temps en temps d’avoir recours à quelque chose d’orienté objet lorsqu’on construit des views. Le concept de Presenters, dans lequel on emballe de nombreuses méthodes interdépendantes les unes des autres et les données en-dessous, s’avère parfois un antidote parfait à la bouillabaisse de fonctions. Mais cela arrive rarement.

La flexibilité idéologique de Rails lui permet de résoudre une large gamme de problèmes. La plupart des paradigmes individuels conviennent parfaitement pour résoudre un certain type de problèmes mais sont inadaptés et trop rigides dès qu’ils sont sortis de leur zone de confort. Appliquer des paradigmes en couches superposées permet de couvrir toutes les zones à problème et rendent le framework final plus puissant et bien plus flexible que tout autre paradigme individuel.

Mais cette flexibilité a un coût : elle requiert de maîtriser non seulement la programmation orientée objet mais également d’avoir pas mal d’expérience en programmation procédurale et fonctionnelle.  Cette contrainte concerne également les sous-langages de Rails : il est ainsi fort utile de maîtriser Javascript pour les views ou SQL pour résoudre quelques queries un peu plus complexes, du moins pour pouvoir profiter au mieux de toutes possibilités qui s’offrent à vous.

La seule façon de gérer cette contrainte est d’adopter la technique de la tortue plutôt que celle du lièvre pour apprendre en chemin, patiemment. Ce qui veut dire qu’au départ vous ne comprendrez pas forcément chaque aspect du framework mais cela ne vous empêchera pas de faire quelque chose de simple qui aura une réelle valeur.

Pilier Rails 3 – Un menu omakase tu utiliseras

Pilier Rails 3 – Un menu omakase tu utiliseras

Comment savoir quel plat commander dans un restaurant quand on ne sait pas ce qui est bon ? Si vous laissez le chef choisir pour vous, vous avez de fortes chances de déguster un bon repas. Tel est le principe de l’omakase.

En matière de programmation, ce principe consistant à laisser des experts choisir pour vous est proche du principe de Convention plutôt que Configuration mais à un niveau plus macro. Alors que le premier se concentre sur la meilleure façon d’utiliser des frameworks individuels, omakase se focalise sur le choix des frameworks et comment les assembler les uns avec les autres. Ce principe contraste donc avec la tradition forte en programmation de présenter les différents outils disponibles comme des choix individuels et de laisser au programmeur le privilège (et le fardeau) de décider le(s)quels il va utiliser.

Vous avez probablement entendu souvent ce conseil : « Utilisez le meilleur outil pour accomplir la tâche », mais la question de quel est le « meilleur outil » est souvent plus difficile à trancher qu’il n’y paraît au premier abord. Ruby a fait le choix de réduire le privilège du programmeur individuel, celui de choisir chacun de ses outils, au profit d’un plus grand bien : une boîte à outil plus performante pour tous.

Les bénéfices sont légion !

  • La force du nombre : l’expérience partagée par le nombre d’utilisateurs de Rails offre une base saine pour partager, débattre, et apprendre les uns des autres,
  • Les utilisateurs travaillent tous à améliorer la même boîte à outil : en tant que framework complet (Full Stack Framework), Rails inclut une variété de parties mobiles qu’il est important de savoir assembler. La plupart des difficultés rencontrées dans les logiciels provient non pas des composants individuels mais des interactions. Le travail commun de l’ensemble de la communauté Rails permet  de mieux comprendre et maîtriser ces interactions,
  • Des substitutions possibles mais pas obligatoires : si Rails est une pile de composants fonctionnant selon le principe omakase, il est toutefois possible de remplacer certains de ses frameworks et librairies par d’autres composants, mais ce n’est pas une obligation. Ce qui signifie que vous pouvez prendre le temps de développer une palette que vous maîtrisez bien avant de penser à remplacer certains de ses composants.