Il serait complexe et inapproprié de discuter ici des spécificités techniques affiliées à ce qu’on appelle dans le jargon informatique le “développement orienté objet”43. En bref, ce concept permet de développer une application via des objets indépendants (du code source fonctionnel) capable de communiquer avec d’autres objets et donc de s’adapter au mieux aux différentes variations pouvant survenir durant la phase de production d’un logiciel. Chaque utilisateur apporte ainsi sa pierre à l’édifice, le
maintener décidant ainsi de consolider celle-ci avec la proposition de l’utilisateur.
Cependant, cette méthode ne résout pas entièrement les actions effectuées en parallèle sur un fichier, et ne permet pas de rendre plus compréhensible la modification apportée par un utilisateur, même si ce dernier a reçu l’approbation du maintener.
1.3.4 Le commit
Parmi les outils méthodiques, il y a ce que les développeurs appellent le commit. Le commit est un acte informatique qui consiste à valider formellement une modification du code source d’un logiciel44. Il permet en quelque sorte d’effectuer un “étiquetage” du
code qui a été ajouté à la structure. Cette action est par ailleurs bien documentée : le
commit s’accompagne ainsi d’un numéro de révision, du nom de l’utilisateur qui a
effectué la modification et permet aussi d’ajouter un message optionnel (plus connu sous le terme de “log” chez les développeurs). Le commit indique également l’heure (« timestamp ») à laquelle a été réalisé la modification. Chacun des fichiers modifiés est ainsi décrit et documenté.
D’une certaine manière, les informations relatives au code source sont tracées, permettant alors de constituer une sorte d’historique de conception et d’évolution du logiciel. Bien entendu, pour effectuer une telle modification, il faut avoir eu les droits d’écriture par le maintener, qui aura préalablement identifié le collaborateur. Cette pratique s’associe ainsi très bien avec la suivante et dernière fonctionnalité que nous allons voir, et qui constitue non seulement une fonctionnalité fondamentale de travail pour les développeurs, mais aussi l’axe principal structurant les plateformes de développement: le versionning.
43 Voir glossaire 44 Voir glossaire
1.4 L
EVERSIONNINGLe versionning consiste à sauvegarder chacune des versions d’un fichier45. Il consiste à sauvegarder plusieurs versions d’un même fichier sans pour autant écraser les versions antérieures. Il est indispensable pour la production de fichiers à moyen et long terme. La méthode du versionning n’est d’ailleurs pas utilisée qu’en programmation, elle est également employée dans la production documentaire. A titre d’exemple, prenons la rédaction de ce mémoire : j’ai été amené à produire plusieurs versions écrites de mon document de travail. Étant donné que durant toute la phase d’élaboration du mémoire le plan de celui-ci est amené à changer régulièrement, du fait des réflexions effectuées sur le sujet mais aussi parce que la rédaction impose souvent une réorganisation des idées, j’ai été ainsi amené à revenir à des versions précédentes pour repartir d’une structure que j’ai faite évoluer dans une version plus récente, et dont je n’étais finalement pas satisfait. J’ai pu ainsi expérimenter plusieurs types de plans pour chacune des trois parties de ma réflexion.
Ce processus peut très bien s’appliquer à la production musicale, au montage vidéo et bien sûr à la rédaction du code source d’un logiciel, ainsi qu’à la production de sa documentation. En effet, celle-ci nécessite d’être corrigée et relue par différents individus, pouvant apporter chacun leurs critiques sur les diverses informations contenues dans le fichier. Par ailleurs, étant donné que les propositions sont faites sous forme de “blocs”de données, il est préférable d’employer un format d’édition simple pour pouvoir prendre en compte les éventuelles recommandations du maintener, mais aussi pour tester individuellement les blocs de données avant de les intégrer au code source principal. Le versionning peut alors s’avérer d’autant plus utile dans ces cas là.
Grâce au versionning, il est également possible de comparer des changements apportés au code source principal du logiciel, et dans le cas d’une défaillance, d’avoir la possibilité de revenir en arrière, à un état fonctionnel et stable du code source. Il peut ainsi s’effectuer manuellement ou alors être totalement automatisé, grâce à un système de gestion de version. Ce système contrôlera et générera chacune des versions d’un fichier46, il sera ainsi possible de revenir à une version
antérieure spécifique. Les systèmes de gestion de versionning se déclinent ainsi
45 CHACON Scott, STRAUB Ben, Pro Git : Everything you need to know about Git, Apress, 2018, 517 p. 46 CHACON Scott, STRAUB Ben, Pro Git : Everything you need to know about Git, Apress, 2018, 517 p.
sous trois formes: gestion de version en local, gestion de version centralisée, et gestion de version distribuée, qui correspondent plus au moins à une évolution chronologique, en fonction des besoins mais aussi des spécificités techniques des infrastructures des utilisateurs à un moment donné.
Les logiciels de gestion de versionning ont dû évoluer progressivement au cours des utilisations et des pratiques afin de palier à une multitude de problèmes que rencontraient couramment les développeurs. Identifier ces problèmes et les solutions qui sont apportées nous permettront d’avoir une première visualisation sur la conservation du code source.