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