Astuce :
The Bio Code : guide du bon broinformaticien

Malgré la multitude d’outils déjà existants, les occasions d'écrire du code sont nombreuses en bioinformatique. Hormis pour les pousse-boutons avertis, le développement fait souvent partie du quotidien d’un bioinformaticien. Personnellement, c’est une activité qui me plaît beaucoup dans ce métier. Développer ses propres applications et outils apporte toujours une certaine satisfaction (et quand ça fonctionne, c’est encore mieux !). C'est un peu comme la cuisine de Mémé, c'est tellement meilleur quand c'est fait maison.

 Photo credit: Marjan Krabelj (CC 2.0)

Photo credit: Marjan Krabelj (CC 2.0)

 

Seulement voilà, nous bioinformaticiens, ne sommes pas analystes programmeurs et cela peut parfois se ressentir sur notre manière de développer. Il suffit d’aller faire un tour dans les sources de certains outils (même connus) pour se rendre compte que ça a été codé avec les pieds par un bioinformaticien. J’ai moi-même écrit une quantité de scripts à l’arrache très mal optimisés, dont je suis peu fier mais qui m’ont permis, avec le temps, de devenir un peu plus rigoureux dans ma manière de développer. Depuis, j'essaie de suivre quelques règles de 'bonne conduite' dans tous mes projets, que ce soit un petit script ou un projet plus conséquent. J'espère que ces quelques points permettront à certains de prendre de bonnes habitudes. Allez, c'est parti !

 

 

1- Faire un état des lieux

Vous avez besoin d’une application spécifique ? Cherchez bien, quelqu’un a sans doute déjà écrit quelque chose de similaire. Cette première étape me paraît assez évidente et je suis sûr que vous êtes rodés à l'utilisation d'un moteur de recherche. C’est une bonne chose de proposer des alternatives mais de manière générale, évitez de réécrire des outils qui existent déjà… sauf si c’est pour faire mieux évidemment !

2- Choisir un langage adapté

Un cahier des charges est un bon point de départ pour le choix du langage. Parfois quelques bullet-points suffiront pour organiser ses idées et trouver un langage adapté. À mon avis, si le temps le permet, il ne faut pas avoir peur de se lancer dans l’apprentissage de quelque chose de nouveau qui pourra peut-être s’avérer utile dans d’autres projets futurs. De manière générale, “tout” est possible, avec n’importe quel langage de programmation, mais il est évident que certains sont meilleurs que d’autres dans certains domaines. Ne vous lancez pas, par exemple, dans du calcul matriciel en Perl… jamais…même sous la menace… Pour aller plus loin sur ce sujet, Gophys a réalisé un article concernant le choix des langages de programmation.

3- Utiliser un gestionnaire de version

 Photo credit: Sean MacEntee (CC 2.0)

Photo credit: Sean MacEntee (CC 2.0)

L’ utilisation d’un gestionnaire de version présente de nombreux avantages (collaboration, suivi des modifications, sauvegarde, etc). Il existe pléthore de services de gestion de développement en ligne (sourceforge, github, bitbucket, pour en citer quelques-uns). De plus, la plupart des gestionnaires de version peuvent être installés localement sur votre machine et sont relativement faciles à utiliser. Plus largement, l'article de Nolwenn vous présente quelques solutions pour mener à bien votre projet.

 

4- Fournir une documentation Même si votre programme n’est pas destiné à être publié, prenez l’habitude d’y ajouter des informations concernant son utilisation. Une documentation (même minimale) doit faire partie intégrante de tous vos développements. C’est toujours frustrant de tomber sur ce genre de chose:

Toujours pas convaincu par l'utilité de ces commentaires ? Allez donc voir l'article de Nisaea !

 

5 - Limiter les bibliothèques externes

Intégrer des bibliothèques externes permet de facilement étendre les fonctionnalités de vos outils. Attention toutefois à ne pas rendre votre application complètement dépendante de celles-ci. C'est souvent la source de problèmes de compatibilité et cela peut rendre l’installation compliquée. Exemple d'un programme que vous ne voulez pas installer sur votre machine :

 

6 - Ecrire du code réutilisable …

On a tous des scripts sans commentaire, ni documentation 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 routines. Écrire du code réutilisable, c’est avant tout une manière de programmer (écrire des fonctions génériques, utiliser des classes, programmation orientée objet, etc) et cela vient avec la pratique. Personnellement, je n'ai pas encore trouvé la solution idéale  pour organiser mes snippets (mais je n'ai pas trop cherché non plus). De nombreuses possibilités existent : utilisation d'un gestionnaire de version, outils dédiés, simples fichiers textes organisés par langage, etc. D'ailleurs, si quelqu'un a des recommandations, ça m'intéresse.

 

7 - … et extensible

Il arrive très souvent de devoir étendre les fonctionnalités de ses outils, gardez toujours cette idée en tête ! Là encore, écrire du code extensible dépend beaucoup de la manière de programmer, de la pratique, mais surtout l'utilisation de design patterns adaptés faciliteront l'ajout de nouvelles fonctions. Idéalement, l’ajout d’extensions doit être possible sans avoir à modifier votre code de base.

 

8 - Utiliser des formats standards

