Mon p'tit coin du web

Pourquoi utiliser un logiciel de gestion de version

Nicolas — 2007-05-14T20:23:36Z

Un développeur est souvent amené à utiliser un logiciel de gestion de version pour ses projets. Pourtant c'est un outil très puissant qui peut servir à bien d'autres choses.

Qu'est-ce qu'un logiciel de gestion de version ?

Il s'agit d'un logiciel qui permet de suivre les différentes versions d'un ensemble de fichiers. Il permet de retrouver un ou des fichiers tels qu'ils étaient à une date donnée. C'est, en résumé, un logiciel qui garde un historique de l'évolution du fichier.

Ces logiciels permettent, quand il s'agit de fichiers texte [1], de voir les modifications (ajout, suppression, changement) entre différentes versions des fichiers, de savoir qui a modifié, etc. Pour un fichier binaire, le logiciel se contente de garder les différentes versions, sans être capable de dire les modifications [2].

Plus précisément, le développeur demande manuellement, et aussi souvent qu'il le désire, au logiciel de gestion de version de stocker l'état de ses fichiers à un instant donné, lui permettant de revenir à cette version à tout moment.

Pour les utilisateurs connaissant un logiciel tel que Microsoft Word (c), un logiciel de gestion de version est similaire au contrôle de révisions que le traitement de texte offre [3].

Pourquoi utiliser un tel logiciel, et quelles sont ses fonctionnalités majeures ?

La première utilisation est bien sûr de garder une trace des modifications. C'est un point très important :
il est possible de faire de nombreuses modifications sur les fichiers, puis de tout annuler pour revenir à une version précédente sans avoir besoin de tout annuler manuellement, ou de garder une copie des fichiers originaux, ...
le logiciel de gestion de version permet de suivre l'historique, qui a modifié quoi, quand. La plupart de ces logiciels permettent d'entrer un commentaire au moment de sauver l'état des fichiers. Associé à la liste, générée automatiquement, des fichiers modifiés, ceci permet de suivre la vie d'un logiciel.

Le logiciel de gestion de version permet également de faciliter le travail entre plusieurs personnes. Chaque développeur travaille sur une copie des sources sur son propre ordinateur, puis quand il juge que sa version est correcte, il la transmet au logiciel de gestion de version, qui centralise les modifications. Les autres développeurs peuvent alors récupérer depuis cette base centrale la dernière version des fichiers.

Il existe deux philosophies par rapport au travail collaboratif :
soit les développeurs travaillent en mode « exclusif », c'est-à-dire qu'une seule personne à la fois peut modifier un fichier donné
soit les développeurs modifient arbitrairement n'importe quel fichier, et le logiciel de gestion de version s'occupe de fusionner automatiquement les différentes modifications. Si la fusion automatique n'est pas possible (deux personnes ont modifié une même zone d'un fichier de façon différente et non compatible), il est nécessaire qu'un développeur résolve à la main les conflits de modification [4].

Les deux philosophies ont des points positifs et négatifs. La première évite les conflits de modification puisqu'une seule personne peut modifier un fichier ; en revanche elle peut parfois forcer un développeur à attendre qu'un autre ait fini de travailler sur un fichier pour pouvoir continuer. La deuxième approche est plus souple car elle permet de modifier sans restriction ni délai ; par contre elle demande une coordination entre les développeurs pour qu'ils ne modifient pas le même endroit en même temps [5].

Une fonctionnalité importante d'un logiciel de gestion de version est la possibilité de créer des « branches ». Cette fonctionnalité permet d'avoir plusieurs versions en parallèle des fichiers.

Ainsi, le projet Crossfire, auquel je participe, a deux branches :
la branche « 1.x » correspond à la version 1.10 du logiciel distribuée publiquement
la branche « trunk » comprend la version en cours de développement qui sera la future version 2.

Après la distribution de la version 1.10, plusieurs bugs ont été signalés, et corrigés. Les corrections ont eu lieu sur la branche « 1.x », qui donnera lieu, lorsque suffisamment de bugs auront été corrigés, à la version 1.11.

