Comment organiser son travail ?

L'organisation du tra­vail peut sem­bler facile, ce n'est pas tou­jours le cas, sur­tout lorsque l'on est impli­qué dans 2 ou 3 pro­jets à la fois. Com­ment se sou­ve­nir de ce que l'on a fait il y a un mois alors même que l'on ne sait plus ce que l'on a fait la veille ? Où sont mes docu­ments dont j'ai besoin pour finir ce script ? Qu'est-ce que j'ai fait de ce fou­tu papier qui parle de la méthode que je dois appli­quer ?

Qui d'entre nous ne s'est jamais retrou­vé confron­té à ce genre de casse-tête ? Très peu j'imagine. Dans ce billet je vais essayer, sans pré­ten­tion, de vous don­ner des pistes pour vous orga­ni­ser sur votre lieu de tra­vail. Bien que je n'applique pas tou­jours ces pistes, elles pour­ront peut-être vous sau­ver la mise !

1 Carnet + 1 Stylo = finies les excuses !

Si comme moi vous êtes tête en l'air ou que vous oubliez par­fois des détails, notam­ment des détails impor­tants, je vous recom­mande très for­te­ment de prendre le plus de petites notes que pos­sible. Si vous avez buté sur un pro­blème pen­dant plu­sieurs heures, jours ou semaines, et que vous avez enfin pu le résoudre, n'hésitez pas à vous noter en rouge d'où venait le pro­blème et com­ment vous avez réus­si à y remé­dier ! Il vous sera alors plus facile de vous rap­pe­ler quelle était la solu­tion plu­tôt que de vous dire "j'ai déjà eu ce pro­blème, mais je ne sais plus com­ment je l'ai réso­lu !"

Le brouillon, l'ami du programmeur

Si vous vous lan­cez dans un pro­jet un peu à l'aveugle, n'hésitez pas à tou­jours avoir du brouillon sous la main. Il en va de même si vous devez débo­guer le pro­gramme de quelqu'un d'autre. Ne vous lan­cez pas dans une fas­ti­dieuse phase de pro­gram­ma­tion ou de débo­gage sans savoir ce que dois faire le script source.

Si vous vous lan­cez dans un nou­veau pro­jet, jetez vos idées sur un brouillon, ça peut vous aider à mettre en avant une suite logique et, sou­vent, des méca­nismes déjà déve­lop­pés soit dans d'autres pro­jets, soit dans des algo­rithmes connus et ayant déjà fait leurs preuves. Comme nous le disons sou­vent en infor­ma­tique : ne réin­ven­tons pas la roue !

Notre bête noire à tous : faire une documentation

Ne négli­gez jamais l'importance d'une bonne docu­men­ta­tion ! Si vous venez d'être embau­ché dans une équipe que vous ne connais­sez pas, et que vous êtes là pour reprendre le poste d'une per­sonne plus expé­ri­men­tée que vous, vous aurez trois cas de figures pos­sibles.

Le pre­mier cas de figure est la docu­men­ta­tion claire comme on aime à les trou­ver. Il n'y a rien de plus per­tur­bant que de ne pas savoir où sont les pro­grammes déve­lop­pés, com­ment et pour­quoi ils ont été déve­lop­pés. Une bonne docu­men­ta­tion peut aus­si bien vous ser­vir si vous devez reve­nir sur les scripts d'un pro­jet qui date de plus de trois mois ‑ne rigo­lez pas, ça m'est arri­vée !- que pour votre suc­ces­seur éven­tuel. De plus, le fait de four­nir une bonne docu­men­ta­tion aux uti­li­sa­teurs peut vous évi­ter bien des désa­gré­ments.

Le second cas de figure est la docu­men­ta­tion bâclée. Comme l'indique le titre de cette sec­tion, la docu­men­ta­tion est notre bête noire à tous. Cer­tains peuvent donc avoir ten­dance à faire une docu­men­ta­tion pour faire une docu­men­ta­tion, com­pre­nez par là que la docu­men­ta­tion leur a été deman­dée mais qu'ils n'ont pas for­cé­ment eu suf­fi­sam­ment de temps ou de bonne volon­té (pour cer­tains) pour faire une bonne "doc".