L’utilisation de formats standards pour les fichiers d’entrée/sortie rendra vos applications plus simple à utiliser. De plus, les formats standards possèdent souvent des modules de lecture/écriture que vous pourrez intégrer directement dans vos outils.

xkcd - (CC BY-NC 2.5)

9 - Tester !

Votre application a de grandes chances de ne pas fonctionner du premier coup. Il est important de tester et vérifier que tout fonctionne avant de la publier. Prévoyez des jeux de données à essayer et, si possible, trouvez des volontaires pour tester votre application afin d’avoir des avis extérieurs. Enfin, essayez d’inclure un minimum de tests unitaires  afin d’assurer le bon fonctionnement de votre programme.

 

10 - Ne lésinez pas sur la gestion d'erreur

(CC-NC 2.0)

XP classic (CC-NC 2.0)

Ces deux derniers points s’appliquent surtout aux applications rendues publiques. Une bonne documentation associée à une bonne gestion d’erreur permettront à vos utilisateurs de comprendre ce qui se passe en cas de problème et leur permettra de se débrouiller. Essayez de fournir des messages d’erreur « utiles » pour l’utilisateur.

 

10 * - Attention aux licences.

Photo credit: Irish Typepad (CC-BY-NC-ND 2.0)

Photo credit: Irish Typepad (CC-BY-NC-ND 2.0)

 

 

 

Enfin, il est important de vérifier la licence  des bibliothèques ou modules que vous  souhaitez intégrer à votre application. Je ne fournirai pas de conseils légaux car de mon coté, j’ai toujours trouvé les termes des licences assez confus. Mais c’est un point important à considérer, surtout si votre application est destinée à être publiée.

 

 

 

Merci à Wocka, Clem_, et Yoann M. pour leur relecture.

7 commentaires sur “The Bio Code : guide du bon broinformaticien

  1. Bonjour,

    je me permets de vous signaler cet article de janvier 2014 qui complète vos conseils :
    Best Practices for Scientific Computing
    Wilson G, Aruliah DA, Brown CT, Chue Hong NP, Davis M, et al. (2014) Best Practices for Scientific Computing. PLoS Biol 12(1): e1001745. doi:10.1371/journal.pbio.1001745

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

    Voici une traduction personnelle du résumé inclus dans l\'article :
    Reference
    1. Écrire des programmes à destination d\'êtres humains et non à des ordinateurs
    (a) Un programme ne doit pas exiger pour être compris d\'avoir en tête plus d\'une poignée d\'éléments
    (b) Choisir des noms cohérents, clivants et explicites
    (c) Choisir un formatage et un style de code constant et cohérent
    2. Laisser l\'ordinateur travailler seul
    (a) Laisser à l\'ordinateur les tâches répétitives
    (b) Faire un historique des commandes en vue de leur réutilisation
    (c) Utiliser un outil spécifique pour concevoir et exécuter les workflows
    3. Faire des changements incrémentals
    (a) Avancer par petits pas avec des tests fréquents tout en rectifiant les objectifs si nécessaire
    (b) Utiliser un système de contrôle de version
    (c) Gérer tous vos fichiers (code compris) avec un système de contrôle de gestion
    4. Ne faites aucune répétition
    (a) Chaque information doit avoir une seule représention faisant autorité dans tout le système
    (b) Modulariser votre code plutôt que faire du copier-coller
    (c) Réutiliser votre code plutôt que le réécrire
    5. Prévoir les erreurs
    (a) Ajouter des opérations de vérification
    (b) Utiliser des bibliothèques de test relatives aux langages utilisés
    (c) Considérer les bugs comme des opportunités de test
    (d) Utiliser un débuggeur symbolique
    6. Optimiser le programme seulement après une preuve de fonctionnement correct
    (a) Utiliser un logiciel de profilage pour identifier les points critiques
    (b) Privilégier les langages de plus haut niveau d\'abstraction [le plus proche du langage naturel ndt]
    7. La documentation doit détailler les intentions et les buts mais pas les recettes de cuisine [c\'est pourquoi le code se doit d\'être explicite ndt]
    (a) La documentation détaille et relie les buts mais dissimule des moyens [elle doit dire pourquoi mais pas comment ndt]
    (b) Remanier le code de préférence pour le rendre plus explicite
    (c) Inclure la documentation dans le code
    8. Collaborer
    (a) Reviser son code avant de le fusionner (Use pre-merge code reviews)
    (b) Utiliser la programmation en binôme pour initier un nouveau rapidement ou pour faire face à un problème particulièrement difficile
    (c) Utiliser un outil de suivi

  2. C\'est quoi un broinformaticien ?
    Vive la relecture 😉

    • Cher GG,

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

      Quant à nos relecteurs, ils seraient heureux de vous accueillir parmi eux si celà vous tente 😉

      • En suivant le lien, je n\'ai pas compris, mais je dois être trop vieux... ou pas assez miso.

        \"Quand à\" => \"Quant à\" 😉

        • 😉

    • http://www.freelives.net/BROFORCE/BROFORCE_WEB.html

      peut être ???!!??

  3. Pour le point 5 se passer de lib externe signifie souvent recoder la roue, si elles existent autant les réutiliser 🙂 après quand on est gentil avec l\'utilisateur on fait un script d\'installation tout propre qui les installe pour lui.

Laisser un commentaire