Oyez Oyez jeune bio-infor­ma­ti­cien, étu­diant de mas­ter, pro­fes­sion­nel débu­tant ou autre curieux, cet article a été écrit spé­cia­le­ment pour vous par l'un des vôtres ! Pour tous les autres si cet article vous laisse un peu sur votre faim, je vous invite à lire deux autres billets déjà pré­sents sur le site, le pre­mier écrit par Nol­wenn, et le second par Nisaea. Mais aus­si à par­ta­ger votre pré­cieuse expé­rience en com­men­taire.

Dans le mot bio-infor­ma­tique, il y a infor­ma­tique, et dans notre domaine cela rime sou­vent avec la pro­duc­tion de scripts, de packages, de pipe­lines ou de pro­jets par­fois plus consé­quents. La pro­duc­tion d'un code de qua­li­té (quel que soit les cri­tères), est quelque chose de dif­fi­cile. Nom­breux sont ceux qui par­mi nous ont tra­vaillé sur plu­sieurs pro­jets, cer­tains se che­vau­chant même. Plus le temps de déve­lop­pe­ment sera consé­quent, plus il sera facile de lais­ser déri­ver son code le ren­dant… moins élé­gant et res­sem­blant vite à ce que cer­tains appellent une "boule de graisse"[1].

Pour évi­ter ce genre de situa­tion, nos très chers cama­rades infor­ma­ti­ciens ont mis en place de nom­breuses méthodes, des conseils pra­tiques et une atti­tude géné­rale à avoir pour la réa­li­sa­tion d'un pro­jet. L'objet de cet article sera d'introduire quelques conseils issus de ces méthodes et qui de manière géné­rale, ren­dront vos pra­tiques de pro­gram­ma­tion plus faciles au quo­ti­dien. En fonc­tion de votre expé­rience, vous aurez sûre­ment de nom­breuses autres bonnes idées, sujets pra­tiques ou outils ren­dant le tra­vail plus agréable. Alors sur­tout, ne vous gênez pas, par­ta­gez, com­men­tez, dis­cu­tez et un jour peut-être, nous pour­rons écrire un wiki, ou bien même un article plus com­plet sur le sujet tous ensemble ? Afin de lan­cer le mou­ve­ment, nous com­men­ce­rons aujourd'hui par une intro­duc­tion géné­rale.

Cas généraux

Un point impor­tant que j'ai com­men­cé à apprendre véri­ta­ble­ment en stage est simple : un script qui va être uti­li­sé par d'autres doit être pen­sé pour faci­li­ter au maxi­mum ces uti­li­sa­teurs. Cela implique, avant toute forme de codage et de desi­gn d'algorithme, de réflé­chir à l'utilisateur. Que vou­dra-t-il ? Que cherche-t-il à réa­li­ser ? Quelles sont les options aux­quelles celui-ci sou­haite avoir accès ? Un module est conçu pour celui qui l'utilise, pas celui qui l'implémente. Pour gar­der cette idée en tête il peut être impor­tant de :

• Décou­per son tra­vail jour­na­lier en ses­sion : en fonc­tion de vos pauses, et de votre rythme ces ses­sions peuvent être de trente minutes, une… ou deux heures. En début de ses­sion il fau­dra prendre une petite minute pour se dire "quel résul­tat vais-je four­nir à l'utilisateur" et "com­ment ce résul­tat doit-il se pré­sen­ter". En fin de ses­sion il faut alors se deman­der "le résul­tat que j'ai pro­duit est-il conforme à l'objectif que je me suis fixé ?". En fonc­tion de la réponse, il faut alors se poser toutes les ques­tions sur pour­quoi l'objectif a‑t'il été atteint ou non afin d'avancer de manière plus effi­cace à la ses­sion sui­vante.
• Bien décom­po­ser son code : aus­si vrai qu'un tra­vail bien défi­ni aide à savoir ce que nous devons faire, un code bien struc­tu­ré per­met de se retrou­ver faci­le­ment dedans. Pour cette par­tie là j'invite à suivre deux conseils pra­tiques issus de la méthode scrum[2]. Le pre­mier conseil est de tou­jours com­men­cer par implé­men­ter le mini­mum vital dans votre script pour qu'il fonc­tionne, sans pen­ser aux cas limites et excep­tions qui devront être gérés ensuite. Le second est que chaque script de votre pro­jet doit être défi­ni par sa tâche fonc­tion­nelle ou sa classe. De manière simple : tou­jours com­men­cer par coder le mini­mum vital, n'implémenter qu'un seul objet par fichier, ou une seule tâche fonc­tion­nelle.

Le multi projet

