Nooooooon ! Non, c’est mort d’avance. Jamais, never, ei koskaan ! On ne développera pas notre projet universitaire avec Dropbox : jamais, jamais tu entends ?
Il y a quelques mois, avant de commencer un projet à l’université, il a fallu se mettre d’accord sur la façon de travailler. Comment on partage le travail, comment on met en commun etc. La solution qui semblait évidente pour tous était : Google docs pour les rapports & Dropbox pour le code. Sauf que… bah j’étais pas vraiment d’accord avec cette solution. Pas du tout même. D’une part, j’ai pas de compte Google, donc pour éditer les documents, c’est moins facile… [0] mais j’admets que ça puisse être pratique pour éditer un petit document à plusieurs, soit, admettons. Mais alors… Dropbox pour partager du code. Là, quand j’entends ça, ça me fait saigner les tympans. Quand je vois quelqu’un faire ça, ça me donne la conjonctivite. Quand quelqu’un pense à soumettre l’idée de faire ça, ça me donne la migraine. [1]
J’aimerai donc dire, ici, à tous les étudiants qui utilisent Dropbox pour gérer leurs projets qu’il faut arrêter. Tout de suite ! Je vais essayer de vous montrer pourquoi. Dans un prochain article, je vous présenterai Mercurial.
Pourquoi Dropbox c’est pas pour le dev.
Donc, je concède que Dropbox puisse être pratique pour partager des photos, des pdf, des vidéos. Ces documents n’ont pas besoin d’être modifiés. Une personne met ses photos dans un dossier Dropbox, une autre en ajoute etc. Et à la fin, tout le monde à les photos de tout le monde. Donc, là, ça peut être pratique. Je suppose que les personnes utilisant Dropbox pour développer se sont dit exactement la même chose :
On fait un dossier partagé, on mettra le code dedans. Quand on veut faire une modification sur un fichier, on la fait, ça met tout à jour chez tout le monde et c’est trop cool.
Oui, mais non. C’est pas cool. Ce qui n’est pas cool, c’est justement la fonction de synchronisation. Imaginons un projet à deux développeurs utilisant Dropbox. Vous faîtes des modifications dans un fichier et à chaque enregistrement, ça synchronise avec votre binôme. Ça veut dire que le binôme qui faisait ses modif’ dans son coin sur son fichier à lui, se retrouve avec vos modif’ à vous aussi et vice-versa. Et là, bonjour le debuggage. C’est juste impossible à suivre.
Pour palier ce problème, plusieurs astuces ont vu le jour. La première est de couper la synchronisation. Comme ça, vous faîtes vos modifications dans votre coin. Et quand ça fonctionne enfin du tonnerre, vous voulez partager ça. Vous croisez alors les doigts pour que le binôme n’ait pas modifié le code entre temps et paaaaf vous synchronisez tout. Le problème, c’est quand le binôme a synchronisé ses modifications avant vous. Vous vous retrouvez comme un jambon a devoir aller chercher les modifications qu’il a faîtes, les intégrer à votre code, vérifier que tout fonctionne [2] et resynchroniser (en espérant que le binôme n’ait pas fait de nouvelles modifications entre temps, sinon vous êtes bon pour un autre tour ^^). Et d’après ce que j’ai entendu, Dropbox fait un beau mélange des fichiers et c’est juste indécrottable… Très vite, on se rend compte que c’est vraiment casse-pied. Et c’est là que nait la seconde astuce.
Vu que c’est vraiment pénible de devoir chercher dans le code les modifications du binôme pour se les copier/coller à la main puis de resynchroniser tout, on cherche une autre solution. L’autre solution que j’ai eu le bonheur entre voir est de définir un planning. Le planning disant qui peut coder et quand. Dans le cas de deux personnes, on peut imaginer que les jours pairs c’est l’un qui s’y colle et les jours impairs c’est l’autre. Dans le cas de trois polynômes, chacun peut coder un jour tous les trois jours. Etc. Et comme ça, plus de problème. Bon… faudrait pas être cinquante parce que sinon on ne ferait pas grand chose, mais ça fonctionne ^^.
Il faut bien avouer que, ça élimine tous les problèmes, mais c’est quand même supeeeeeer contraignant. Ça veut dire que si j’ai une super idée un jour où c’est pas à moi de coder, j’ai plus qu’à la noter sur un post-it pour y repenser le lendemain ? J’espère qu’à ce stade déjà, les utilisateurs Dropbox me lisant auront vu que c’était pas acceptable de travailler comme ça. Mais, je vais enfoncer encore un peu plus le clou pour être sûr que le message passe.
On est dimanche 17 novembre, c’est un jour impair c’est donc à moi de coder. Je me lance. Deux heures plus tard, coup de téléphone, on me propose d’aller manger une crêpe en ville et comme j’adore les crêpes, je ne sais refuser et pars laissant mon travaille en plan. La crêpe est suivie d’une bière ou deux et j’en oublie complètement mon code qui m’attend patiemment. Je rentre, je décide de couper mon cerveau en allumant la télévision. Deux heures plus tard, je retourne à mon ordinateur et vois mon code, qui m’attend. C’est pas fini, mais tant pis, mon binôme finira demain, allez je synchronise tout ça. La question que j’aimerai maintenant poser est simple : comment votre binôme peut-il voir ce que vous avez modifié par rapport à la version précédente ? Comment votre binôme peut savoir ce que vous avez commencé ? Alors oui, Dropbox fait des snapshots à chaque synchronisation et permet de revenir en arrière, mais comment vous faîtes pour voir la différence entre deux fichiers ? C’est à dire, ce qui en sort et ce qui en entre ? Bah… il sait pas faire (à ma connaissance). Votre binôme est bon pour chercher les différences entre le code d’avant et vos modifications. Avouez qu’il y a plus intéressant comme jeu pour un lundi matin. Votre binôme pourrait se dire que vous avez juste écrit n’importe quoi et choisir de restaurer la version précédente. Au quel cas, votre travail est simplement parti à la poubelle. Mais heureusement, vous pourrez recommencer… le lendemain.
Autre cas de figure. J’ai une idée top cool. Avant d’en parler à mes binômes, j’aimerai faire des petits tests voir si ce que je pense tiens la route. Je coupe la synchronisation − pour ne pas les embêter (en plus, c’est pas à moi de coder ce jour là…). Je code ma super feature, c’est un peu bancale, mais ça devrait suffire pour leur montrer à quel point c’est peut être cool. Maintenant, question. Comment je fais pour leur montrer ma super feature ? Je synchronise tout avec le code principal, alors que ça bug un peu ? Je fais un nouveau dossier partagé Dropbox ? Je les fais venir chez moi pour leur montrer (mais du coup, ils n’auront pas accès au code pour tester…) ? Je continue tout seul à développer ça et quand ça fonctionnera bien, je synchroniserai tout avec le code principal, en espérant très fort que le code n’est pas trop trop changé… ? Non, sérieusement… vous voyez qu’aucune solution proposée ici n’est valable…
La solution
Tous les problèmes que je viens de vous montrer là se résolvent avec ce qu’on appelle un gestionnaire de versions. Il en existe plein ! Les plus connus sont sans doute Mercurial, Git et Bazaar. Ces outils sont faits exprès pour gérer du code, sont faits exprès pour travailler à plusieurs, sont faits exprès pour gérer des différentes versions d’un projet. Bref, c’est ça qu’il faut utiliser et pas Dropbox ou n’importe quel autre disque dur dans le cloud, c’est juste pas fait pour !
Dans un prochain article, je vous montrerai comment se servir de Mercurial (vu que c’est le gestionnaire de versions que je connais le mieux).
Allez, ciao ;)
| [0] | je crois savoir qu’il est possible de permettre la lecture/écriture à quelqu’un en lui donnant un lien, sans pour autant que cette personne ait un compte. Si vous en savez plus, je suis preneur car on m’a dit que « non, c’est pas possible »… |
| [1] | pour la petite histoire, j’ai proposé d’utiliser Mercurial. Ils m’ont regardé avec des yeux de merlan frit. Je leur ai vite fait montrer. C’était dans un terminal. Et une des filles m’a dit « ah, mais c’est super vieux les terminaux, il faut songer à évoluer maintenant ». Bon… ok ^^ |
| [2] | parce que vous faîtes des tests unitaires, évidement ;) |