- Le blog participatif de bioinformatique francophone depuis 2012 -

The Bio Code : guide du bon broinformaticien

par

dans

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.

 Photo credit: Marjan Krabelj (CC 2.0)
Pho­to cre­dit : Mar­jan Kra­belj (CC 2.0)

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

 Photo credit: Sean MacEntee (CC 2.0)
Pho­to cre­dit : Sean MacEn­tee (CC 2.0)

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.

xkcd — (CC BY-NC 2.5)

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

(CC-NC 2.0)
XP clas­sic (CC-NC 2.0)

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.

Photo credit: Irish Typepad (CC-BY-NC-ND 2.0)
Pho­to cre­dit : Irish Type­pad (CC-BY-NC-ND 2.0)

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.




Commentaires

7 réponses à “The Bio Code : guide du bon broinformaticien”

  1. Bon­jour,

    je me per­mets de vous signa­ler cet article de jan­vier 2014 qui com­plète vos conseils :
    Best Prac­tices for Scien­ti­fic Com­pu­ting
    Wil­son G, Aru­liah DA, Brown CT, Chue Hong NP, Davis M, et al. (2014) Best Prac­tices for Scien­ti­fic Com­pu­ting. PLoS Biol 12(1): e1001745. doi:10.1371/journal.pbio.1001745

    http://www.plosbiology.org/article/info%3Adoi%2F10.1371%2Fjournal.pbio.1001745

    Voi­ci une tra­duc­tion per­son­nelle du résu­mé inclus dans l'article :
    Refe­rence
    1. Écrire des pro­grammes à des­ti­na­tion d'êtres humains et non à des ordi­na­teurs
    (a) Un pro­gramme ne doit pas exi­ger pour être com­pris d'avoir en tête plus d'une poi­gnée d'éléments
    (b) Choi­sir des noms cohé­rents, cli­vants et expli­cites
    (c) Choi­sir un for­ma­tage et un style de code constant et cohé­rent
    2. Lais­ser l'ordinateur tra­vailler seul
    (a) Lais­ser à l'ordinateur les tâches répé­ti­tives
    (b) Faire un his­to­rique des com­mandes en vue de leur réuti­li­sa­tion
    (c) Uti­li­ser un outil spé­ci­fique pour conce­voir et exé­cu­ter les work­flows
    3. Faire des chan­ge­ments incré­men­tals
    (a) Avan­cer par petits pas avec des tests fré­quents tout en rec­ti­fiant les objec­tifs si néces­saire
    (b) Uti­li­ser un sys­tème de contrôle de ver­sion
    (c) Gérer tous vos fichiers (code com­pris) avec un sys­tème de contrôle de ges­tion
    4. Ne faites aucune répé­ti­tion
    (a) Chaque infor­ma­tion doit avoir une seule repré­sen­tion fai­sant auto­ri­té dans tout le sys­tème
    (b) Modu­la­ri­ser votre code plu­tôt que faire du copier-col­ler
    (c) Réuti­li­ser votre code plu­tôt que le réécrire
    5. Pré­voir les erreurs
    (a) Ajou­ter des opé­ra­tions de véri­fi­ca­tion
    (b) Uti­li­ser des biblio­thèques de test rela­tives aux lan­gages uti­li­sés
    (c) Consi­dé­rer les bugs comme des oppor­tu­ni­tés de test
    (d) Uti­li­ser un débug­geur sym­bo­lique
    6. Opti­mi­ser le pro­gramme seule­ment après une preuve de fonc­tion­ne­ment cor­rect
    (a) Uti­li­ser un logi­ciel de pro­fi­lage pour iden­ti­fier les points cri­tiques
    (b) Pri­vi­lé­gier les lan­gages de plus haut niveau d'abstraction [le plus proche du lan­gage natu­rel ndt]
    7. La docu­men­ta­tion doit détailler les inten­tions et les buts mais pas les recettes de cui­sine [c'est pour­quoi le code se doit d'être expli­cite ndt]
    (a) La docu­men­ta­tion détaille et relie les buts mais dis­si­mule des moyens [elle doit dire pour­quoi mais pas com­ment ndt]
    (b) Rema­nier le code de pré­fé­rence pour le rendre plus expli­cite
    (c) Inclure la docu­men­ta­tion dans le code
    8. Col­la­bo­rer
    (a) Revi­ser son code avant de le fusion­ner (Use pre-merge code reviews)
    (b) Uti­li­ser la pro­gram­ma­tion en binôme pour ini­tier un nou­veau rapi­de­ment ou pour faire face à un pro­blème par­ti­cu­liè­re­ment dif­fi­cile
    (c) Uti­li­ser un outil de sui­vi

  2. C'est quoi un bro­in­for­ma­ti­cien ?
    Vive la relec­ture 😉

    1. Yoann M.
      Yoann M.

      Cher GG,

      https://lmddgtfy.net/?q=bro%2Bcode

      Quant à nos relec­teurs, ils seraient heu­reux de vous accueillir par­mi eux si celà vous tente 😉

      1. En sui­vant le lien, je n'ai pas com­pris, mais je dois être trop vieux… ou pas assez miso.

        "Quand à" => "Quant à" 😉

        1. Yoann M.

          😉

  3. Avatar de EVillain
    EVillain

    Pour le point 5 se pas­ser de lib externe signi­fie sou­vent reco­der la roue, si elles existent autant les réuti­li­ser 🙂 après quand on est gen­til avec l'utilisateur on fait un script d'installation tout propre qui les ins­talle pour lui.

Laisser un commentaire