Opinion :
Comment organiser son travail ?

L'organisation du travail peut sembler facile, ce n'est pas toujours le cas, surtout lorsque l'on est impliqué dans 2 ou 3 projets à la fois. Comment se souvenir de ce que l'on a fait il y a un mois alors même que l'on ne sait plus ce que l'on a fait la veille ? Où sont mes documents dont j'ai besoin pour finir ce script ? Qu'est-ce que j'ai fait de ce foutu papier qui parle de la méthode que je dois appliquer ?

Qui d'entre nous ne s'est jamais retrouvé confronté à ce genre de casse-tête ? Très peu j'imagine. Dans ce billet je vais essayer, sans prétention, de vous donner des pistes pour vous organiser sur votre lieu de travail. Bien que je n'applique pas toujours ces pistes, elles pourront peut-être vous sauver la mise !

Et maintenant, je fais quoi ? | Auteur PublicDomainPictures, licence CC0

Et maintenant, je fais quoi ? | Auteur PublicDomainPictures, licence CC0

1 Carnet + 1 Stylo = finies les excuses !

Bloc note et crayon à papier | Auteur : PublicDomainPictures, licence CC0

Bloc note et crayon à papier | Auteur : PublicDomainPictures, licence CC0

Si comme moi vous êtes tête en l'air ou que vous oubliez parfois des détails, notamment des détails importants, je vous recommande très fortement de prendre le plus de petites notes que possible. Si vous avez buté sur un problème pendant plusieurs heures, jours ou semaines, et que vous avez enfin pu le résoudre, n'hésitez pas à vous noter en rouge d'où venait le problème et comment vous avez réussi à y remédier ! Il vous sera alors plus facile de vous rappeler quelle était la solution plutôt que de vous dire "j'ai déjà eu ce problème, mais je ne sais plus comment je l'ai résolu !"

Le brouillon, l'ami du programmeur

Si vous vous lancez dans un projet un peu à l'aveugle, n'hésitez pas à toujours avoir du brouillon sous la main. Il en va de même si vous devez déboguer le programme de quelqu'un d'autre. Ne vous lancez pas dans une fastidieuse phase de programmation ou de débogage sans savoir ce que dois faire le script source.

Si vous vous lancez dans un nouveau projet, jetez vos idées sur un brouillon, ça peut vous aider à mettre en avant une suite logique et, souvent, des mécanismes déjà développés soit dans d'autres projets, soit dans des algorithmes connus et ayant déjà fait leurs preuves. Comme nous le disons souvent en informatique : ne réinventons pas la roue !

Notre bête noire à tous : faire une documentation

Ne négligez jamais l'importance d'une bonne documentation ! Si vous venez d'être embauché dans une équipe que vous ne connaissez pas, et que vous êtes là pour reprendre le poste d'une personne plus expérimentée que vous, vous aurez trois cas de figures possibles.

Le premier cas de figure est la documentation claire comme on aime à les trouver. Il n'y a rien de plus perturbant que de ne pas savoir où sont les programmes développés, comment et pourquoi ils ont été développés. Une bonne documentation peut aussi bien vous servir si vous devez revenir sur les scripts d'un projet qui date de plus de trois mois -ne rigolez pas, ça m'est arrivée !- que pour votre successeur éventuel. De plus, le fait de fournir une bonne documentation aux utilisateurs peut vous éviter bien des désagréments.

Le second cas de figure est la documentation bâclée. Comme l'indique le titre de cette section, la documentation est notre bête noire à tous. Certains peuvent donc avoir tendance à faire une documentation pour faire une documentation, comprenez par là que la documentation leur a été demandée mais qu'ils n'ont pas forcément eu suffisamment de temps ou de bonne volonté (pour certains) pour faire une bonne "doc".

