Méthodes

Il y a peu, j’ai posé sur Twitter la question :

Sondage express : pour ou contre le commit des fichiers propres à l’IDE dans le gestionnaire de sources ?

Un petit échange s’en est suivi avec @pierre_fauvel, qui pense que c’est en effet une bonne pratique. Pour ma part, je suis plus mitigé sur cette question… 140 caractères, c’est un peu court pour argumenter : je pensais donc publier un billet pour étayer mon avis sur la question. M. Fauvel a eu la même idée, et m’a devancé.

Avant de lire ce qui suit, je vous renvoie donc a son très intéressant billet sur la question.

Oui, il faut partager les bonnes pratiques

Je suis bien évidemment d’accord : il doit y avoir de la communication dans une équipe, ainsi qu’un partage des bonnes pratiques : c’est une évidence !

Il me vient tout de suite à l’esprit plusieurs applications concrètes incontournables de ce principe. En particulier pour tout ce qui concerne l’outillage du projet :

• l’outil de gestion de configuration : c’est la base du travail collaboratif. Il est donc inconcevable qu’un développeur n’utilise pas le même système que les autres
• la gestion du build : la manière de construise le projet doit être la même pour chaque développeur (Ant, Maven, Gradle, Ivy, ou autre), afin d’assurer la reproductibilité de celui-ci. C’est pour cela que nous mettons les fichiers de configuration du build (les pom.xml, profiles.xml, etc. de Maven dans notre cas) sont mis en gestion de configuration.
• les outils d’intégration continue ainsi que les résultats associés (tests en échec, métriques de qualité Sonar, etc.)
• les règles de qualité de code à mettre en place (PMD, CheckStyle, FindBugs). En particulier pour celles-ci, il est important que tous les développeurs soient convaincus de leur utilité, et soient d’accord sur les limites à appliquer et leurs raisons : pourquoi limiter une méthode à 30 lignes de code plutôt que 20 ou 40 ?…

Mais il faut aussi laisser une marge de liberté aux développeurs…

Les points précédents étant acquis, il ne faut pas non plus trop vouloir trop contrôler. En particulier, je ne suis pas partisan d’avoir un environnement de développement unique, configuré de la même manière pour tous les développeurs, et dont la configuration serait mise en gestion de configuration.

En effet, même s’il faut partager les bonnes pratiques, il me semble que certaines pratiques ne peuvent justement pas être hiérarchisées. Dans ce cas, pourquoi en imposer une plutôt qu’une autre ?

Prenons un exemple concret : l’utilisation de SVN avec Eclipse. On peut utiliser Subclipse ou Subversive. Les deux ont des fonctionnalités similaires, et le choix est donc affaire de préférence plus que de « bonne pratique ». On pourrait effectivement choisir d’en imposer un arbitrairement, afin d’uniformiser les environnements de développement, mais j’avoue que je n’en vois pas l’intérêt : le choix n’impacte en rien la productivité, et je préfère donc laisser la liberté à chacun de choisir celui qu’il préfère.

Les développeurs ont souvent leurs propres habitudes, et leurs outils préférés. Et bien souvent, il existe des outils concurrents dont il est difficile de dire lequel est meilleurs que l’autre :

• vi, kate, emacs, etc. pour l’édition de fichiers sur les systèmes Unix
• Notepad++, PSPad, etc. pour faire la même chose sous Windows
• 7Zip ou PeaZip pour la gestion des archives sous Windows
• etc.

Plutôt que d’imposer un outil unique, je préfère laisser le choix aux développeurs d’utiliser celui qu’ils préfèrent. Ainsi, chacun sera efficace (en utilisant l’outil avec lequel il est à l’aise), et cela ne pénalise à mon avis pas le travail de l’ensemble de l’équipe.

Si je fais ce choix, c’est aussi pour une question de moral : un développeur n’est pas un enfant, et n’aime donc généralement pas qu’on le prenne pour tel. J’ai tendance à penser que chacun est à même de décider quels outils lui conviennent le mieux, et appréciera de pouvoir les utiliser : il en sera non seulement plus efficace, mais aussi plus motivé qu’on lui fasse confiance.

