Data science et développement informatique sont deux domaines très proches l’un de l’autre. En particulier, la data emprunte beaucoup au développement, qu’il est utile de maîtriser pour être un spécialiste data accompli.
En effet, plusieurs logiciels permettant de faire de l’analyse de données via une interface graphique existent et se sont développés ces dernières années (par exemple, DataIku). Malgré tout, on n’échappe jamais à la nécessité de mettre les mains dans le cambouis (comprendre : écrire du code) lorsqu’on fait de la data.
Pour ces raisons, devenir un bon data scientist nécessite aussi de savoir coder correctement. Ce n’est pas une coïncidence si le DataOps s’inspire du DevOps : de nombreux principes et règles valides en développement informatique sont aussi valides en data.
Dans cet article, nous allons donc nous intéresser à quelques règles à respecter pour écrire du code de qualité lorsqu’on est data scientist.
Pourquoi écrire du code propre ?
Après tout, la question est légitime : est-ce vraiment nécessaire de mettre de l’énergie et de l’effort dans son code ? Ou bien serait-ce faire du zèle ?
Il existe plusieurs raisons valables pour s’appliquer lorsqu’on développe, notamment :
- la collaboration : produire un codage lisible est la meilleure manière de rendre vos collègues développeurs heureux (l’inverse est vrai aussi). En effet, c’est compliqué de comprendre un code bien écrit et bien documenté, alors si en plus il est mal écrit, sans commentaires (ou pire, avec des commentaires erronés) et mal agencé, ça devient impossible. C’est mieux pour vos collègues, mais aussi pour vous-même, dans un mois, lorsque vous aurez oublié votre travail.
- un code testable : mettre en place des tests (unitaires ou d’intégrations) est un « must-have » en développement informatique. Or, un code mal agencé est souvent difficile à tester. À l’inverse, l’écriture des tests est évidente et presque naturelle lorsque le code à tester est bien structuré.
- réutilisation : pouvoir réutiliser du code existant permet de gagner un temps considérable et c’est plus facile à faire lorsque le code en question a été documenté, clairement écrit et testé.
- limiter l’accumulation de dette technique : la dette technique est un concept fort en développement informatique. Il est souvent sous-estimé par le management, qui s’intéresse surtout aux résultats, alors que deux solutions techniques produisant le même résultat ne sont pas forcément égales. La dette technique désigne l’accumulation progressive de mauvais choix techniques subsistant dans du code (dû à une précipitation ou à un besoin qui a évolué). Cette dette entraîne des bugs, des surcoûts de maintenance et des frictions importantes pour faire évoluer le logiciel.
Bien sûr, il ne faut pas tomber dans le piège inverse et essayer de coder parfaitement, car cela n’existe pas. N’importe quel développeur regardant son code vieux de 6 mois trouvera des défauts à son travail.
Quelques conseils pour produire du code de meilleure qualité
Une certaine part de subjectivité entre dans l’évaluation de code informatique. Cependant, certaines règles mettent tout le monde d’accord (ou presque, mais vous n’aurez rien à vous reprocher au moins !).
Quelques principes à appliquer :
- DRY, de l’anglais « don’t repeat yourself », à savoir, éviter d’écrire deux fois le même bout de code. Si cela survient, sûrement, ce code doit être encapsulé dans une fonction et si c’est fréquent, la structure générale de votre code pourrait être à revoir.
- une fonction = une opération : notamment pour rendre votre code testable et offrir une bonne lisibilité, évitez les fonctions réalisant plusieurs opérations logiques différentes.
- maximiser la cohésion : la cohésion d’un code caractérise la pertinence des regroupements opérés via différentes abstractions. Ainsi, un fichier ne doit contenir que des entités (fonction ou classes) qui partagent un lien commun ; une classe ne doit contenir que des méthodes qui font usage des attributs de cette classe ; une fonction ne doit contenir que des instructions nécessaires à une opération logique donnée. En d’autres termes, chaque regroupement doit avoir une motivation logique forte.
- minimiser la dépendance : allant de pair avec la cohérence, la dépendance mesure les liens existants entre différents éléments dans votre code. Ainsi, si vous changez l’attribut d’une classe, il est normal que cela impacte une méthode de cette classe. En revanche, si cela entraîne aussi des modifications dans d’autres entités, ou pire, dans d’autres fichiers, ce n’est pas un très bon signe et vous avez sûrement un problème de dépendance.
- respecter les conventions : les langages possèdent leurs conventions (PEP8 pour Python, par exemple), c’est essentiel pour une bonne collaboration.
Après ces bonnes pratiques, voici des choses à éviter :
- les abstractions prématurées : notamment en phase de développement, il est souvent préférable de garder un « pavé de code » intact plutôt que de créer des abstractions (fonctions, classes…) dont la pertinence n’est pas sûre à 100 %. En effet, il est plus coûteux de défaire des abstractions devenues inutiles que de gérer un bloc de code trop long. En d’autres termes, ne créez des abstractions que quand c’est vraiment nécessaire.
- le « sur-design » : évitez de vous projeter trop loin lors d’une phase de design, car il est impossible de prévoir les problèmes avant qu’ils ne surviennent. Préférez plutôt faire des petites itérations et avancer à tâtons, tout en prenant le temps d’écrire du code clair, propre et commenté pour ne pas accumuler trop de dette technique.
- les dépendances accessoires : certes, réutiliser du code permet de gagner du temps, mais cela crée de la dépendance entre différents projets. Prenez le temps de peser le gain de temps par rapport aux ennuis potentiels liés à une dépendance supplémentaire.
- les états globaux : un code dont le comportement dépend de paramètres globaux (l’heure de la journée, par exemple) est plus difficile à tester et à débugger.
En tant que spécialiste data, on n’attendra pas de vous que vous soyez capable de développer des logiciels complexes, votre valeur ajoutée est ailleurs. Mais négliger la qualité du code écrit aura un impact négatif fort lorsqu’il faudra passer de la phase prototype à la phase production d’un projet data. Donc prenez le temps de vous renseigner sur les conventions et les bonnes pratiques relatives au langage que vous utilisez.
