Brainstorming sur les bonnes pratiques

[oliviermeslin]

Bonjour à tous,

j'ouvre cette issue pour recueillir toutes vos idées autour des bonnes pratiques, dans la perspective de rédiger ensemble un guide de bonnes pratiques pour les selfeurs. Toutes les idées sont les bienvenues. J'anticipe qu'@RLesur va nous parler de ROpenSci, et qu'@acazaubiel va nous parler de targets...

[linogaliana]

Regarder aussi la PEP 8 Python dans l'optique de normalisation des langages cousin

[RLesur]

Voici les idées que je soumets au débat.

Le principe général que j'ai à l'esprit est de ne pas réécrire depuis 0 un guide de bonnes pratiques mais s'appuyer sur un ou plusieurs guides faisant "autorité" dans la communauté R. Contrairement à python qui a PEP 8, R n'a pas l'équivalent, ce qui est très gênant.
Par exemple, j'aime beaucoup la présentation du Google's style guide qui est présenté comme un fork du Tydiverse Style Guide en modifiant/adaptant quelques points.

Que choisir comme guides de référence ?

Ma référence pour le développement de packages est effectivement rOpenSci https://devguide.ropensci.org/

Pour le style de code, il est difficile de dire que le Tidyverse Style Guide n'est pas la référence en la matière.

Pour les pipelines analytiques, c'est le plus compliqué je trouve car il y a évidemment targets mais pas seulement.

[sylvainDaubree]

De mon côté, je pousse à nouveau le "savoir compter, savoir coder" https://www.insee.fr/fr/statistiques/4469245 dans les ressources internes, qui me plaît toujours pas mal (ce n'est pas du tout orienté R). Il me semblait qu'il a été réecrit pour un éco & stat, mais je ne sais pas si c'est allé au bout finalement, je n'en ai pas trouvé trace.

[CTassart]

Bonjour,

Beaucoup d'agent·e·s commence à coder (en R notamment) parce que leur poste le nécessite : il·elle·s suivent les 1ères formations "institutionnelles", puis se débrouille au quotidien, sans maîtriser, connaître et/ou appliquer les règles de bonnes pratiques qui, par ailleurs, ne sont pas forcément claires ni mêmes définies pour la programmation avec R.

il me semble important que les bonnes pratiques soient également intégrées, rapidement, dans le cursus des formations INSEE. Peut-être serait-il intéressant de se rapprocher des personnes "compétentes" en la matière ?

[linogaliana]

En y réfléchissant, je me demande si l'ambition de ce guide ne devrait pas être d'introduire, étape par étape, à la définition de méthodes favorables à

• la pérennité
• la reproductibilité
• la lisibilité des projets R (et éventuellement python, je vais y revenir).

Avec ces trois objectifs en tête, on peut produire un guide qui se démarque de contenus déjà existants et avec des préconisations intéressantes pour la gestion de projets de données. On peut même ajouter à ces objectifs la sécurisation des données et des processus de production.

Il ne s'agit bien-sûr pas d'épuiser un sujet mais de faire du nouveau guide un point d'entrée, renvoyant à la foisonnante documentation en ligne. Certes, ci-dessous, je présente des éléments en apparence avancés (intégration continue...) mais il s'agit d'expliquer la justification et l'intérêt, pas de faire un guide complet ou un tutoriel sur chaque question.

Je pense que @avouacr peut également être intéressé par la discussion puisqu'on a eu cette discussion à propos de l'enseignement à l'ENSAE.

1. En premier lieu, les normes de grammaire et de documentation proposées par le tidyverse ou google style guide (R) ou la PEP 8 (python). Ce sont des éléments utiles pour la compréhension commune d'un script.
2. En second lieu, adopter des structures de dossier normalisées et une bonne gestion des dépendances. Les RProjects en R, les cookiescutter en Python. Séparer stockage du code, stockage des données, environnement d'exécution. Expliquer pourquoi structurer un projet en 1 ou plusieurs packages peut améliorer la reproductibilité de celui-ci (mais alerter sur l'enjeu de la maintenance)
3. En troisième lieu Git + Gitlab/Github pour l'archivage, le versionnage du code, la collaboration et la gestion des évolutions du code
4. Si on veut aller plus loin, question de l'intégration continue
5. Si on veut aller plus loin, gérer l'évolution des transformations de données à chaque modification du code avec targets (R) ou l'un des multiples outils disponibles en python (par exemple Airflow)
6. Si on veut aller encore plus loin, introduire à la question (immense) du déploiement d'environnements d'exécution reproductibles: docker, kube, etc.