Tout ceci n’étant bien sûr vrai que dans la mesure où ces choix personnels ne sont pas gênants pour le travail de l’équipe. Bien sûr, nous discutons souvent de ces choix, et parfois, nous convainquons nos collègues qu’un logiciel est vraiment meilleurs qu’un autre. C’est ainsi que sur la recommandation de Damien, j’ai adopté yEd pour l’édition de diagrammes.

Quelques exemples

Un de mes collaborateurs a préféré travailler sous Ubuntu plutôt que sous Windows. Cet OS répond à ses besoins, et est parfaitement compatible avec le travail du reste de l’équipe (SVN, serveurs de test, etc.). Sa licence Windows a été installée sur une machine virtuelle lorsqu’il en a besoin occasionnellement.

Mon nouveau dada, c’est Git. J’en ai fait la présentation aux équipes de développement, mais avant de le déployer à grande échelle, je préfère le tester : je l’ai donc installé localement, en le connectant au SVN de l’équipe. Mon environnement est donc « personnalisé », mais cela n’impacte pas le travail de l’équipe. Si je suis convaincu, je proposerai aux autres cette solution, en leur présentant ses avantages, mais en laissant libres ceux qui préfèrent garder leurs habitudes de travailler directement avec Subversion. Et il y a des arguments pour chacune, comme par exemple le plugin EGit pour Eclipse qui n’est pas encore du tout au niveau de ceux qui existent pour SVN (mais là, j’anticipe sur un prochain article…).

Nous travaillons tous sous Eclipse. Je n’ai jamais eu l’occasion de travailler avec des IDE mixtes. Mais dans la mesure où d’autres IDE (Netbeans par exemple), permettent de travailler avec Maven, SVN, etc., je ne pense pas que cela soit impossible ou nuisible. Ainsi, si un collaborateur préférait par habitude utiliser un autre IDE, je n’y verrais pas d’inconvénient (mais là, je suis peut-être un grand optimiste).

Conclusion

Afin de laisser cette marge de manoeuvre aux développeurs, il faut y mettre quelques moyens. Deux d’entre eux me viennent à l’esprit :

• chaque développeur est administrateur local de sa machine
• maintien de manière collaborative (wiki, par exemple) d’une liste de « logiciels recommandés » par catégorie : édition de texte, etc., voire d’un centre de téléchargement interne, pour accélérer la vitesse d’accès et uniformiser les versions des logiciels (lorsque c’est pertinent)
• chacun a un accès à Internet peu restreint, permettant au moins l’accès au téléchargement de logiciels (libres) de son choix, mais aussi à la veille technologique, aux forums de discussion techniques, etc. (personnellement, je préconise même l’absence totale de blocage, sauf en cas d’abus manifestes).

A mon sens, cette souplesse ne va pas à l’encontre d’un développement structuré, tant qu’elle respecte la plate-forme de développement commune et les spécificités du projet. Elle permet aux membres de l’équipe de tester plusieurs outils, et d’échanger sur leurs expériences avec ceux-ci.

Cette diversité permet de multiplier les tests comparatifs, de communiquer et de capitaliser sur les résultats de ces tests :

• si un outil a clairement l’avantage sur ses concurrents, il sera naturellement adopté par l’ensemble de l’équipe
• si les outils ne peuvent être départagés, il n’est pas la peine de choisir

Mais revenons au sujet initial. Pour les raisons évoquées ci-dessus, je ne mets pas les fichiers propres à l’IDE sous gestion de configuration. Je ne considère pas la configuration de l’environnement de développement comme étant une « partie intégrante du projet ». Ceci dit, une « configuration type du projet » est tout de même accessible pour ceux qui la veulent : elle n’est pas sous SVN pour éviter à ceux qui ont une configuration personnalisée d’écraser par erreur lors d’un commit celle par défaut.

Il y a peu, j'ai posé sur Twitter la question : Sondage express : pour ou contre le commit des fichiers propres à l'IDE dans le gestionnaire de sources ? Un petit échange s'en est suivi avec @pierre_fauvel, qui pense que c'est en effet une bonne pratique. Pour ma part, je suis plus mitigé sur cette ...