EasySave

Ce que fait le logiciel

EasySave sauvegarde des dossiers, sur demande ou avant une opération risquée. L'utilisateur déclare des travaux, les lance depuis un tableau de bord, et suit leur avancement fichier par fichier. Certaines extensions sont chiffrées au passage, tout est journalisé, et le logiciel s'interrompt de lui-même si l'application métier de l'entreprise démarre, parce qu'une sauvegarde n'a pas à ralentir le travail de quelqu'un.

La contrainte du module

Le sujet imposait une contrainte plus intéressante que le produit : livrer trois versions successives pour un éditeur fictif, ProSoft, en faisant évoluer l'architecture à chaque itération sans réécrire depuis zéro. Chaque version arrivait avec son propre cahier des charges, découvert seulement une fois la précédente livrée, donc impossible d'anticiper en concevant tout d'avance.

Les trois versions

Ce qui change d'une version à l'autre n'est pas la quantité de fonctionnalités mais l'endroit où vit le code.

• v1, console, le moteur : parcours des dossiers, sauvegarde complète ou différentielle, chiffrement par extension, journal quotidien, fichier d'état, interface en français et en anglais. Cinq travaux maximum, exécutés à la suite.
• v2, interface graphique, le moteur est extrait dans une bibliothèque partagée par la console et la nouvelle fenêtre WPF, construite en MVVM. La vue ne connaît plus la logique, la journalisation devient un composant à part avec JSON et XML au choix, et le nombre de travaux n'est plus limité.
• v3, tableau de bord, tous les travaux s'exécutent en même temps, chacun pilotable individuellement ou tous ensemble, avec les règles qui deviennent nécessaires dès qu'on ne s'exécute plus à la file. Les journaux peuvent partir vers un service conteneurisé.

Comment c'est découpé

La solution compte sept projets, et ce découpage est le vrai livrable du module : c'est lui qui a permis d'absorber trois cahiers des charges successifs.

• Core, modèles, services, stratégies de sauvegarde et ViewModels : tout ce qui ne dépend d'aucune interface
• Console et WPF, deux interfaces sur le même moteur, la seconde ajoutée sans modifier la première
• EasyLog, journalisation isolée, avec une stratégie par format d'écriture
• CryptoSoft, exécutable de chiffrement séparé, appelé comme un outil externe
• LogServer, petite API conteneurisée qui reçoit les journaux de plusieurs postes
• Tests, unitaires et d'intégration sur le moteur

Ce que le parallélisme a vraiment coûté

Passer du séquentiel au parallèle ne consiste pas à lancer les travaux en même temps : c'est le moment où des règles qui allaient de soi doivent être écrites explicitement, parce que plus personne n'attend son tour.

• Chaque travail tourne dans sa propre tâche, avec son jeton d'annulation pour l'arrêt et son signal d'attente pour la pause, qui ne prend effet qu'à la fin du fichier en cours, sinon on laisse une copie à moitié écrite
• Les fichiers prioritaires sont arbitrés par un coordinateur partagé entre tous les travaux : aucun fichier ordinaire ne démarre tant qu'une extension prioritaire reste en attente, quel que soit le travail qui la détient
• La bande passante est protégée par un sémaphore global : au-delà d'un seuil paramétrable, un seul fichier volumineux circule à la fois
• L'outil de chiffrement est verrouillé par un mutex système nommé, donc unique à l'échelle de la machine et pas seulement du processus
• Une pause automatique se déclenche si le logiciel métier du client est détecté, avec reprise à sa fermeture

Ce que j'en retire

• MVVM : pourquoi séparer la vue de la logique change tout au moment de la v2
• La concurrence se conçoit, elle ne se rajoute pas : les règles inter-travaux de la v3 n'existaient pas tant que tout s'exécutait à la suite
• Une architecture se juge à sa deuxième version, pas à la première
• Documentation technique et livraison en équipe sur un rythme imposé