Enfin, le der­nier cas est la docu­men­ta­tion inexis­tante. Le fait de ne pas dis­po­ser de docu­men­ta­tion peut entraî­ner, auprès de vos uti­li­sa­teurs ou de vos suc­ces­seurs, de nom­breuses heures à fouiller les nom­breux réper­toires et scripts avant de trou­ver LE pro­gramme dont ils ont besoin. Pis, l'absence d'un tel docu­ment peut pro­vo­quer de nom­breuses chutes de che­veux pré­ma­tu­rées chez nous : il n'y a rien de plus rageant que d'avoir mis trois semaines à déve­lop­per un pro­gramme puis, au moment de le déployer, de décou­vrir qu'un pro­gramme simi­laire avait déjà été mis en place !

Classer ses dossiers, ça peut aider

Nous savons tous faire des dos­siers sur notre machine ou même sur la machine par­ta­gée avec nos col­lègues. Mais savons-nous bien géné­rer nos réper­toires ?

Je n'entends pas par là la façon de créer le-dit dos­sier, mais plus de son nom et de l'endroit où il est créé.

Dans la mesure du pos­sible, essayez d'avoir une logique dans la hié­rar­chie. Il n'y a rien de plus dif­fi­cile que de se rap­pe­ler d'un che­min consti­tué de nom­breux dos­siers. Si vous avez pen­sé cor­rec­te­ment votre arbo­res­cence, un uti­li­sa­teur qui cherche un docu­ment en par­ti­cu­lier pour­ra, en un coup d’œil, esti­mer quel réper­toire est le plus sus­cep­tible de conte­nir son docu­ment.

Je code mais je m'éparpille et je casse mes scripts, quelle solution ?

Dans ce para­graphe je vous par­le­rai de deux cas d'écoles bien dis­tincts : la bonne école et la mau­vaise école. Com­men­çons par la mau­vaise école.

La mauvaise école : écrire directement dans le script ou le copier en mon_script_version12.py

Je qua­li­fie de mau­vaise école la méthode qui consiste à modi­fier le script direc­te­ment dans son code source, mais éga­le­ment la méthode qui consiste à dupli­quer  son code source pour y appor­ter une modi­fi­ca­tion, mineure ou majeure.

La modi­fi­ca­tion d'un script direc­te­ment dans un code source peut être à double tran­chant. Autant pour une modi­fi­ca­tion mineure cela ne devrait pas poser de pro­blème, autant pour une modi­fi­ca­tion impor­tante vous pour­riez très vite le regret­ter. Il est très dif­fi­cile, lorsque l'on apporte ce genre de modi­fi­ca­tion, de pou­voir reve­nir faci­le­ment en arrière si l'on a mal fait un algo­rithme. Si vous n'avez fait qu'une dizaine de modi­fi­ca­tions, vous pour­rez tou­jours reve­nir à la ver­sion de départ en annu­lant vos actions, mais qu'en est-il pour des cen­taines de modi­fi­ca­tions ? Il se peut, très vrai­sem­bla­ble­ment, que vous ne puis­siez pas reve­nir à une ver­sion stable, et ça peut arri­ver plus vite qu'on ne le pense ! Si vous n'aviez pas encore sau­ve­gar­dé vos modi­fi­ca­tions, vous aurez juste per­du du temps. En revanche, si vous aviez déjà sau­ve­gar­dé vos modi­fi­ca­tions, il vous fau­dra vous armer de cou­rage et de patience pour débug­ger.

La dupli­ca­tion de code source peut certes paraître être une bonne idée, elle n'est pas com­plè­te­ment inutile, mais elle risque d'apporter une lour­deur dans la main­te­nance du-dit code source. Si vous avez trois ver­sions de votre script, cela ne devrait pas être trop gênant pour la ges­tion et savoir, à terme, quels fichiers sont à sup­pri­mer et quels fichiers sont à gar­der. Mais plus vous aurez de ver­sions et plus vous ris­que­rez de ne plus savoir quels sont les scripts fonc­tion­nels et quels sont les scripts posant pro­blème. Il vous sera alors très dif­fi­cile de faire le tri.