Simultanément, un travail de fond de modification a eu lieu sur la branche « trunk ». Cette branche est considérée expérimentale, et c'est sur elle que les efforts majeurs de développement ont lieu, que la plupart des nouvelles fonctionnalités sont rajoutées. Les corrections apportées sur la branche « 1.x » sont, si applicables, dupliquées sur cette branche.

Lorsque la branche « trunk » sera considérée stable, la branche « 1.x » sera abandonnée sauf pour corrections de bugs majeurs.

Deux versions des fichiers cohabitent donc, chacune ayant son utilité, l'une pour avoir une version distribuable à tout instant et l'autre pour expérimenter.

À quoi peut servir un tel logiciel pour un non développeur ?

Même si c'est à l'origine un outil destiné aux développeurs, un logiciel de gestion de version peut parfaitement être utilisé par un non développeur.

Le premier avantage est qu'une copie des fichiers gérés par le logiciel est disponible dans un emplacement centralisé. Ceci permet de facilement faire une sauvegarde des données — il suffit de copier le répertoire central. De plus même si un fichier est effacé par erreur il est possible d'en récupérer une version depuis le logiciel de gestion de version.

Le deuxième avantage est l'historique offert. Pour des documents souvent modifiés, pouvoir revenir à un point arbitraire dans le passé est un énorme avantage.

Bien sûr, utiliser un tel logiciel impose une certaine discipline, à savoir transmettre régulièrement au logiciel de gestion de versions les modifications effectuées sur les documents. Cependant les gains sont probablement suffisants pour s'imposer cette contrainte sans trop de difficultés.

Utiliser un logiciel de version nécessite également d'avoir un peu plus d'espace disque disponible, puisqu'un fichier existe en différentes versions, occupant de la place sur le disque. Mais avec les capacités actuelles de stockage, ce n'est pas vraiment une difficulté — enfin, vouloir gérer des versions de films en haute définition poserait certainement des soucis !

Exemple d'application de la gestion de versions

Un exemple d'application de gestion de versions est disponible l'encyclopédie Wikipédia. En effet, chaque article a un historique intégral depuis sa création, comprenant toutes les modifications jamais effectuées [6]. Il est possible de visualiser les changements apportés entre deux versions arbitraires, de revenir à des versions antérieures, ...

De plus plusieurs personnes peuvent modifier le même article simultanément, avec un conflit uniquement si la même zone a été modifiée de façon incompatible.

Même si le mécanisme est peu visible pour le contributeur, il s'agit bel et bien d'un système de gestion de version.

[1] Il est coutume de distinguer les fichiers ou formats dits texte — qui ne contiennent que des caractères alphanumériques ou symboles — qui peuvent être simplement affichés, et les fichiers dits binaires qui nécessitent un programme pour être visualisés. Ainsi une image est un fichier binaire, alors que par exemple un mail est en format texte — il contient parfois des « tags » qui permettent d'indiquer l'italique, le gras, ..., mais ces tags eux-mêmes sont en format texte, et peuvent être lus sans logiciel spécial si besoin.

[2] Se contenter de repérer les modifications d'une image entre deux versions ne serait pas forcément une tâche insurmontable, mais pour par exemple un film cela n'aurait pas beaucoup de sens.

[3] À noter qu'un document Word n'est pas un document texte, mais bien un fichier binaire. Les données de mise en forme (gras, italique, tableaux, ...) sont stockées sous format complexe illisible sans logiciel spécialisé. Cependant les dernières versions peuvent aussi utiliser un format dit XML, qui lui devrait être, si j'ai bien compris, en format texte un peu plus simple à interpréter sans logiciel spécial.

[4] La plupart des logiciels travaillent sur un mode de modification ligne à ligne, avec une certaine zone autour. En général, les conflits ont lieu uniquement si la même ligne est modifiée par deux développeurs simultanément, les algorithmes des logiciels étant assez puissant pour fusionner les modifications.

[5] Un argument en faveur de cette méthode est que « si deux développeurs modifient en même temps la même zone d'un fichier, ils ont un problème de communication, ce qu'aucun logiciel de gestion de version ne peut résoudre. »

[6] Il est possible de totalement supprimer des versions, cependant c'est une fonctionnalité uniquement utilisée pour purger les modifications de type spam, ou requises pour raisons légales.

L'art de documenter

Nicolas — 2007-04-21T09:20:23Z

