Smelly tables

Je rebondis sur l’article précédent pour dire tout le bien que je pense de l’utilisation de tableaux… ou pas!

Petit cas d’école :

On veut des tableaux!

“La MOA: Alors, on voudrait un tableau des sinistres sur le contrat, avec une quinzaine de colonnes, toutes triables.”
“Le développeur : OK. C’est quoi la volumétrie?”
“La MOA : On va partir du principe que les clients ne passent pas leur vie à avoir des dégâts des eaux et des accidents de voiture, donc 20-30 sinistres max par contrat.”
“Le développeur : Ca ne tiendra pas dans l’écran, il va falloir mettre en place une pagination, du type 10 résultats par page. Validé?”
“La MOA : Validé!”

Comme la volumétrie est faible, le développeur choisit de charger toute la liste et de laisser au composant le soin de gérer la pagination et les tris directement dans la couche client.

6 mois plus tard, c’est à dire, 2 mois de développement + 2 mois de recette + 2 mois de production (vive le cycle en V!), retour affolé de la MOA. Les performances de l’application sont catastrophiques, les utilisateurs se plaignent tout le temps.
Ben oui, parmi les contrats, certains sont ceux de grands loueurs de voitures! Les contrats portent sur l’ensemble de la flotte et les sinistres se comptes en… milliers!!! Je vous laisse le soin d’imaginer à quelle point la base de données et le serveur d’app sont plombés quand il s’agit de charger une liste pareille…

On gère la pagination

Si la volumétrie est importante, on n’a pas d’autre choix que de gérer la pagination directement en base de données.
Sauf que :

  • Ca complexifie le service de chargement des données : il faut gérer l’offset, le nombre de résultas max, la liste des colonnes triées et leur ordre
  • C’est impossible si vous avez eu le malheur de gérer vos données et vos libellés dans des supports de persistence différents (genre les données en base et les libellés en fichiers dans la webapp, ou les données dans un webservice et les libellés en local dans l’application)

Bref, les impacts sont lourds si le besoin a mal été défini et qu’il faut rectifier le tir.

Au fait, c’est pour quoi faire au juste?!

Oui, au fait, comment les utilisateurs se servent ils des tableaux :
“L’utilisateur : Alors, c’est simple : je veux retrouver le sinistre du contrat XXX en date du YYYY, alors j’ouvre la liste des sinistres du contrat, je trie par date, et… ah, j’ai 10 pages de résultats, bon, je vais cliquer sur la page 5. Ah non, la 6? Non plus, la 7 peut-être? Ah oui, ça y est!”

Smelly, isn’t it?

On fait quoi, alors?

La plupart des utilisateurs sont verrouillés sur de mauvaises habitudes acquises sur des vieilles applications client-serveur ou sur Excel.
Dans la plupart des cas, lorsqu’ils demandent des listes gigantesques et des fonctionnalités de tris, ils veulent en réalité des fonctions de recherche et de filtres, mais ils sont juste incapables de le réaliser. Ils pourront même se montrer un frein au changement si vous proposez autre chose.
Cette réaction est d’autant plus surprenant que lorsqu’elles se servent d’un moteur de recherche, ces mêmes personnes vont naturellement affiner les critères de recherche plutôt que d’aller consulter les résultats en page 4?!

En conclusion, avant de mettre en place une usine à gaz, n’hésitez pas à remettre en question le besoin exprimé, qui est souvent plus une solution qu’un besoin, pour identifier le besoin réel. En battez vous!
Et si vous devez effectivement vraiment mettre en place des tableaux, appuyez vous sur une solution intelligente du type du composant JQuery présenté par Alexandre. :)

VN:R_U [1.9.22_1171]
Rating: 0 (from 0 votes)
Share
Ce contenu a été publié dans Non classé, avec comme mot(s)-clef(s) , . Vous pouvez le mettre en favoris avec ce permalien.

Une réponse à Smelly tables

  1. Je n’avais jamais vu les choses sous cet angle là, très bonne idée !

    Un autre argument du “faut tout charger en mémoire”, c’est souvent des problèmes du type “les données doivent être filtrées à partir d’info qui proviennent d’un BPM / d’un système externe de gestion des droits”, etc. Et la solution ?

    1) Dénormaliser (et bah ouiiii….)
    2) Pas de BPM
    3) Pas de BPM
    4) Pas de BPM. T’es sourd ou quoi ? T’as pas compris ? Pas de BPM !! Pourquoi tu veux mettre un BPM ? Parce la MOA veut pouvoir garder la main sur les process métier ? De toute façon le BPM faudra bien l’intégrer… ya une équation simple :
    BPM = productivité / 42.
    5) Pas de BPM.

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)

Laisser un commentaire