Opinion :
Introduction sur les bonnes pratiques de développement

Oyez Oyez jeune bio-informaticien, étudiant de master, professionnel débutant ou autre curieux, cet article a été écrit spécialement 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 premier écrit par Nolwenn, et le second par Nisaea. Mais aussi à partager votre précieuse expérience en commentaire.

Licence de contenu de FreeImages.com

Licence de contenu de FreeImages.com

Dans le mot bio-informatique, il y a informatique, et dans notre domaine cela rime souvent avec la production de scripts, de packages, de pipelines ou de projets parfois plus conséquents. La production d'un code de qualité (quel que soit les critères), est quelque chose de difficile. Nombreux sont ceux qui parmi nous ont travaillé sur plusieurs projets, certains se chevauchant même. Plus le temps de développement sera conséquent, plus il sera facile de laisser dériver son code le rendant... moins élégant et ressemblant vite à ce que certains appellent une "boule de graisse"[1].

Pour éviter ce genre de situation, nos très chers camarades informaticiens ont mis en place de nombreuses méthodes, des conseils pratiques et une attitude générale à avoir pour la réalisation d'un projet. L'objet de cet article sera d'introduire quelques conseils issus de ces méthodes et qui de manière générale, rendront vos pratiques de programmation plus faciles au quotidien. En fonction de votre expérience, vous aurez sûrement de nombreuses autres bonnes idées, sujets pratiques ou outils rendant le travail plus agréable. Alors surtout, ne vous gênez pas, partagez, commentez, discutez et un jour peut-être, nous pourrons écrire un wiki, ou bien même un article plus complet sur le sujet tous ensemble ? Afin de lancer le mouvement, nous commencerons aujourd'hui par une introduction générale.

Cas généraux

Un point important que j'ai commencé à apprendre véritablement en stage est simple : un script qui va être utilisé par d'autres doit être pensé pour faciliter au maximum ces utilisateurs. Cela implique, avant toute forme de codage et de design d'algorithme, de réfléchir à l'utilisateur. Que voudra-t-il ? Que cherche-t-il à réaliser ? Quelles sont les options auxquelles celui-ci souhaite avoir accès ? Un module est conçu pour celui qui l'utilise, pas celui qui l'implémente. Pour garder cette idée en tête il peut être important de :

  • Découper son travail journalier en session : en fonction de vos pauses, et de votre rythme ces sessions peuvent être de trente minutes, une... ou deux heures. En début de session il faudra prendre une petite minute pour se dire "quel résultat vais-je fournir à l'utilisateur" et "comment ce résultat doit-il se présenter". En fin de session il faut alors se demander "le résultat que j'ai produit est-il conforme à l'objectif que je me suis fixé ?". En fonction de la réponse, il faut alors se poser toutes les questions sur pourquoi l'objectif a-t'il été atteint ou non afin d'avancer de manière plus efficace à la session suivante.
  • Bien décomposer son code : aussi vrai qu'un travail bien défini aide à savoir ce que nous devons faire, un code bien structuré permet de se retrouver facilement dedans. Pour cette partie là j'invite à suivre deux conseils pratiques issus de la méthode scrum[2]. Le premier conseil est de toujours commencer par implémenter le minimum vital dans votre script pour qu'il fonctionne, sans penser aux cas limites et exceptions qui devront être gérés ensuite. Le second est que chaque script de votre projet doit être défini par sa tâche fonctionnelle ou sa classe. De manière simple : toujours commencer par coder le minimum vital, n'implémenter qu'un seul objet par fichier, ou une seule tâche fonctionnelle.

Le multi projet

Quand on travaille sur plusieurs projets en même temps il peut arriver que l'un soit mis en parenthèse temporairement. Et là, au moment de revenir dessus, c'est le drame : on ne se souvient plus du tout de ce qui est codé, la doc n'est toujours pas faite (et ne le sera qu'en fin de projet hum…), et la dernière fonction implémentée semble totalement obscure avec une syntaxe qui paraissait brillante sur le moment mais aujourd'hui semble écrite par un autre !

C'est dans ce genre de situation qu'un code bien commenté peut devenir utile. Actuellement j'en suis à une période de ma vie où je commente un maximum mon code. Je ne vais pas revenir sur comment bien commenter un code (pour ça quelques conseils sont disponibles dans de nombreux articles ou  dans un livre de Richard Johnson[3]), voici cependant ce que j'essaie d'appliquer : à la fin de chaque session de travail, si je sais que je ne vais pas revenir dessus le lendemain matin ou tout de suite après. J'essaie de noter, soit directement en fin de code soit sur une feuille à part : date de la dernière session de travail, ce qui est fait, ce qui reste à faire, et en plus, le but de la dernière fonction implémentée avec un maximum de contexte autour ou de mots clefs pour me souvenir rapidement de l'ensemble.

Pour vous aider dans cette tache, il existe un outil connu de tous qui se nomme les gestionnaires de versions, l'un des plus populaire est git[4]. En effet, en général à la fin d'une session de travail, on actualise notre projet avec le code implémenté dans la journée, et c'est en cela que le gestionnaire de version vous aidera en vous demandant quels sont les ajouts proposés par votre version du projet. Un bon commit est un commit fonctionnel ou bien décrit vous permettant de vous retrouvez dans le projet le jour ou vous allez vouloir le reprendre pour écrire le commit suivant. L'art du bon commit à par ailleurs déjà été décris dans d'autres articles[5] !

Enfin point important, il existe de nombreux outils pour faciliter la gestion de projet en groupe. Certains sont basés sur des méthodologies d'entreprise tel que la méthode agile[6] comme par exemple Taiga[7]. D'autres sont des outils visant simplement à faciliter la communication en fonction de votre propre méthodologie tel que Trello[8]. Ces outils sont là pour faciliter une des parties les plus difficiles dans  la gestion de projet, la communication. Ils permettent de définir un rôle à chaque personne et d'avoir un historique des tâches à effectuer. Chaque membre du projet aura un accès à l'historique complet de ce qui est fait, facilitant l'arrivée de nouvelle personne.

Conclusion

Voila, j'espère à travers ces lignes simples et ces quelques idées générales, avoir réussi à vous sensibiliser à des problèmes de notre quotidien. C'est à vous de voir si cela vous aidera dans votre travail en fonction de quel genre de bio-informaticien vous souhaitez devenir, et surtout de trouver vos propres méthodes pour être plus efficace. Bonne chance à vous, et n'hésitez pas à rajouter d'autres conseils ou références sur le sujet en commentaire !

Un grand merci aux relecteurs: Kumquatum, Pierre Marijon Et Nolwenn !

Citations :

1 : Geek Sublime, Vickham chandra, 2014, Édition Robert Laffont.

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

3 : The elements of matlab style, 2011, Richard Johnson, Édition Cambridge.

4 : https://bioinfo-fr.net/git-usage-collaboratif

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

6 : http://www.agiliste.fr/introduction-methodes-agiles/

7 : https://taiga.io

8 : https://trello.com

  • À propos de
  • Bioinformaticien de formation ayant complété son cursus par un master de machine learning appliqué aux langues à Nantes. Actuellement en Doctorat au laboratoire physique théorique de la matière condensé à Paris, ma thèse a pour sujet l'organisation 3D des génomes eucaryotes et les éléments répétés. J'aime python, le machine learning et les techniques d'études des chromosomes.

Catégorie: Opinion | Tags: ,

Un commentaire sur “Introduction sur les bonnes pratiques de développement

  1. Les méthodes sont les habitudes de l\'esprit et les économies de la mémoire!

Laisser un commentaire