Quand on tra­vaille sur plu­sieurs pro­jets en même temps il peut arri­ver que l'un soit mis en paren­thèse tem­po­rai­re­ment. Et là, au moment de reve­nir des­sus, c'est le drame : on ne se sou­vient plus du tout de ce qui est codé, la doc n'est tou­jours pas faite (et ne le sera qu'en fin de pro­jet hum…), et la der­nière fonc­tion implé­men­tée semble tota­le­ment obs­cure avec une syn­taxe qui parais­sait brillante sur le moment mais aujourd'hui semble écrite par un autre !

C'est dans ce genre de situa­tion qu'un code bien com­men­té peut deve­nir utile. Actuel­le­ment j'en suis à une période de ma vie où je com­mente un maxi­mum mon code. Je ne vais pas reve­nir sur com­ment bien com­men­ter un code (pour ça quelques conseils sont dis­po­nibles dans de nom­breux articles ou  dans un livre de Richard John­son[3]), voi­ci cepen­dant ce que j'essaie d'appliquer : à la fin de chaque ses­sion de tra­vail, si je sais que je ne vais pas reve­nir des­sus le len­de­main matin ou tout de suite après. J'essaie de noter, soit direc­te­ment en fin de code soit sur une feuille à part : date de la der­nière ses­sion de tra­vail, ce qui est fait, ce qui reste à faire, et en plus, le but de la der­nière fonc­tion implé­men­tée avec un maxi­mum de contexte autour ou de mots clefs pour me sou­ve­nir rapi­de­ment de l'ensemble.

Pour vous aider dans cette tache, il existe un outil connu de tous qui se nomme les ges­tion­naires de ver­sions, l'un des plus popu­laire est git[4]. En effet, en géné­ral à la fin d'une ses­sion de tra­vail, on actua­lise notre pro­jet avec le code implé­men­té dans la jour­née, et c'est en cela que le ges­tion­naire de ver­sion vous aide­ra en vous deman­dant quels sont les ajouts pro­po­sés par votre ver­sion du pro­jet. Un bon com­mit est un com­mit fonc­tion­nel ou bien décrit vous per­met­tant de vous retrou­vez dans le pro­jet le jour ou vous allez vou­loir le reprendre pour écrire le com­mit sui­vant. L'art du bon com­mit à par ailleurs déjà été décris dans d'autres articles[5] !

Enfin point impor­tant, il existe de nom­breux outils pour faci­li­ter la ges­tion de pro­jet en groupe. Cer­tains sont basés sur des métho­do­lo­gies d'entreprise tel que la méthode agile[6] comme par exemple Tai­ga[7]. D'autres sont des outils visant sim­ple­ment à faci­li­ter la com­mu­ni­ca­tion en fonc­tion de votre propre métho­do­lo­gie tel que Trel­lo[8]. Ces outils sont là pour faci­li­ter une des par­ties les plus dif­fi­ciles dans  la ges­tion de pro­jet, la com­mu­ni­ca­tion. Ils per­mettent de défi­nir un rôle à chaque per­sonne et d'avoir un his­to­rique des tâches à effec­tuer. Chaque membre du pro­jet aura un accès à l'historique com­plet de ce qui est fait, faci­li­tant l'arrivée de nou­velle per­sonne.

Conclusion

Voi­la, j'espère à tra­vers ces lignes simples et ces quelques idées géné­rales, avoir réus­si à vous sen­si­bi­li­ser à des pro­blèmes de notre quo­ti­dien. C'est à vous de voir si cela vous aide­ra dans votre tra­vail en fonc­tion de quel genre de bio-infor­ma­ti­cien vous sou­hai­tez deve­nir, et sur­tout de trou­ver vos propres méthodes pour être plus effi­cace. Bonne chance à vous, et n'hésitez pas à rajou­ter d'autres conseils ou réfé­rences sur le sujet en com­men­taire !

Un grand mer­ci aux relec­teurs : Kum­qua­tum, Pierre Mari­jon Et Nol­wenn !

Citations :

1 : Geek Sublime, Vick­ham chan­dra, 2014, Édi­tion Robert Laf­font.

2 : https://fr.wikipedia.org/wiki/Scrum_(méthode)

3 : The ele­ments of mat­lab style, 2011, Richard John­son, Édi­tion Cam­bridge.

4 : https://​bioin​fo​-fr​.net/​g​i​t​-​u​s​a​g​e​-​c​o​l​l​a​b​o​r​a​tif

5 : https://ensiwiki.ensimag.fr/index.php/Écrire_de_bons_messages_de_commit_avec_Git

6 : http://​www​.agi​liste​.fr/​i​n​t​r​o​d​u​c​t​i​o​n​-​m​e​t​h​o​d​e​s​-​a​g​i​l​es/

7 : https://​tai​ga​.io

8 : https://​trel​lo​.com