« De toute façon, je suis le seul qui touchera au code ». J'ai déjà vu ou entendu cette remarque de nombreuses fois. Sous prétexte d'un développement en solo, un programmeur ne commente pas ce qu'il fait ou encore n'archive rien.

Ce que je voudrais commencer par faire, c'est montrer que « programmer seul, c'est déjà programmer en équipe ». Par seul, j'entends projet personnel, dans son coin, même amateur. Puis nous regarderons ce que la programmation en équipe peut apporter à un projet personnel.

Une équipe tout seul

L'idée de la démonstration est simple : une personne change. Le programmeur qu'est la personne aujourd'hui n'est pas la même que six mois plus tard. Entre temps, des lectures de livres, documentations ou codes tiers, des discussions ou des réflexions ont certainement changé les manières de faire et de voir.

De plus, il n'est pas rare pour un projet personnel que des impératifs ou tout simplement des changements de priorités interviennent (famille, boulot), forçant le projet en pause pendant quelques temps. Comment faire pour repartir sur le projet après une pause ? Cela fait partie des causes classiques d'abandon de projet : on ne comprend plus ce qui avait été fait, le code nous est devenu étranger.

Documenter

Le vaccin classiquement préconisé est de commenter son programme. C'est un minimum en effet. L'expérience montre que, souvent, ce qui semblait évident sur le moment et n'a pas été commenté est justement ce qui devient incompréhensible plus tard.

Commenter des parties de code est une nécessité, mais commenter le design général est tout aussi important. En effet, lors de la mise en place du programme, il y a eu des réflexions, des idées notées. Ces réflexions ont amené à faire les choses d'une manière plutôt que d'une autre. Mais pourquoi ? Le danger, en revenant sur cette partie plus tard, est de ne plus la comprendre, de retravailler sur cette partie inutilement¹. Le choix d'un design avait peut-être été dicté par une contrainte qui a été changée. Il faut donc aussi noter les contraintes.

Le bon dosage de cette documentation n'est pas évident à trouver ; il vient avec l'expérience. Certains pêcheront par défaut, d'autres par excès. Ne pas en faire assez sera une perte de temps lorsque le besoin de documentation se fera sentir ; en faire trop est un perte de temps pendant l'écriture.

Un point souvent oublié de la documentation est l'usage de ce qui a été programmé. Comment utilise-t-on cette classe ? Comment a-t-on prévu que le système fonctionnait ? Pour éviter de trop en faire, une bonne méthode à mon sens est d'écrire des programmes de tests. Ces programmes ont un avantage double : ce sont des tests, si possible des tests unitaires² et ils documentent en pratique la manière d'utiliser le programme.

Tester

Et puisqu'on en est aux tests : voici une autre pratique de projet d'équipe qui mérite d'être utilisé lorsque l'on programme seul. Là encore, vous êtes multiple. Vous avez travaillé sur une partie, par exemple la gestion des entités d'un jeu vidéo. Plus tard, vous travaillez sur la gestion 3d du son, ce qui vous amène à retoucher à la gestion des entités car vous aviez oublié de lui faire publier une information sur les sons qu'elles produisent. Il n'est pas absolument certain qu'en retouchant votre code fait quelques temps auparavant, vous cassiez par mégarde quelque chose, mais ce n'est pas exclu. Avoir des tests unitaires est un moyen de minimiser le risque.

Être cohérent

Une façon de faciliter la lecture utilisée par les équipes est la standardisation de l'écriture. Donnez-vous quelques règles et respectez-les. Cela peut-être la manière dont vous écrivez vos variables (MaVariable ? maVariable ? ma_variable ?), la façon de faire vos indentations, la forme des commentaires,... Si tout est cohérent, alors vous repérerez beaucoup plus facilement les éléments constitutifs du code source.

Notez bien entendu vos règles dans un document avec le projet car, encore une fois, après une interruption, vous aurez peut-être pris d'autres habitudes (travail dans une équipe avec d'autres règles, lecture d'un livre avec d'autres règles,...)

Archiver

« J'ai décidé d'arrêter ce projet car mon disque a crashé et j'ai tout perdu ». Phrase trop souvent vue³. Votre travail est important ! Même si c'est un jeu de morpion, vous y avez passé des heures dessus, vous y avez réfléchi, vous vous êtes battu avec votre compilateur. Tout cela ne mérite pas de disparaître à cause d'une fausse manipulation ou d'une panne matériel.