Enfin, le dernier cas est la documentation inexistante. Le fait de ne pas disposer de documentation peut entraîner, auprès de vos utilisateurs ou de vos successeurs, de nombreuses heures à fouiller les nombreux répertoires et scripts avant de trouver LE programme dont ils ont besoin. Pis, l'absence d'un tel document peut provoquer de nombreuses chutes de cheveux prématurées chez nous : il n'y a rien de plus rageant que d'avoir mis trois semaines à développer un programme puis, au moment de le déployer, de découvrir qu'un programme similaire avait déjà été mis en place !

Classement de la documentation par dossier | Auteur geralt, licence CC0

Classement de la documentation par dossier | Auteur geralt, licence CC0

Classer ses dossiers, ça peut aider

Nous savons tous faire des dossiers sur notre machine ou même sur la machine partagée avec nos collègues. Mais savons-nous bien générer nos répertoires ?

Je n'entends pas par là la façon de créer le-dit dossier, mais plus de son nom et de l'endroit où il est créé.

Dans la mesure du possible, essayez d'avoir une logique dans la hiérarchie. Il n'y a rien de plus difficile que de se rappeler d'un chemin constitué de nombreux dossiers. Si vous avez pensé correctement votre arborescence, un utilisateur qui cherche un document en particulier pourra, en un coup d’œil, estimer quel répertoire est le plus susceptible de contenir son document.

Je code mais je m'éparpille et je casse mes scripts, quelle solution ?

Dans ce paragraphe je vous parlerai de deux cas d'écoles bien distincts : la bonne école et la mauvaise école. Commençons par la mauvaise école.

La mauvaise école : écrire directement dans le script ou le copier en mon_script_version12.py

Je qualifie de mauvaise école la méthode qui consiste à modifier le script directement dans son code source, mais également la méthode qui consiste à dupliquer  son code source pour y apporter une modification, mineure ou majeure.

La modification d'un script directement dans un code source peut être à double tranchant. Autant pour une modification mineure cela ne devrait pas poser de problème, autant pour une modification importante vous pourriez très vite le regretter. Il est très difficile, lorsque l'on apporte ce genre de modification, de pouvoir revenir facilement en arrière si l'on a mal fait un algorithme. Si vous n'avez fait qu'une dizaine de modifications, vous pourrez toujours revenir à la version de départ en annulant vos actions, mais qu'en est-il pour des centaines de modifications ? Il se peut, très vraisemblablement, que vous ne puissiez pas revenir à une version stable, et ça peut arriver plus vite qu'on ne le pense ! Si vous n'aviez pas encore sauvegardé vos modifications, vous aurez juste perdu du temps. En revanche, si vous aviez déjà sauvegardé vos modifications, il vous faudra vous armer de courage et de patience pour débugger.

La duplication de code source peut certes paraître être une bonne idée, elle n'est pas complètement inutile, mais elle risque d'apporter une lourdeur dans la maintenance du-dit code source. Si vous avez trois versions de votre script, cela ne devrait pas être trop gênant pour la gestion et savoir, à terme, quels fichiers sont à supprimer et quels fichiers sont à garder. Mais plus vous aurez de versions et plus vous risquerez de ne plus savoir quels sont les scripts fonctionnels et quels sont les scripts posant problème. Il vous sera alors très difficile de faire le tri.

La bonne école : utiliser un gestionnaire de version

Avant d'aborder ce point, une petite définition s'impose.

Un gestionnaire de version est un outil qui vous permet de gérer vos différents projets, que ce soit des projets de documentation, de présentation, de programmation ou tout autre type de projet. Cet outil vous permet ainsi de garder une trace de vos différentes modifications à partir du moment où vous avez pris la peine de "prévenir" le gestionnaire que vous avez fait une mise à jour. Fini de se retrouver avec 20 copies d'un même script, ou de ne plus pouvoir revenir en arrière si vous modifiez trop votre code source, si vous faites une erreur, vous pourrez demander au gestionnaire de vous redonner la version précédente, ou une autre version antérieure fonctionnelle.