Doit-on se restreindre à R ? Le guide principal est en R, certes. Mais peu de bonnes pratiques en Python ne sont pas transposables en R (et vice versa).

[py-b]

Pour mémoire, une issue connexe : https://github.com/InseeFrLab/utilitR/issues/355 (attention, contient une envolé lyrique de @acazaubiel)

[avouacr]

Tout à fait d'accord avec @linogaliana. Il me semble que le sujet des bonnes pratiques peut (et gagnerait à) être traité de manière agnostique au langage utilisé. Cela permettrait de souligner les idées fondamentales derrière ces pratiques (le code comme outil de communication, pour soi futur et pour les autres, réflexion en projet voire package, nécessité du contrôle de version, réflexion sur l'environnement d’exécution de l'application..) indépendamment de leur implémentation. Et bien sûr cela éviterait d'avoir à éditer des guides similaires pour les différents langages utilisés en statistique publique, voire qui pourraient émerger dans le futur.

Je trouve aussi pertinent de présenter les bonnes pratiques comme un continuum de degrés de reproductibilité, sur lequel on se placerait en fonction de ses aspirations (portée du projet, potentiel collaboratif, potentiel évolutif, etc.) et de ses contraintes (ressources humaines, temps, etc.). Dans la progression que tu suggères @linogaliana -- et à laquelle je souscris complètement -- il me semble clair que les principes sous-jacents à chaque étape sont assez indépendants du langage utilisé. Dans 1, 2 et 5 il est possible d'expliquer les principes communs, tout en renvoyant aux guides de référence propres à chaque langage, qui ont été suggérés dans la conversation.

[oliviermeslin]

Je suis d’accord avec @CTassart que les bonnes pratiques doivent être enseignées très tôt, dès les débuts de l’apprentissage de R. En revanche, je suis spontanément réticent à l’idée de discuter dès maintenant avec les personnes chargées des formations, car il me semble important que nous ayons les mains libres sur la rédaction du guide.

Je suis également d'accord avec les propositions de @linogaliana et @avouacr, en particulier l'idée d'une gradation des bonnes pratiques en fonction de l'ambition des projets, et l'idée d'un guide de bonnes pratiques qui soit le moins adhérent possible à R.

