The Bio Code : guide du bon broinformaticien

Mal­gré la mul­ti­tude d’outils déjà exis­tants, les occa­sions d'écrire du code sont nom­breuses en bio­in­for­ma­tique. Hor­mis pour les pousse-bou­tons aver­tis, le déve­lop­pe­ment fait sou­vent par­tie du quo­ti­dien d’un bio­in­for­ma­ti­cien. Per­son­nel­le­ment, c’est une acti­vi­té qui me plaît beau­coup dans ce métier. Déve­lop­per ses propres appli­ca­tions et outils apporte tou­jours une cer­taine satis­fac­tion (et quand ça fonc­tionne, c’est encore mieux !). C'est un peu comme la cui­sine de Mémé, c'est tel­le­ment meilleur quand c'est fait mai­son.

Seule­ment voi­là, nous bio­in­for­ma­ti­ciens, ne sommes pas ana­lystes pro­gram­meurs et cela peut par­fois se res­sen­tir sur notre manière de déve­lop­per. Il suf­fit d’aller faire un tour dans les sources de cer­tains outils (même connus) pour se rendre compte que ça a été codé avec les pieds par un bio­in­for­ma­ti­cien. J’ai moi-même écrit une quan­ti­té de scripts à l’arrache très mal opti­mi­sés, dont je suis peu fier mais qui m’ont per­mis, avec le temps, de deve­nir un peu plus rigou­reux dans ma manière de déve­lop­per. Depuis, j'essaie de suivre quelques règles de 'bonne conduite' dans tous mes pro­jets, que ce soit un petit script ou un pro­jet plus consé­quent. J'espère que ces quelques points per­met­tront à cer­tains de prendre de bonnes habi­tudes. Allez, c'est par­ti !

1- Faire un état des lieux

Vous avez besoin d’une appli­ca­tion spé­ci­fique ? Cher­chez bien, quelqu’un a sans doute déjà écrit quelque chose de simi­laire. Cette pre­mière étape me paraît assez évi­dente et je suis sûr que vous êtes rodés à l'utilisation d'un moteur de recherche. C’est une bonne chose de pro­po­ser des alter­na­tives mais de manière géné­rale, évi­tez de réécrire des outils qui existent déjà… sauf si c’est pour faire mieux évi­dem­ment !

2- Choi­sir un lan­gage adap­té

Un cahier des charges est un bon point de départ pour le choix du lan­gage. Par­fois quelques bul­let-points suf­fi­ront pour orga­ni­ser ses idées et trou­ver un lan­gage adap­té. À mon avis, si le temps le per­met, il ne faut pas avoir peur de se lan­cer dans l’apprentissage de quelque chose de nou­veau qui pour­ra peut-être s’avérer utile dans d’autres pro­jets futurs. De manière géné­rale, “tout” est pos­sible, avec n’importe quel lan­gage de pro­gram­ma­tion, mais il est évident que cer­tains sont meilleurs que d’autres dans cer­tains domaines. Ne vous lan­cez pas, par exemple, dans du cal­cul matri­ciel en Perl… jamais…même sous la menace… Pour aller plus loin sur ce sujet, Gophys a réa­li­sé un article concer­nant le choix des lan­gages de pro­gram­ma­tion.

3- Uti­li­ser un ges­tion­naire de ver­sion

L’ uti­li­sa­tion d’un ges­tion­naire de ver­sion pré­sente de nom­breux avan­tages (col­la­bo­ra­tion, sui­vi des modi­fi­ca­tions, sau­ve­garde, etc). Il existe plé­thore de ser­vices de ges­tion de déve­lop­pe­ment en ligne (sour­ce­forge, github, bit­bu­cket, pour en citer quelques-uns). De plus, la plu­part des ges­tion­naires de ver­sion peuvent être ins­tal­lés loca­le­ment sur votre machine et sont rela­ti­ve­ment faciles à uti­li­ser. Plus lar­ge­ment, l'article de Nol­wenn vous pré­sente quelques solu­tions pour mener à bien votre pro­jet.

4- Four­nir une docu­men­ta­tion Même si votre pro­gramme n’est pas des­ti­né à être publié, pre­nez l’habitude d’y ajou­ter des infor­ma­tions concer­nant son uti­li­sa­tion. Une docu­men­ta­tion (même mini­male) doit faire par­tie inté­grante de tous vos déve­lop­pe­ments. C’est tou­jours frus­trant de tom­ber sur ce genre de chose :