L'autre avantage du gestionnaire de version réside dans le fait que vous pouvez assigner un projet à un groupe d'utilisateurs. Vous pourrez donc travailler à plusieurs sur un même projet. Mieux ! Vous pourrez sauvegarder vos données à plusieurs, certains gestionnaires gérant assez bien l'accès concurrentiel. Au pire, si vous n'êtes pas sûr de vous, vous pouvez toujours afficher la différence entre vos fichiers modifiés et ceux mis à jour dernièrement dans l'outil.

Il existe différents logiciels de gestion de version, dans le monde d'Unix et du libre, nous pouvons notamment citer Subversion, Git, mercurial ou bien encore Bazaar. Si vous connaissez bien le monde d'Unix sachez que le launchpad est basé sur un gestionnaire de version. Ce type d'outil est donc massivement utilisé !

Conclusion

Il existe différentes façons d'organiser son travail, à chacun d'adopter les méthodes qui lui conviennent ou qu'il peut mettre en place sur son lieu de travail. Autant si vous êtes dans une infrastructure de bioinformaticiens ou d'informaticiens vous utilisez sûrement déjà les bonnes méthodes, autant si vous êtes le seul référent (bio)informaticien dans un laboratoire de biologie vous risquerez de devoir pratiquer les mauvaises méthodes pendant quelques temps.

Pour ma part j'utilise beaucoup la méthode du "je note ce que je fais au fur et à mesure, on ne sait jamais !", et ça me sauve bien souvent la mise ! Je documente également autant que possible mes programmes, afin que les utilisateurs sachent dans quel but ils ont été développés et comment ils fonctionnent. Enfin, j'essaie de toujours garder une logique dans la hiérarchie et dans les noms de mes fichiers et programmes, ce qui aide beaucoup pour mémoriser les chemins et les programmes à utiliser. En revanche notre infrastructure ne dispose pas de logiciel de gestion de versions et, étant la seule à avoir des connaissances, même éparses, avec ce type d'outil, je passe par la mauvaise école pour éviter de casser mes codes sources. Et encore, quand je ne modifie pas directement dans mon code source 🙂  !

Un dernier point, que je n'ai pas abordé malgré son importance, concerne les commentaires. Ce point a été abordé précédemment par Nisaea dans ce billet que je vous invite à lire pour compléter cette lecture.

Merci à bu, ZaZoOo, nahoy et Yoann M. pour leur relecture et leurs commentaires.

  • À propos de
  • Issue d'une licence de biologie cellulaire et physiopathologie et d'un master de bioinformatique, je m'intéresse tout particulièrement au monde de la recherche et au domaine de la santé. J'ai travaillé dans l'unité 946 de l'INSERM, dirigée par Florence Demenais, où mon travail principal a été l'étude et la recherche de bases de données et d'outils d'intérêt majeur pour l'axe de recherche dans lequel j'étais impliquée. J'ai aussi travaillé à l'Institut Pasteur où j'ai été recrutée en tant qu'ingénieure bioinformaticienne dans le cadre du LabEx Milieu Intérieur et où ma mission principale a été de mettre en place une base de données pour la gestion de nos échantillons biologiques. Mes centres d'intérêt en bioinformatique sont : la mise en application de méthodes dans les domaines de la génomique, de la protéomique et les interactions gène-gène protéine-protéine pouvant nous apporter des informations sur leurs influences dans les maladies. Je travaille actuellement au service informatique de l'IBENS où j'ai été recrutée en qualité de développeuse d'applications !

2 commentaires sur “Comment organiser son travail ?

  1. c\'est ce genre d\'articles où on donne des astuces aux gens qui me plaisent!
    ces articles construisent ma personnalité et surtout, me permettent d\'être de plus en plus méthodique car les méthodes sont les habitudes de l\'esprit et les économies de la mémoire!

  2. Du coup, tu es plutôt stylo + cahier, mais pas trop notebook digital ? Est-ce qu\'il y en a parmi vous qui se servent d\'un cahier de labo numérique. Si oui, avec quoi ?

Laisser un commentaire