08 septembre 2006

Priorités techniques (versionnage des données)

On a eu un débat sur les priorités dans le développement :-P

Une question forte était notamment de savoir s'il n'aurait pas été plus judicieux de faire de suite un amorçage avec une petite IHM sexy, au lieu de régler la question du versionnage des données.

J'avoue que je n'ai pas de réponse à cette question, j'ai vraiment hésité à implémenter le versionnage des données dès la v0.2 (implémentation du forum).

Ce que je peux dire, c'est que pour le développement du forum, le versionnage des données offrait d'emblée les points suivants :
  • les contextes de navigation, notamment dans les résultats de recherche (les résultats d'une recherche lancée à un instant <t> restent inchangés même si de nouvelles données sont arrivées à <t+1>, <t+2>... <t+n> : le rafraîchissement de la recherche est à la discrétion de l'utilisateur, pas du système)
  • le suivi des commandes pour les traitements asynchrones (si une commande à <n+2> ne passe pas, on peut revenir à l'état <n> ou <n+1>, selon l'intégrité demandée : passage de commandes par lots, etc.).
    À vrai dire, dès qu'on fait du traitement asynchrone, je ne vois pas comment s'en sortir sans versionnage.
Et bien sûr, sur le long terme, le versionnage des données offrira :
  • des sauvegardes métier faciles et cohérentes
  • une possibilité de gérer la concurrence entre des modifications multi-sites
Bien sûr, les utilisateurs lambda n'ont que faire de ces subtilités. Le versionnage est surtout un confort pour les administrateurs fonctionnels, car pour chaque version étiquetée, le système leur garantit la cohérence des données.

Cependant ce versionnage est tellement galère à implémenter from scratch, que je n'arrive même pas à imaginer la somme monstrueuse d'efforts qu'il faut déployer pour garantir une migration souple des données d'un système sans versionnage, vers un système avec versionnage. À moins bien sûr d'arrêter les serveurs pour verrouiller les données, mais c'est pas du jeu ;-)

C'est une autre façon de voir les choses : y avait-il un moyen acceptable de faire autrement que d'implémenter ce merdier dès le début ?
La question ainsi posée, ma réponse serait proche du « non »...


Dans le même genre, il y a d'autres « priorités techniques discutables » :
  • Unicode
  • internationalisation (1)
  • gestion des timezones
  • gestion répartie des identités
  • centralisation de la publication des messages
  • sessions multi-sites (un peu de SSO)
  • ...?
Cela, alors que le Back&Reload n'est pas encore géré...

Le débat reste ouvert, ainsi que les commentaires :-)


(1) Pour mémoire, sur l'internationalisation, voir le post de Tristant Nitot :
Localization and Internationalization: what some of us have learnt

1 commentaire:

Christophe Brugne a dit…

Apport
L'apport du versionnage en terme de cohérence est indiscutable (il interdit des cas tordus du style "l'utilisateur recherche un mot sur tout le site, il visualise un des résultats de recherche, le texte ne contient pas le mot car il a été modifié entre temps et le mot supprimé").
Il est vrai que, comme toute fonctionnalité back-office, sans impact visualisable par l'utilisateur, le rapport satisfaction utilisateur/temps passé est peu favorable.
Cependant si le choix est fait d'implémenter le versionnage car l'équipe le juge nécessaire, alors c'est bien de l'avoir fait dès le début. C'est un élément structurant, une brique de base donc lourd à mettre en oeuvre sur un existant non pensé dans ce sens.

Potentiel
Un autre point positif c'est ce que le versionnage offre comme fonctionnalités utilisateur potentielles : restauration d'anciens messages ou données au sens large, historique, statistiques, anti-vandalisme pour ne citer qu'elles.

Priorité au fonctionnel ... mais technique d'abord
Ceci dit, la priorité reste de répondre aux besoins utilisateurs et de produire une première version du site répondant à leurs attentes. Le forum et blog sont en très bonne voie.

Les priorités devraient être orientées sur le fonctionnel : agenda et wiki par exemple. L'agenda car c'est très visuel (comprendre "fort impact utilisateur") et indispensable pour le besoin collaboratif des utilisateurs, le wiki car il permettra aux assoces de monter leur site web rapidement en toute liberté.

Reste que nous ne pouvons pas nous affranchir des briques de base indispensables. La gestion utilisateurs en est une.

En conclusion : versionnage et gestion des utilisateurs à boucler. Forum et blog à mettre en ligne dans la foulée après les tests et l'intégration. Réponse aux besoins fonctionnels en cible.