Tou­jours pas convain­cu par l'utilité de ces com­men­taires ? Allez donc voir l'article de Nisaea !

5 — Limi­ter les biblio­thèques externes

Inté­grer des biblio­thèques externes per­met de faci­le­ment étendre les fonc­tion­na­li­tés de vos outils. Atten­tion tou­te­fois à ne pas rendre votre appli­ca­tion com­plè­te­ment dépen­dante de celles-ci. C'est sou­vent la source de pro­blèmes de com­pa­ti­bi­li­té et cela peut rendre l’installation com­pli­quée. Exemple d'un pro­gramme que vous ne vou­lez pas ins­tal­ler sur votre machine :

6 — Ecrire du code réuti­li­sable …

On a tous des scripts sans com­men­taire, ni docu­men­ta­tion qui trainent sur un coin de disque dur. Avec les années, ces bouts de code se perdent et on se retrouve à réécrire les mêmes rou­tines. Écrire du code réuti­li­sable, c’est avant tout une manière de pro­gram­mer (écrire des fonc­tions géné­riques, uti­li­ser des classes, pro­gram­ma­tion orien­tée objet, etc) et cela vient avec la pra­tique. Per­son­nel­le­ment, je n'ai pas encore trou­vé la solu­tion idéale  pour orga­ni­ser mes snip­pets (mais je n'ai pas trop cher­ché non plus). De nom­breuses pos­si­bi­li­tés existent : uti­li­sa­tion d'un ges­tion­naire de ver­sion, outils dédiés, simples fichiers textes orga­ni­sés par lan­gage, etc. D'ailleurs, si quelqu'un a des recom­man­da­tions, ça m'intéresse.

7 — … et exten­sible

Il arrive très sou­vent de devoir étendre les fonc­tion­na­li­tés de ses outils, gar­dez tou­jours cette idée en tête ! Là encore, écrire du code exten­sible dépend beau­coup de la manière de pro­gram­mer, de la pra­tique, mais sur­tout l'utilisation de desi­gn pat­terns adap­tés faci­li­te­ront l'ajout de nou­velles fonc­tions. Idéa­le­ment, l’ajout d’extensions doit être pos­sible sans avoir à modi­fier votre code de base.

8 — Uti­li­ser des for­mats stan­dards

L’utilisation de for­mats stan­dards pour les fichiers d’entrée/sortie ren­dra vos appli­ca­tions plus simple à uti­li­ser. De plus, les for­mats stan­dards pos­sèdent sou­vent des modules de lecture/​écriture que vous pour­rez inté­grer direc­te­ment dans vos outils.

9 — Tes­ter !

Votre appli­ca­tion a de grandes chances de ne pas fonc­tion­ner du pre­mier coup. Il est impor­tant de tes­ter et véri­fier que tout fonc­tionne avant de la publier. Pré­voyez des jeux de don­nées à essayer et, si pos­sible, trou­vez des volon­taires pour tes­ter votre appli­ca­tion afin d’avoir des avis exté­rieurs. Enfin, essayez d’inclure un mini­mum de tests uni­taires  afin d’assurer le bon fonc­tion­ne­ment de votre pro­gramme.

10 — Ne lési­nez pas sur la ges­tion d'erreur

Ces deux der­niers points s’appliquent sur­tout aux appli­ca­tions ren­dues publiques. Une bonne docu­men­ta­tion asso­ciée à une bonne ges­tion d’erreur per­met­tront à vos uti­li­sa­teurs de com­prendre ce qui se passe en cas de pro­blème et leur per­met­tra de se débrouiller. Essayez de four­nir des mes­sages d’erreur « utiles » pour l’utilisateur.

10 * — Atten­tion aux licences.

Enfin, il est impor­tant de véri­fier la licence  des biblio­thèques ou modules que vous  sou­hai­tez inté­grer à votre appli­ca­tion. Je ne four­ni­rai pas de conseils légaux car de mon coté, j’ai tou­jours trou­vé les termes des licences assez confus. Mais c’est un point impor­tant à consi­dé­rer, sur­tout si votre appli­ca­tion est des­ti­née à être publiée.

Mer­ci à Wocka, Clem_​, et Yoann M. pour leur relec­ture.