samedi 20 novembre 2010

Frameworks, librairies, modules ...

posted May 11, 2010 9:27 AM by Guillaume BIBAUT   [ updated Jul 7, 2010 3:45 PM ]


De nos jours, on voit de plus en plus de technologies apparaitre, je ne saurais en citer quelques unes, car le but n'est pas d'en pénaliser.
De ces technologies se forment des communautés de développeurs, bien souvent provenant eux-même de différents horizons, différentes cultures, différentes façons de pensées. Chacune de ces communautés tente bien souvent de tirer le meilleur parti de ces technologies et propose dans le meilleur des cas des frameworks, ou des ensembles de librairies/modules, ainsi que des Best Practices (les meilleures pratiques d'utilisation).


Bien heureux celui qui y trouve rapidement son compte, mais bien souvent et malheureusement pour ceux qui tentent de trouver, d'utiliser certains de ces frameworks, on se retrouve vite avec des ensembles de classes qui font bien plus que ce qu'elles devraient faire.
De fait, nait de ces frameworks une complexité qu'il est difficile d'appréhender car au départ, chacun de nous part avec un besoin simple :


"Comment faire ceci de manière simple ? si j'y pense et que la technologie en question existe depuis un moment, je vais certainement trouver sur internet des réponses à mes questions, voir des frameworks m'aidant à faire ce que je veux de manière simple."

Personnellement et d'expérience, je suis rarement tombé sur la solution simple qui permet de faire une action tout aussi simple à exprimer, et ceci dans plusieurs langages de programmation. J'ai plutôt découvert bien souvent que là où une idée simple pouvait s'exprimer, une complexité sans pareille pouvait naître et rendre fastidieuse son utilisation.
C'est à s'en demander comment les personnes qui ont fournit ces frameworks en sont arrivées là.


Certes dans les technologies que nous utilisons en 2010, en existent certaines qui peuvent paraitre difficile à appréhender car elles sont grandement configurable, mais se dégage d'elles un schéma directeur qui est bien souvent simple.
Pourquoi ne pas se dire : "Cette idée n'existe pas dans ce langage de programmation, mais les classes disponibles dans celui-ci me permettent de reproduire telle utilisation, tel modèle. Comment puis-je rendre utilisable cet utilisation, ce modèle, de manière simple ?".
Ce que je comprend depuis maintenant un moment, c'est que ces personnes qui ont produits des frameworks bien complexe à utiliser n'ont saisi que la complexité de ce modèle, et donc ont rendu encore plus fastidieuse l'utilisation du modèle. Là où une chose simple aurait du naitre, une multitude d'autres choses
sont nées et celles-ci tentent de faire tout en même temps. C'est là où je me dis que ces personnes ont raté là où elles auraient du réussir.
Comment ? En ayant elles-mêmes les idées claires en se dégageant de la complexité, en rendant accessible ce qui ne l'est pas.


Une personne que je connais bien m'a dit il n'y a pas très longtemps, en remaniant un peu et en essayant de rester simple :


"Pour faire ceci, j'ai besoin de tout ça. Seulement, tout faire en même temps pour avoir mon résultat le rend bien trop complexe. J'ai donc décidé de tout scinder en actions beaucoup plus simples et autonomes.".

Ici, je parle des frameworks disponibles pour les différents langages de
programmation, mais il est possible d'appliquer le même raisonnement pour les projets informatiques. Pour exemple, certains d'entre eux deviennent bien souvent des "usines à gaz", comme on les
nomme si bien, car ces projets ont voulu tout faire au lieu de faire
juste ce à quoi elles auraient du être conçu.
On connait tous cette phrase, ou bien nous l'avons déjà entendu : "Il faut diviser pour mieux régner". Il me semble que la plupart des projets informatiques se sont fourvoyés car ils sont bien plus complexes que ce qu'il ne devraient être car :
  1. L'idée de base, bien que simple, n'a pas été comprise, ou n'a pas su être transmise de manière simple
  2. Les interlocuteurs ont eu peur de dire qu'ils ne comprenaient pas car c'est leur métier de "comprendre"
  3. Ces interlocuteurs ont produits nombres de documents tentant de répondre à une idée mal comprise, mal transmise
  4. Ces idées ont elles-même eu du mal à être assimilées par les intervenants du projet
Le résultat : une application qui fait plus que ce qu'elle aurait du faire, et qui embarque en plus de la complexité là où les actions sont pourtant simples.


Pour rendre une idée simple et la garder simple, il faut savoir l'exprimer avec des mots simples de sorte que l'on soit sûr de la faire comprendre. De la simplicité nait la simplicité.