La vie est une pièce de théâtre : ce qui compte, ce n'est pas qu'elle dure longtemps, mais qu'elle soit bien jouée – Sénèque

Rappelez-vous : nous pouvons facilement générer une route, et nous avons un template de base pour nos pages, le tout fièrement propulsé par le framework Codeigniter.
Nous allons donc maintenant nous atteler gaiement à ce qui va constituer le cœur du travail de refonte : la réécriture de toutes les pages.
Mais un problème de taille se présente. Car des pages d'administration sur Shop Application, il y en a beaucoup…
Vraiment.. beaucoup !

Croyez-moi, je fais partie de l'équipe de Shop Application depuis bientôt 4 mois et je travaille uniquement sur la refonte. Et bien je découvre encore des nouvelles pages tous les jours.
C'est aussi la force de notre solution: elle est particulièrement complète.

Alors par où commencer, et surtout comment ?
Et bien, vous savez comme manger un éléphant ? Une bouchée à la fois !
Nous allons donc développer les pages les unes après les autres, méthodiquement.

Pour mesurer l'effort nécessaire, l'ensemble des pages ont été répertoriées et notées selon leur complexité.
Pour les noter, deux critères sont retenus  : la complexité fonctionnelle de la page et la complexité de son code.
Il suffit ensuite de faire la moyenne de ces deux critères et de la majorer de 40% (afin d'anticiper les tests et la relecture) pour obtenir un chiffre unique.
L'échelle de notation  repose sur le principe du "planning poker" de la méthode Agile : 1, 3, 5, 8, 13, 21 (les plus matheux auront reconnu la suite de Fibonacci… au moins jusqu'ici) et 40 pour la plus complexe.

On estime ensuite au doigt mouillé pouvoir effectuer entre 5 et 8 points de complexité par semaine.
Ainsi une page de complexité 10 doit normalement être terminée en 2 semaines.
Disclaimer : reporter la complexité en temps n'est pas recommandé dans un projet Agile, mais nous l'avons fait afin d'estimer le coût de cette refonte et ainsi la financer.

Revenons maintenant à des aspects plus "techniques" de la création de page.
Afin d'optimiser l'intégration, une nouvelle page "composants" a été créée.
Celle-ci est destinée uniquement aux développeurs. Elle a pour vocation de répertorier tous les composants (comprendre : les fonctionnalités, les éléments) présents sur toutes les pages.
Toutes ces briques sont ajoutées au fur et à mesure da la création des pages par chaque développeur impliqué dans le projet de refonte.
La vitesse de développement des pages doit donc devenir de plus en plus rapide à mesure que chaque composant est ajouté à ce "catalogue".
L'autre intérêt de ces composants est également d'assurer une uniformité structurelle et stylistique entre toutes les pages.

En terme de style justement, le framework CSS Bulma a été retenu afin de donner un cadre à l'intégration.
Le nommage très sémantique de ses classes ("column", "is-three-quarters", …) rend sa compréhension intuitive et rapide. Justement, une des devises est "simple to learn, simple to use".
Grâce à sa structure minimaliste et modulaire en Sass, la solution s'intègre sans effort au projet et supporte la "customisation".
Cependant l'appel à des feuilles de style individuelles pour les pages reste rare, notamment grâce aux "helpers" de Bulma (des classes qui altèrent le style de chaque élément, par exemple : "is-danger", "has-text-centered"…).
Le framework est suffisament complet et efficace pour structurer et styliser les composants et les pages avec des techniques efficaces (flexbox en tête) en respectant la sémantique HTML.
Nous obtenons ainsi un code élégant, moderne et respectueux des normes d'accessibilité… Beau tout simple !

La suite au prochain épisode…