La bonne école : utiliser un gestionnaire de version

Avant d'aborder ce point, une petite défi­ni­tion s'impose.

Un ges­tion­naire de ver­sion est un outil qui vous per­met de gérer vos dif­fé­rents pro­jets, que ce soit des pro­jets de docu­men­ta­tion, de pré­sen­ta­tion, de pro­gram­ma­tion ou tout autre type de pro­jet. Cet outil vous per­met ain­si de gar­der une trace de vos dif­fé­rentes modi­fi­ca­tions à par­tir du moment où vous avez pris la peine de "pré­ve­nir" le ges­tion­naire que vous avez fait une mise à jour. Fini de se retrou­ver avec 20 copies d'un même script, ou de ne plus pou­voir reve­nir en arrière si vous modi­fiez trop votre code source, si vous faites une erreur, vous pour­rez deman­der au ges­tion­naire de vous redon­ner la ver­sion pré­cé­dente, ou une autre ver­sion anté­rieure fonc­tion­nelle.

L'autre avan­tage du ges­tion­naire de ver­sion réside dans le fait que vous pou­vez assi­gner un pro­jet à un groupe d'utilisateurs. Vous pour­rez donc tra­vailler à plu­sieurs sur un même pro­jet. Mieux ! Vous pour­rez sau­ve­gar­der vos don­nées à plu­sieurs, cer­tains ges­tion­naires gérant assez bien l'accès concur­ren­tiel. Au pire, si vous n'êtes pas sûr de vous, vous pou­vez tou­jours affi­cher la dif­fé­rence entre vos fichiers modi­fiés et ceux mis à jour der­niè­re­ment dans l'outil.

Il existe dif­fé­rents logi­ciels de ges­tion de ver­sion, dans le monde d'Unix et du libre, nous pou­vons notam­ment citer Sub­ver­sion, Git, mer­cu­rial ou bien encore Bazaar. Si vous connais­sez bien le monde d'Unix sachez que le launch­pad est basé sur un ges­tion­naire de ver­sion. Ce type d'outil est donc mas­si­ve­ment uti­li­sé !

Conclusion

Il existe dif­fé­rentes façons d'organiser son tra­vail, à cha­cun d'adopter les méthodes qui lui conviennent ou qu'il peut mettre en place sur son lieu de tra­vail. Autant si vous êtes dans une infra­struc­ture de bio­in­for­ma­ti­ciens ou d'informaticiens vous uti­li­sez sûre­ment déjà les bonnes méthodes, autant si vous êtes le seul réfé­rent (bio)informaticien dans un labo­ra­toire de bio­lo­gie vous ris­que­rez de devoir pra­ti­quer les mau­vaises méthodes pen­dant quelques temps.

Pour ma part j'utilise beau­coup la méthode du "je note ce que je fais au fur et à mesure, on ne sait jamais !", et ça me sauve bien sou­vent la mise ! Je docu­mente éga­le­ment autant que pos­sible mes pro­grammes, afin que les uti­li­sa­teurs sachent dans quel but ils ont été déve­lop­pés et com­ment ils fonc­tionnent. Enfin, j'essaie de tou­jours gar­der une logique dans la hié­rar­chie et dans les noms de mes fichiers et pro­grammes, ce qui aide beau­coup pour mémo­ri­ser les che­mins et les pro­grammes à uti­li­ser. En revanche notre infra­struc­ture ne dis­pose pas de logi­ciel de ges­tion de ver­sions et, étant la seule à avoir des connais­sances, même éparses, avec ce type d'outil, je passe par la mau­vaise école pour évi­ter de cas­ser mes codes sources. Et encore, quand je ne modi­fie pas direc­te­ment dans mon code source 🙂  !

Un der­nier point, que je n'ai pas abor­dé mal­gré son impor­tance, concerne les com­men­taires. Ce point a été abor­dé pré­cé­dem­ment par Nisaea dans ce billet que je vous invite à lire pour com­plé­ter cette lec­ture.

Mer­ci à bu, ZaZoOo, nahoy et Yoann M. pour leur relec­ture et leurs com­men­taires.