Archivez régulièrement. Vous avez deux disques ? Copiez de temps en temps votre projet sur le second disque. Vous avez un disque externe ou une clé USB ? Pareil. Dupliquez au moins une fois votre travail. Si votre projet est un projet online, ayez une copie local du site. Non seulement si le serveur crash, vous n'aurez pas tout perdu, mais en cas de perte de connexion, vous pouvez continuer en local. Pensez aussi à sauver vos bases de données.

Utilisez un gestionnaire de version (CVS ou Subversion pour les plus connus en utilisation libre). Cet outil est indispensable en équipe. Et comme le sujet de cet article est qu'une équipe commence avec une personne, le gestionnaire de version est indispensable pour votre projet personnel s'il a un tant soit peu d'envergure.

Le gestionnaire vous permettra d'avoir un historique de vos fichiers, c'est aussi une sauvegarde, vous n'aurez a priori pas de soucis de « merge » comme sur un projet à plusieurs et, si par hasard vous travaillez sur deux machines, vous avez à disposition un moyen facile de transférer votre travail. Ce cas de deux machines est d'ailleurs encore un cas où travailler seul est travailler en équipe : vous sur votre ordinateur de bureau n'êtes pas le même que sur votre ordinateur portable.

À partir de quand ?

Quand est-ce qu'un projet personnel possède assez d'envergure pour avoir des besoins d'équipe ? À vous de voir. Je dirais que si vous commencez à utiliser le mot « projet », c'est qu'il faut commencer à l'envisager. Si vous parlez de « petit test », alors ce n'est peut-être pas la peine.

Cependant, certaines méthodes, comme les commentaires ou une notation homogène deviendront des réflexes. À force de les employer, même les petits tests en profiteront (avec peut-être quelques écarts). D'autres méthodes, comme l'utilisation d'un gestionnaire de version, ne sont pas utiles dans ces petits tests.

Éviter l'éparpillement

Prenez du temps à considérer en quoi consiste votre projet. Puis réunissez les outils qui vous sont nécessaires. Enfin, conformez-vous à votre idée et surtout, à vos outils. Beaucoup de projets passent de l'état de développement à l'état de tests incessants de logiciels.

Il n'est pas question de ne jamais changer de logiciels, mais il faut bien garder à l'esprit que tout changement à un énorme coût en temps et que, ce temps là, vous ne le passerez pas à développer votre projet. Si vous avez choisi un IDE et que celui-ci fonctionne bien, gardez-le ; ne changez pas toutes les semaines pour voir ce qu'apporte la nouvelle version en développement. Si vous avez choisi de construire votre projet avec des Makefile, ne décidez pas tout à coup, suite à la lecture d'un article, que vous allez tout passer sous Scons puis deux semaines après sous Ant. Même changer de version de votre système d'exploitation est un coût non négligeable en temps.

Ce coût en temps ne se limite pas au temps passé à installer le nouvel outil. Il faut prendre en compte le temps de reconfiguration, le temps de mise à jour de votre projet - qui peut fonctionner différemment avec une nouvelle version d'un outil -, le temps de prise en main et, parfois, le temps de revenir en arrière car ce nouvel outil ou cette nouvelle version apporte plus de problèmes qu'il ou elle n'en résout.

Une équipe fait ses changements après mure réflexion et peut même, si elle est assez grosse, se payer le luxe de continuer son développement pendant que l'un des membres étudie le nouvel outil et juge si le changement est intéressant.

Sur ce point, vous avez plus de contraintes qu'une équipe : vous êtes tout seul. L'étude du nouvel outil, même en parallèle de votre projet, va délayer votre développement. Or une des causes d'arrêt de projets personnels est la perte de motivation suite à un développement qui dure trop longtemps sans avancées perceptibles.

Considérations diverses

Non, le but de cet article n'est pas de donner des raisons à chaque programmeur se lançant dans un projet seul d'être ou de devenir d'hébéphrénique. Mais le fait d'être seul implique forcément que l'on va assumer chaque poste et chaque tâche du projet. Il n'est donc pas, à mon avis, inintéressant de se considérer comme une équipe.

Inutile cependant de trop en faire. Une équipe aura besoin de mécanismes dont vous n'aurez pas besoin, ou que vous ne pourrez pas appliquer car vous êtes, physiquement, seul. Inutile de sortir le diagramme de Gantt pour vous fixer des objectifs dans les six prochains mois si votre projet est un hobby, mais il peut être utile d'avoir une idée de planning, dans les grandes lignes, si vous avez une échéance. Un concours limité par le temps comme Novendiales par exemple. Inutile non plus d'essayer de faire du « pair programming ».

Le dosage est à votre discrétion. Mais gardez en tête que vous aller évoluer et que donc « programmer seul, c'est déjà programmer en équipe ».