22 mois de Vitam

Quelques mots jetés sur un blog afin de me rappeler (comme un journal de bord) ce sur quoi j’ai travaillé. Ma mission Vitam s’est terminé il y a 6 mois et je pense que je peux le publier sans trop me faire remarquer et sans me faire trop d’ennemies.

Ce sur quoi j’ai travaillé plus précisément:

  • Réparer des bugs métiers: par exemple sur le DSL, les règle de gestion ou encore sur les headers.
  • Correction d’un bug sur la date en XML.
  • Implémentation des registres de fond symbolique.
  • Travail sur le workflow de préservation (génération, extraction AU | GOT, identification, validation).
  • Travail sur un système de plugin externe: les Griffin (imagemagick, siegfried, libreoffice).
  • La valeur probante.
  • Le “mass” update.
  • Travail sur un méchanisme de retry.
  • Travail sur les cardinalitée Vitam.
  • Correction de multiples bugs sur les clients HTTP.

Les sujets qu’il fallait avoir en tache de fond, garder à l’esprit:

  • Idempotence (deux actions identiques ont le même effet unique)
  • Distribution (distribuer les taches)
  • Sécurité (une donnée qui est rentrée dans le système ne doit pas pouvoir être modifié par l’extérieur ou bien il faut s’en rendre compte)
  • Cohérence (comment faire qu’une donnée arrivée ne soit pas perdu)
  • Vérification/Audits (comment faire pour qu’on puisse vérifier ce qui a été fait)
  • Compatibilité (comment faire pour que ce qui a été fait avant soit compatible avec ce qui est fait aujourd’hui)

Les choses qui n’ont pas marché:

  • La personne du métier != Product Owner.
  • Mauvaise utilisation généralisée de git / release / release note / reviews / build.
  • Mauvaise organisation des temps communs (une réunion c’est un sujet, un temps borné, un scrib qui écrit tout, un compte rendu, une fin, une décision).
  • Multiplication des outils qui font la même chose (tuleap + gitlab + board physique).
  • Les coachs agiles / scrum masters full time.
  • Il y a eu un temps avec:
    • 3 “preneurs de décision” => perte de temps car il fallait un consensus,
    • un seul “preneur de décision” => perte de temps car trop demandé et donc ne peut pas prendre toutes les décisions.
  • La ségrégation architecte/développeur.
  • Faire des tests E2E la référence de test de code + que les tests E2E soient écrits par les développeurs.
  • Celui qui écrit != celui qui maintient
  • Pas de framework dans une grosse équipes de dev qui ont des niveaux de compétences très différents.
  • Peu de temps de maturation des features
  • Pas de feature switch
  • Pas de rollback après upgrade

Les choses que j’ai apprises sur mon métier :

  • Archéologie, aimer le code existant, ne pas le rejeter, vouloir le comprendre et l’améliorer plutôt que le ré-écrire.
  • Les méthodes de travail sont plus importantes que les compétences brutes.
  • Le but du jeu est d’avoir un outil simple qui s’efface, qui se retire, qui marche, que l’on voit moins (cf. Terre des Hommes, Antoine de Saint-Exupéry).
  • Il faut rapidement mettre en place un système de logging qui vas être normalisé (jsonL par exemple) et pouvoir être réutilisé.

Les technologies que j’ai pu découvrir vraiment :

  • mongodb
  • picocli
  • imagemagick
  • libreoffice (as a server)
  • java 11
  • arbre de merklee / digest / hash function / timestamp / chain
  • vscode + plugin http
  • angular (beurk)

Les sujets que ça pousse à découvrir chez moi :

  • Error handling => comment faire pour avoir une bonne gestion / couverture des erreurs
  • Test fuzzing => comment mieux tester son application pour la rendre robuste aux pannes “random”
  • Log reporting => comment faire pour bien recycler / réutiliser ce qui sort de l’application (log, stack, code d’erreur)
  • Distributed actors => est ce que ça serait pas l’avenir des micro-services ?