Toutefois, il me semble que nous pourrions définir un socle minimal de bonnes pratiques valables dans toutes les situations, et qui pourrait être inclus dans les formations (sur R ou sur d'autres langages) en disant: "C'est le minimum indispensable que vous devez appliquer systématiquement". Ce socle rassemblerait en gros les points 1, 2, 3 : avoir des scripts bien rédigés, avoir des dossiers bien structurés, maîtriser les dépendances et versionner les codes avec Gitlab. Si on arrivait à ce que tous les projets développés en self respectent ce socle, on aurait déjà fait un grand bond en avant...

[CTassart]

@oliviermeslin je comprends qu'on ne veuille pas impliquer trop tôt les éléments extérieurs mais je pense que, in fine, il faudra leur proposer d'intégrer ces recommandations dans le cursus INSEE.

[linogaliana]

Le livre Clean code https://www.amazon.fr/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

[avouacr]

Hello,

Dans l'optique d'interventions à l'Ensae sur le sujet au cours de l'année, j'ai rédigé un plan détaillé de ce que j'imaginerais être un guide de bonnes pratiques pour projets de données. Vu que cela recoupe largement ce dont on a discuté dans le cadre de ce thread et de la réunion de vendredi, je le soumets à la discussion communautaire ici, peut être que cela peut servir de base aux suites du brainstorming ?

Le syllabus est construit selon les principes que je proposais dans la discussion (et alimenté à partir des points soulevés par chacun) :

• non centré autour d'un langage particulier, en faisant référence aux standards de chaque langage lorsque cela est pertinent ;
• autour d'une idée d'un continuum de bonnes pratiques, sur lesquelles on se placerait en fonction des ambitions/ressources/contraintes de son projet. Et donc une structure basée sur une progression, aussi bien au fil des sections qu'au sein des sections.

Je suis preneur de tout retour !

[acazaubiel]

Bonjour à tous,

Je trouve généralement que cette conversation reflète mes besoins et ceux de mon équipe. On développe des applications Shiny (c'est la vie) et on doit s'assurer d'avoir une perennité non nulle. Donc présenter les choses comme un continuum de reproductibilité avec un curseur qui dépendra des contraintes est clairement la meilleure chose.

Je suis plus partagé sur cette idée d'avoir une approche multi-langages. Je comprends l'idée, mais je crains que nous aboutissions à quelque chose d'assez théorique in fine, si on ne reste pas "concentré" sur R. Je pense qu'il serait préférable de rester focalisé sur R quitte à dire que les recommandations s'appliquent plus généralement...

Egalement, je reste attaché à cette idée de template sur début de projet. Car le plus dur n'est pas de continuer un projet bien ficelé, mais de commencer un projet du début, et d'avoir une organisation suffisamment rigoureuse mais flexible (car tout n'est pas encore bien formalisé en début de projet).

:)

[jeremylhour]

Hello, je viens de lire ce thread, très intéressant. Je suis d'accord avec la nécessité d'un tel guide et le plan proposé par Romain est top. J'ai récemment relu le "savoir coder" de l'Insee, qui est bien, mais me semble un peu daté, pas assez directif, et avec lequel je suis en désaccord sur certains points (e.g. optimisation de la performance).

Je suis partagé sur la question de laisser le langage libre ou de se restreindre à R. Grosso-modo, j'imagine que de toute façon on ne parle que de python et de R. C'est vrai que se focaliser sur R sera mieux pour la majorité des gens, y compris les débutants. Maintenant, côté SSP Lab, on pousse vraiment pour l'utilisation de python, notamment pour les projets qui sont autre chose que des études. Est-ce qu'on ne peut pourrait pas à chaque fois expliquer la philosophiegénérale, puis spécifier à R et à python au moyen d'encadrés spécifiques ?

Concernant python, j'aime beaucoup de bouquin là : https://nostarch.com/beyond-basic-stuff-python

[linogaliana]

Merci beaucoup pour toutes ces propositions et références qu'il faut qu'on garde en mémoire.

A mon avis, il est assez primordial de ne pas laisser de côté python qui va devenir, dans les années à venir, de plus en plus utilisé en self puis en prod. Dans l'optique de chaînes de prod dont le code risque d'évoluer (maintenance du code existant, nouvelles fonctionnalités...), il est important d'anticiper cela dès la mise en place du projet en proposant une forme de normalisation entre les langages. Cela tombe bien avec python et R (en effet, a priori on partirait que sur ces deux langages) qui partagent la même philosophie et pour lesquels le respect des bonnes pratiques peuvent permettre d'avoir très peu d'éléments spécifiques au langage qui augmentent le coût de la transition d'un langage vers l'autre. Le mouvement général étant à l'intrication de ces deux langages dans des chaînes de prod (cf. investissement important d'RStudio avec reticulate) un guide présentant les deux langages s'accorderait parfaitement avec ça. De plus, une grande partie des éléments de reproductibilité évoqués par @avouacr ne sont pas spécifiques à R.

Quant à la présentation, j'imagine bien un système d'onglet permettant de facilement basculer d'un langage à l'autre. La doc de spark donne un bon exemple de ce que ça donne

[acazaubiel]

Je comprends la philosophie générale, c'est juste que les agents de L'Insee commencent à peine à être opérationnel sous R. Leur présenter un nouveau document dans lequel on présente Python comme l'avenir passera assez mal pour plein de raisons :

• de nombreuses chaînes de production sont encore en SAS, donc on a même pas fini de transiter vers R ;
• le coût fixe de la transition sas vers R n'a pas encore été amorti par des gains d'efficacité ;
• la transition à été (globalement) assez laborieuse, avec beaucoup d'auto-formations et de bricolage ;
• la position officielle de l'institut n'est pas de basculer vers Python, à ma connaissance, donc la légitimité à en faire est plus faible.

Bref, je pense que ce serait une mauvaise idée de mettre les deux langages sur le même plan. R est privilégié politiquement à l'Insee, c'est donc celui qu'il faut mettre en avant, surtout si on cherche à parler à tous les agents. Bon tout ça peut se régler avec les onglets comme dans la doc Spark mais R doit être en first :)

[avouacr]

@acazaubiel

Je pense que personne ici ne suggère de présenter Python comme l'avenir de l'Insee. En tout cas, à titre personnel, ce n'était pas du tout mon intention et je ne trouverais d'ailleurs pas pertinent de donner cette orientation à un éventuel guide des bonnes pratiques à usage SSP. L'enjeu est plutôt, comme cela a été souligné par @jeremylhour et @linogaliana, de tenir compte, sans pour autant se positionner, de plusieurs constats :

• le cocktail des langages enseignés dans les écoles de statistique évolue rapidement, et tend à se biaiser au profit de Python, reflétant un mouvement général de transition vers des formations en data science, souvent centrée sur Python ;
• par conséquent, et aussi dans la perspective des recommandations du rapport DINUM-Insee sur la valorisation des compétences data, il est probable que Python prenne de fait de l'importance dans le SSP dans les années à venir, dans la mesure où il constitue un langage commun à l'ensemble des professions "data" qui sont amenées à se développer, et est également mieux adapté que R à la production ;
• R et Python sont de fait des langages proches, qui partagent la même philosophie, très éloignée de celle de SAS par exemple. Du coup, les bonnes pratiques qui s'appliquent à l'un s'appliquent quasi de manière automatique à l'autre -- modulo quelques subtilités d'implémentation. Je pense qu'il est aussi essentiel de noter que le fait de transitionner de SAS vers des langages comme R et Python n'est pas qu'un choix technique, mais traduit la place croissante prise par le développement et les outils libres dans le métier de statisticien. A ce titre, il me semble qu'un guide des bonnes pratiques doit souligner le changement de culture qui doit s'opérer, en s'inspirant des bonnes pratiques en vigueur dans la communauté des développeurs, qui sont pour la plupart indépendantes du langage de programmation.

Je reste cependant tout à fait d'accord avec toi sur le fait qu'il faut absolument éviter l'écueil de produire un guide trop théorique. Dans tous les cas, le guide pratique de référence pour devenir "opérationnel sous R" resterait clairement utilitR. Il me semble qu'il est un peu vain de vouloir évoquer le sujet des bonnes pratiques trop tôt dans la formation des agents, dans la mesure où il faut avoir suffisamment de pratique du langage pour bien saisir en quoi il est important d'améliorer ses pratiques. Du coup, faire un guide relativement agnostique au langage (tout en mettant R au premier plan des implémentations) ne me semble pas incompatible avec la problématique de former correctement à R des personnes qui n'en ont jamais ou peu fait.

Sinon, +1 pour la présentation onglets en mode doc Spark, et +1 pour les templates de début de projet.

[acazaubiel]

Hehe, ce thread est hyper intéressant (même si je passe pour le vieux relou)! :)

En définitive (et comme souvent par écrit), nos différences sont je pense plus minimes que ce qui nous rassemble. Je veux simplement alerter un point qui me semble important dans la manière de présenter les choses pour les agents de l'Insee.

Si on s'y prend mal, ce guide peut être lu/vu comme une recommandation "en creux" à faire du Python comme on pourrait faire du R. Je pense que cette recommandation ne passera pas auprès des agents de l'Insee, pour toutes les raisons évoquées si dessus.

Je comprends néanmoins tes remarques sur la domination croissante de Python vis-à-vis de R, et c'est un vrai enjeu pour l'institut...

Si vraiment on veut garder du Python dans ce guide, je pense qu'il faut l'amener à travers l'idée que ce guide ne s'applique pas uniquement à l'Insee mais aussi dans le reste du SSP, et au-delà dans la sphère privée.

[loicmidy]

bonjour à tous, les travaux sur les bonnes pratiques peuvent être d'une grande utilité pour les statisticiens/data scientist dans plusieurs contextes de travail. Je réagis sur un contexte particulier, celui d'un programme R qui est un traitement statistique appliqué sur un processus essentiel de l'Insee et concourt donc à la production de statistiques officielles Insee. Je pense qu'il serait souhaitable que ce type de programme soit du "code propre". Dans clean code plusieurs développeurs experts donnent leur avis sur ce qui constitue du "code propre". Bjarne Stroustrup "I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well." Grady Booch "Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control." Dave Thomas "Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone." Michael Feathers "I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you’re led back to where you are, sitting in appreciation of the code someone left for you—code left by someone who cares deeply about the craft." Ron Jeffries "Reduced duplication, high expressiveness, and early building of simple abstractions. That’s what makes clean code for me." Ward Cunningham "You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem."

Il y a beaucoup d'idées dans ces avis de développeurs experts mais si je ne devais en retenir qu'une c'est qu'un code propre est facile à lire, comprendre et modifier. Or si j'ai bien compris certains selfeurs développent des scripts R de plusieurs milliers de lignes sans fonctions (on a alors un gros script monolithique). Pour moi ce type de script n'est clairement pas du code propre. Je retrouve le même avis dans le document savoir compter, savoir coder ("les programmes ne doivent pas être trop longs"). Comment faire pour éviter cela? Dans le document écrit par Romain Avouac https://github.com/avouacr/bonnes_pratiques je lis notamment Modularité : Découpage des scripts en fonctions, Découpage des blocs du projet en modules. Ces éléments me semblent hyper importants. Je me permets de poster sur ce point qui est peut être évident pour vous mais je le fais car je ne l'ai pas vu apparaitre explicitement tel quel dans les discussions.

Cordialement Loïc

[jeremylhour]

Hello, en parlant de bonnes pratiques pour les projets, je viens de tomber là dessus : https://github.com/quantumblacklabs/kedro . Je n'ai pas eu l'occasion de tester, mais cela semble intéressant, et en lien avec ce sujet.

[linogaliana]

Merci @jeremylhour pour kedro ça a l'air exactement ce que je cherchais comme librairie pour un de mes projets.

Ca pourrait être le contrepoint Python de targets (R) si ça marche bien (à tester)

[MaelTheuliere]

Hello, très intéressant ces échanges. Histoire d'alimenter la biblio, je vous transmets le lien vers les guides qui compilent les bonnes pratiques identifiées dans le cadre de la démarche propre :

• la théorie : https://rdes_dreal.gitlab.io/propre/index.html
• la pratique : https://rdes_dreal.gitlab.io/publication_guide/

[ddotta]

Hello, discussion très intéressante merci beaucoup !
J'ai simplement une remarque technique à faire sur la proposition d'onglets que je trouverais très pratique en effet pour basculer entre les langages.

Quant à la présentation, j'imagine bien un système d'onglet permettant de facilement basculer d'un langage à l'autre. La doc de spark donne un bon exemple de ce que ça donne

J'avais fait quelques tests sur un autre projet et je m'étais rendu compte que la technique des {.tabset} expliquée ici ne fonctionnait pas avec un bs4_book comme utilisé dans utilitr

Et autre question : même en cas de contournement très probable de ce problème par les brillants mainteneurs de ce dépôt, je me pose la question de l'articulation de ces onglets avec utilitr::html_paged issue de {pagedown}.
Comment cela pourra être gérer lorsqu'un lecteur voudra imprimer la fiche sur les bonnes pratiques ? (s'il veut que l'impression pdf contienne le code R ou python)

[linogaliana]

Salut @ddotta ce sont de bonnes questions !

Pour les onglets sur le site web, je m'inquiète pas trop je pense qu'on peut trouver une implémentation, peut-être à base de fenced divs pandoc. Je l'ai fait en blogdown pour mon cours python (ici) en m'insipirant du shortcode hugo du thème Hugo Apero (exemple pour le cours de 3A qu'on fait avec @avouacr ici). Côté gouvdown vous avez testé @MaelTheuliere ?

En ce qui concerne le print il y a une petite stratégie à adopter. J'ai l'intuition que pour le print, transformer le panelset en encadré avec des parties correspondant aux onglets serait pas mal (je me dis que pour le print, pour le coup, on met les deux langages). On pourra ouvrir une issue spécifiquement sur cette technique quand on tentera ce système d'onglets

[linogaliana]

@jeremylhour j'ai un peu étudié la question des pipelines côté python. kedro n'est toujours pas passé à une version récente de python donc ça me paraît compliqué de le recommander en alternative de targets.

En revanche, j'ai commencé à pas mal utiliser snakemake, c'est vraiment pas mal. Cela fait écho à une discussion qu'on avait eu sur grrr avec @juba. snakemake est moins intuitif à la prise en main que targets mais ça fonctionne bien (je vais essayer à terme d'ajouter un tuto snakemake dans mon cours python).

[ddotta]

Un article de blog écrit cette semaine sur le sujet qui contient des liens intéressants sur le sujet de cette issue (dont certains ont déjà été évoqués)

[linogaliana]

je ferme puisque maintenant on a la formation bonnes pratiques + des chaptires utilitr consacrés