Batswirl

Ou pourquoi je ne recommande pas une nouvelle fonctionnalité de Microsoft Visual Studio Team Foundation Server 2008.

Rappel : la fonctionnalité permet d'extraire la dernière version du fichier lorsque vous demandez son extraction pour modificaiton. Il s'agit du comportement par défaut de Visual Source Safe et a été largement demandé par un certain nombre d' utilisateurs de TFVC 2005 qui n'en disposait pas

Il est désormais connu de tous qu'au cours de la planification d'un projet il est indispensable de fixer des jalons, des points de repère qui nous permettront de vérifier que nous ne nous sommes pas écartés du droit chemin, de notre objectif initial. Si tel est le cas, nous corrigerons notre route, nos tâches à faire afin de reprendre la bonne direction.

Cette technique, bien connue des adeptes de la navigation aérienne, nous l'utilisons tous les jours, à tout moment, dans chacune de nos actions. Nous établissons un plan de route que nous nous efforçons de tenir. Les imprévus font que nous devons nous positionner puis nous réorienter avant de pouvoir reprendre notre route.

Et en quoi cela concerne-t-il un contrôleur de code source ou un développeur me direz-vous?

Les développeurs n'échappent pas à la règle.

Je me place rarement derrière une machine, dans un environnement de travail sans savoir ce que je vais réaliser. A partir d'un objectif, je vais placer mes jalons, les sous-modules, les types, les routines qui me permettront de mener à bien ma tâche et faire progresser mon produit.

Je commence donc mon travail, je crée des classes, des interfaces,bref... Je crée des fichiers. Tout irait pour le mieux jusqu'à ce que j'aie à travailler en équipe et que j'utilise un contrôleur de code source et/ou que je doive prendre en compte l'existant.

Je m'apprête à modiifer cette classe abstraite dont je dérive afin que cette dernière me fournisse un service bien sympathique et là... c'est le drame.

Un développeur a mis à jour cette classe depuis ma dernière extraction du fichier et j'ai activé l'option Get lastest on Check-out. Je dois désormais prendre en compte dans mon plan, cette nouvelle méthode à implémenter, les modifications du contexte etc...

Qu'à cela ne tienne, les obstacles ne m'effraient guère et je consens à implémenter cette méthode et à modifier les paramètres d'appel des différentes méthodes.

Pourtant,  au cours de la journée, l'incident se répète sans cesse et je commence à ne plus trop cerner mon plan d'action initial. J'en arrive même à faire des concessions dans ma conception initiale afin de me plier aux apports des autres développeurs. Soit.

Le constat

Le constat que nous pouvons tirer de cette journée de travail type est que le report des modifications d'un référentiel commun dans notre espace de travail et sans intervention de notre part nous force à intégrer ces modifications dans notre travail en cours.

Pourtant, je l'avoue, je ne suis pas thread safe et l'accumulation de paramètres à prendre en compte réduit ma capacité à prendre les bonnes décisions sur le sous système que je suis en train de concevoir.

Les différentes déviations que me font prendre ces modifications, m'eloignent petit à petit de ma route que je distingue de moins en moins. Imaginez qu'au cours de ces déviations, un golf s'offre à moi et vous comprendrez le retard que je pourrais prendre (les personnes me connaissant feront le rapprochement).

En bref, si les méthodes agiles préconisent une réactivité face au changement, elles permettent également d'organiser ce changement. Après tout, durant mon développement si je pressens devoir prendre en compte des modifications présentes sur le serveur, rien ne m'empêche de les récupérer. Cependant, je ne vois aucun intérêt à subir les affres d'un quelconque automatisme dans cette opération.

Une des valeurs agiles : Le courage

N'ayez crainte, il ne s'agit pas d'un article uniquement réservé aux adeptes des méthodes agiles, certains frileux des termes itérations et incrémentales ont déjà approuvé mes propos concernant mon point de vue sur cette option de TFS.

Le courage, c'est aussi être honnête et reconnaître ses fautes. Ainsi, il m'arrive, parfois, durant mon développement, d'être lassé de cette "intégration" continue (notez bien les guillemets et ne me faites pas dire ce que je n'ai pas dit).

Lassé, au point de tout faire pour en arriver à ce que je veux : Compiler, tester.

Alors que fait le développeur dans ce cas?

Il intègre me direz vous. Non monsieur, il corrige, atténue, prend en compte pour palier son besoin primaire : Compiler et voir si ce qu'il a écrit marche.

Certains appellent cela une intégration, pour ma part, j'appellerais ça une rustine.

Ne nous y trompons pas, le changement et l'intégration non organisés sont des virus qui peuvent mettre à mal votre volonté de bien faire.

Et l'intégration alors?

J'entends alors au loin les discours moqueurs me signalant que je n'ai toujours pas intégré mon code avec le référentiel et que je vais en mettre du temps. Ma réponse est Oui, je vais mettre du temps pour intégrer, mais aussi prendre le temps d'intégrer.

L'intégration consiste à confronter vos réalisations face aux modifications apportées par vos coéquipiers. Une partie de mon planning quotidien ou hebdomadaire devra être réservée à cela. Si, en plus, ces créneaux horaires sont communs à l'ensemble de l'équipe, je disposerais de collègue entièrement disponibles pour parler de telle abstraction à revoir ou de telle librairie que j'ai utilisée et qui leur permettrait d'archiver et donc d'intégrer plus rapidement. Encore une fois, déranger un développeur par vos propres soucis durant son développement ne provoquera que deux choses :

• Vous parlerez dans le vide ou presque
• Il ne vous invitera pas à son mariage se rappellant de ce petit bug que vous l'avez aidé à glisser dans sa fonctionnalité et qui a coûté si cher en production

Voilà pourquoi je ne recommande pas et je n'active pas l'option Get lastest on Check Out dans Team Foundation Version Control 2008.

Dans une prochaine publication, je confronterai mes résultats de test de QI à ceux de Visual Studio afin d'expliquer pourquoi je ne laisse jamais l'IDE s'occuper de mon espace de travail.