J'ai eu plusieurs discussions avec des collègues sur comment, pourquoi, à quelle fréquence commenter ou documenter du code. Et ceci fait l'objet de nombreux débats sur Internet.

Pourquoi commenter [1] ? Simplement pour pouvoir, dans le futur, savoir ce que fait du code, et pourquoi et/ou comment il le fait. Ce besoin de savoir peut être lié à une recherche de bug, ou simplement de curiosité. De plus, le développeur ayant besoin de savoir n'est pas forcément l'auteur du code en question — mais même ce dernier bénéficie du commentaire quand il relit du code plusieurs mois après son écriture en ayant codé sur d'autres projets entre-temps.

Cependant savoir où, quand et comment commenter est très difficile [2].

La première règle est de donner des noms significatifs aux fonctions et variables, afin d'identifier leur signification. Ainsi void ResetMap(mapstruct* map) est plus parlant que void Reset(mapstruct* var) s'il s'agit d'une carte.

Un exemple de mauvais commentaire est du style :

x = 0; /* initialisation */

 /* Retourne le solde /*
 int GetSolde()
 {
 return solde;
 }

qui n'apporte strictement rien. Il arrive aussi que les commentaires soient totalement faux par rapport au code, donc leur signification devient nulle.

Il m'est arrivé de travailler dans des groupes où il fallait impérativement commenter toutes les méthodes, fonctions, classes publiques pour pouvoir archiver des modifications dans le contrôle de sources. Le problème est que de nombreuses propriétés ou fonctions n'ont tout simplement pas matière à commentaire — leur nom étant descriptif, bien entendu. Bilan, nous avons utilisé un programme pour extraire automatiquement les signatures (entrées, sorties) de ces éléments, et répondre à l'impératif de commentaires. À mon sens c'est une valeur ajoutée nulle, voire négative, car plusieurs fois je perdais du temps à rajouter les commentaires qui n'apportaient rien. Il aurait fallu faire en sorte qu'un archivage commente automatiquement en extrayant les informations, et laisser au développeur la responsabilité de savoir où le commentaire était nécessaire.

Pour moi, un commentaire doit répondre à différents critères pour être utile :
ne pas paraphraser le code, ne pas dire comment on fait quelque chose, sauf si c'est vraiment très complexe — auquel cas il faut aussi se poser la question de simplifier ça. Lire le code répond en effet à la question du « comment », mais pas du « pourquoi ».
dire pourquoi on fait quelque chose — « le chemin peut comporter des /, qui sont invalides dans un nom de fichier et doivent donc être transformés en _ »
préciser quelle partie des spécifications fonctionnelles la fonction implémente — « cette fonction traite le cas spécifique de la réduction d'impôt de la loi xxx dans le cadre yyy », si le nom de la fonction ne suffit pas à indiquer cela
indiquer les cas d'erreur de la fonction, ou ses présuppositions — « la carte peut être nulle, auquel cas la fonction ne fait rien », ou « l'objet doit être correctement initialisé par un appel à InitObject() avant d'utiliser cette fonction »
éventuellement dire pourquoi une méthode a été choisie plutôt qu'une autre — « il est également possible d'utiliser tel algorithme, cependant il est plus compliqué à mettre en œuvre et n'apporterait aucun gain de performance sur de si petits ensembles de données »
en règle générale, ne rien dire qu'un outil automatisé, comme Doxygen, ne puisse extraire

[1] je vais utiliser ce verbe pour désigner le fait de commenter ou documenter, pour simplifier l'écriture.

[2] je ne prétends aucunement être expert en ce domaine, d'ailleurs.

L'art de débugger

Nicolas — 2007-02-23T19:11:02Z

Tout développeur est confronté au problème de la correction de bogues ou de comportements aberrants, que ce soit dans du code qu'il a écrit ou non.

Une telle correction peut en général se découper en plusieurs phases, parfois mêlées ou confondues.

La première phase est de comprendre le comportement anormal. Cela peut parfois être très simple (« l'application plante »), parfois un rapport de bogue écrit par un utilisateur n'a pas assez de détails (« le troisième alinea a une mauvaise forme »). Développeur et utilisateur ne parlent pas toujours le même langage, donc la communication est parfois difficile.

La deuxième phase est de savoir reproduire le bogue. Très souvent, elle va avec la première, car pour comprendre le comportement anormal le plus simple est de le reproduire et de constater de visu ce qui ne va pas.

La troisième phase est de savoir quel est le comportement attendu. Là, ça peut être plus compliqué à savoir. Si l'application a un cahier des charges, ce n'est pas forcément difficile, mais il existe parfois des mésententes entre la demande que le rédacteur voulait exprimer et celle que le développeur lit, sans même qu'il y ait de mauvaise foi de part et d'autre. Encore une fois, rédacteur et développeur ne parlent pas forcément le même langage, donc il faut clarifier au maximum.

Parfois, l'application n'a pas spécifiquement de cahier des charges. C'est un problème récurrent par exemple dans les projets Open Source, où des fonctionnalités sont développées puis le codeur s'éloigne du projet, sans avoir forcément tout documenté. Je développe pour un jeu nommé Crossfire, jeu de rôle assez standard. Parfois, un comportement est anormal (un objet ne se comporte pas comme il le faut), la cause en est connue (il manque un paramétrage pour l'objet), mais personne ne sait quelle est la correction adéquate, le paramétrage que le créateur de l'objet voulait donner. D'où discussion éventuelle entre les développeurs et les joueurs pour décider ce qu'il faut faire. Sachant que parfois la discussion n'est pas très active, et le premier à corriger décide de facto de la façon de corriger.

La quatrième phase est de comprendre ce qui cause le problème. Et là, il y a des fois des surprises. Sur Crossfire, il existe depuis plusieurs années un code de climat permettant de rendre les cartes un peu plus dynamiques et variables selon la saison dans le jeu. Ce code était anormal depuis plusieurs mois voire années, des arbres apparaissaient sur l'eau, du sol disparaissait, bref plein d'anomalies. Son code a été tracé, examiné, en vain. Les erreurs étaient en fait dans d'autres parties du code, sans aucun rapport. La première coupable était une fonction insérant des objets à un endroit de la carte, qui ne se comportait pas comme elle le devait. Comme seul le climat utilisait certains paramètres, l'anomalie n'avait pas été remarquée. Le second coupable était une fonction de concaténation de noms de chemins. Elle utilisait un buffer statique qu'elle retournait à son appelant avec un chemin [1]. Or le climat appelait plusieurs fonctions différentes, dont certaines appelant cette fonction de concaténation et changeant sa valeur. Au final, le climat travaillait à un moment sur une carte et à un moment sur une autre en pensant être sur la première. Bilan, des éléments supprimés ou insérés à des endroits incohérents car tests et insertion étaient sur deux cartes différentes.

La cinquième phase est la correction du bogue. Dans le cas cité auparavant, le buffer statique a été remplacé par un paramètre buffer que la fonction remplit, éliminant le cas d'écriture parasite [2]. Bien évidemment, il faut vérifier que la correction n'introduit pas de nouveaux bogues...

La sixième phase, enfin, est la validation par l'utilisateur de la validité de la correction. À ce niveau, il est parfois nécessaire de recommencer à la première phase, si la modification n'est pas satisfaisante.

Une septième phase, en général oubliée, est de documenter les modifications, tout au moins le comportement voulu par l'utilisateur ou décidé. Ceci permet de s'assurer que des développeurs futurs auront les informations nécessaires à la compréhension du code.

Un élément amusant est la répartition temporelle entre ces différentes phases. Le développeur, bien naturellemment, préfère souvent développer plutôt que discuter pour savoir le comportement attendu, surtout quand celui-ci prête à discussion. Les quatrième et cinquième phases sont donc souvent ses favorites. Mais, souvent, ce sont les autres phases qui demandent le plus de temps. Le pire des cas est celui où la cause du problème est comprise, la façon de corriger aussi (et en plus la correction est simple et sans effet de bord), mais il faut attendre de savoir comment corriger.

[1] autrement dit, si l'appelant garde une référence vers le résultat retourné, le contenu ainsi référencé peut changer sans préavis. Ce qui bien sûr pose un souci.

[2] chaque appelant fournit son emplacement privé où la fonction écrit le résultat, donc plus d'interférence.