Ou l’art de documenter facilement une base de données

#mylife je viens de commencer un nouveau boulot chez La Roue Verte, une entreprise de covoiturage sur Grenoble, qui met à disposition son outil gratuitement pour les particuliers et base son business model sur du SASS avec les entreprises.

Pourquoi je vous raconte ça ? Parce que lorsque l’on commence un nouveau travail, il faut  « rentrer dans la base de code », autrement dit, se familiariser avec le produit. J’ai donc eu la proposition suivante : « On a pas de doc, et ça nous embête, or, quel meilleur moyen de rentrer dans le code que de la rédiger ? Si tu es capable de faire la doc sans faute, c’est que tu as compris comment ça marchait ! ».

Un traitement de texte ? C’est quoi ?

Aussitôt dit, aussitôt fait, me voici à devoir documenter une base de données PostgreSQL, le modèle de notre application. Aucune contrainte sur les outils à utiliser, il faut juste que le rendu final soit un PDF. La solution de facilitée aurait été d’ouvrir LibreOffice Writer et de prendre une à une chaque colonnes de chaque tables en la décrivant. Cela peut sembler fastidieux, mais de toute manière, je n’y échapperai pas. Non, ce qui m’ennuyait dans cette solution, c’était le maintien à jour des données. Si la doc aurait été à jour au moment de sa création, il y avait fort à parier que le fichier texte n’allait pas être modifié par les développeurs lorsqu’ils modifieraient le schéma de la base, que ce soit par oubli, par flemme ou par manque de temps. Or, dès que le document n’est potentiellement plus le reflet exact de la base, même si la différence entre les deux est mineure, il ne devient plus possible de s’y référer, on ne peut pas savoir ce qui est correct de ce qui n’est plus à jour. L’intégralité du document (et ma vingtaine d’heures passées à le rédiger) devient inutile. Une doc pas à jour équivaut à « pas de doc ».

La génération automatique à la rescousse

La solution pour avoir une documentation toujours à jour ? La générer directement depuis le schéma de la base de données. Un coup de DuckDuckGo, et je découvre Autodoc, un outil en ligne de commande à qui on donne simplement l’accès à la base de données, et qui nous extrait des fichiers au format HTML, Dot, Dia et DocBook XML. HTML ? Parfait pour moi ça. Facile à mettre en forme en deux coups de CSS, qui se transformera en une seconde en un PDF grâce au « Imprimer dans un fichier » de Firefox… Je lance la génération.

Toutes les tables sont là, les colonnes aussi, mais aussi les contraintes (clef primaire, clef étrangère, not null, valeur par défaut…) ou encore les fonctions triggers, des statistiques, bref, beaucoup de choses. Les graphiques .dot ne sont pas vraiment exploitables, mais pas grave, ce n’est pas ça qui m’intéresse. Après un coup de CSS pour rendre le résultat moins moche, j’ai maintenant une documentation qui se génère en une commande, et qui est donc toujours à jour par rapport au schéma de la base de données.

C’est une bonne nouvelle, mais les informations contenues dans ce HTML sont finalement assez faibles. Il n’y a rien de plus que ce que je pourrais lire dans le create.sql, certes, sous une forme un peu plus lisible, mais tout de même, ce qui est intéressant, c’est de dire à quoi correspondent chaque table et chaque colonne. Ici, je connais leur type et leurs contraintes, et je peux imaginer ce qu’elles font grâce à leur nom, mais tout de même, ce n’est pas cela que l’on appelle une documentation.

COMMENT ON, THE solution

Après quelques recherches supplémentaires, j’ai donc trouvé la solution idéale pour le moment : COMMENT, qui permet d’ajouter très facilement un commentaire à à peu près tout et n’importe quoi (table, column, constraint, index, database… la liste est longue, vous pouvez la consulter dans la doc). La syntaxe est ultra simple :

COMMENT ON TABLE user IS 'Contient les utilisateurs inscrits dans l''application.'; -- Ajoute un commentaire sur la table "user"
COMMENT ON TABLE user.name IS 'Le nom de l''utilisateur'; -- Ajoute un commentaire sur la colonne name de la table "user"

Un coup de génération, et les commentaires s’affichent dans le .html 🙂

Cerise sur le gâteau, postgresql_autodoc nous permet de choisir le template sur lequel il doit se baser pour génerer la doc. J’ai donc modifié ce fichier pour retirer tout ce qui était inutile, améliorer le design et lui demander d’interpreter le HTML dans les commentaires. Magnifique ! Grâce à des <span class="technique"> et un bout de JavaScript, nous voici maintenant capable de masquer ou afficher en un clic les parties techniques de la documentation, celles qu’on a pas besoin de montrer quand on présente la partie métier de l’application.

Bien sûr, cette solution n’évite pas le fait que si un commentaire n’est pas ajouté ou pas mis à jour lors de la modification du schéma, la doc ne sera pas exactement à jour. Mais comme elle se base sur le schéma pour être généré, on est absolument sûr que toutes les tables et colonnes sont là et avec le bon nom, ce qui est déjà nettement mieux qu’une doc non reliée à la base de données.

Voilà, la mauvaise nouvelle, c’est que la commande COMMENT est spécifique à PostgreSQL et n’est pas dans le standard SQL, mais de toute manière, Postgres est la meilleure DB non ?