Introduction
Léonard de Vinci a dit une fois : "La simplicité est la sophistication suprême". Ce qu'il était loin de savoir à ce moment-là, ce qu'il venait de décrire en quelques mots ce qui fait la force du langage Python.
Python est de plus en plus populaire comme langage de programmation. Et en effet, sa simplicité syntaxique y est pour beaucoup. Il permet donc de se concentrer sur l'essentiel : le problème qu'on veut résoudre. Ce n'est pas un hasard s'il est utilisé dans beaucoup de logiciels du quotidien : Instagram, Spotify, Dropbox, Pinterest ou même encore Uber. La communauté data et machine learning l'affectionnent également beaucoup.
Toutefois, cette simplicité a un prix. Et ce prix, c'est qu'il y a très peu de choses qui nous empêchent d'écrire du code d'une qualité tellement mauvaise que des crevettes pas fraîches à côté, c'est un médicament pour les problèmes de digestion. Oui oui, ça peut aller très loin, très vite, pied au plancher avec Python !
Mais il y a aussi une bonne nouvelle : cette même simplicité, qui fait la force de Python, est aussi la raison pour laquelle on peut écrire du code de très bonne qualité. Et on n'est pas sur du léger, léger. On parle là d'un code d'une incroyable flexibilité, d'une excellente maintenabilité et le tout avec une grande expérience de lecture. En tant que crafters, vous savez à quel point cela a de la valeur 🙂
Il y a donc deux côtés diamétralement opposés du spectre. Mais il ne faut pas croire. La plupart du temps, les développeurs ne tombent pas dans ces travers par mauvaises intentions. Dans cette série d'articles, nous allons donc voir des manières d'aller plus loin que de la bidouille avec Python. Nous allons voir comment faire du Python de qualité en évitant les écueils récurrents. Mais avant ça, commençons par définir ce que c'est "bidouiller".
C’est quoi bidouiller ?
Bidouiller, c'est écrire du code avec pour seul objectif de le faire marcher, sans considération pour le futur, sans considération pour une meilleure approche et même sans considération pour le fait que d'autres personnes liront ce code.
En soit, ce n'est pas nécessairement une mauvaise chose de bidouiller. Tout est une question de contexte. Notablement, lorsqu'on est dans une dynamique d'exploration ou d'expérimentation, on apprend même beaucoup de choses en bidouillant. De même, il peut arriver qu'on ait besoin de produire en urgence un script qu'on ne réutilisara plus. Dans ces cas là, bidouiller n'a presque pas de conséquences et peut même avoir des avantages.
Par contre, ce n'est pas la même histoire pour du code Python d'un projet qui a vocation à être maintenu sur la durée. Là ce n'est plus du code jetable. Dans cette situation, il devient primordiale de ne pas bidouiller. Et les raisons sont nombreuses :
1. Maintenance du code plus difficile
Le code bidouillé est généralement le résultat d'un ensemble de "mauvaises" décisions en apparence innocentes. Ça peut être par exemple qu'on décide de donner un nom pas très explicite ou ambigu à une variable. Ensuite, le lendemain, on met 15 minutes à comprendre ce qu'elle contient alors que le code est de nous. Pire encore deux semaines plus tard au moment où, disons, un bug s'est produit en production.
Du code bidouillé a tendance à être difficile à lire. Lorsque le code est dans cet état, on n'a plus de mal à corriger des bugs ou à faire des évolutions. Et plus il est comme ça, plus on passe de temps à essayer de le déchiffrer, et moins à résoudre le problème en cours (bug, évolution, analyse, etc.).
Mine de rien, nous autres développeurs passont beaucoup de temps à lire du code. Qu'on travaille en solo ou qu'on collabore avec d'autres développeurs. Alors autant que ce soit fluide 🙂
D'ailleurs, puisqu'on parle de collaboration ...
2. Bidouiller empoisonne la collaboration
Comme mentionné plus haut, il est souvent difficile de se retrouver dans du code bidouillé. Y compris quand nous en sommes l'auteur. Alors naturellement, pour une autre personne, ce n'est pas une sortie à Disneyland.
C'est d'autant plus compliqué si l'auteur original du code n'est pas là pour nous l'expliquer. Et même s'il était là, dans certains cas, il est aussi perdu que nous ^^.
La bidouille a par conséquent tendance à entamer la collaboration sur une base de code et à ralentir de près ou de loin le cycle de développement. D'ailleurs, puisqu'on parle de lenteur ...
3. Problèmes de performance
Parfois, l'exécution d'un code ça prend du temps. La raison vient parfois juste de la nature du traitement (ex. un traitement en batch d'une grosse quantité de données). Les Data Scientist et les ML Engineer par exemple rencontrent ou écrivent beaucoup de code de cette nature.
Cependant, le code peut aussi prendre plus de temps qu'il ne devrait selon la manière dont nous l'avons implémenté (utilisation à outrances de boucles for, utilisation excessive de conditions, etc.). C'est pourquoi en Python, comme dans beaucoup d'autres langages, il existe des recommandations pour écrire du code plus efficace.
Lorsqu'on bidouille, on a tendance à ne pas refactorer son code, sinon très peu. De ce fait, on s'expose à laisser trainer des goulots d'étranglement ça et là dans la base de code qui finissent par ralentir l'exécution du code de manière considérable.
4. Introduction de failles de sécurité
En bidouillant, il arrive également qu'on prenne des décisions qui mènent directement vers des failles de sécurité. La bonne nouvelle cela dit, c'est qu'il existe des outils pour scanner le code Python et nous prévenir des failles de sécurité connus. Ce qu'on appelle des outils de Static Application Security Testing (abrégé SAST).
Comme librairie de SAST en Python, on pourrait notamment citer bandit.
5. Cercle vicieux
Une première personne introduit des négligences dans le code, puis le passe à la prochaine personne. La prochaine personne voit qu'il y a déjà quelques négligences dans le code et se dit : "Oh c'est pas grave si je fais pareil". Tour à tour, les négligences appellent d'autres négligences. Et puis un jour, la base de code ressemble à un plat de spaghetti carbonara resté trop longtemps dans le frigo. Nous avons là un bel exemple de la théorie de la vitre cassée dans toute sa majesté.
Qui plus est, la nature simple de Python fait que la situation escalade très rapidement. Au final, on se retrouve avec un code difficile à maintenir et qui nous fait peur même. Qui nous fait tellement peur qu'on ose même plus prononcer son nom. D'ailleurs, en ce moment, rien qu'en vous en parlant, je n'arrive pas à m'empêcher de trembler. C'est dire à quel point c'est traumatisant 👀
Vous savez quoi, passons tout de suite à la prochaine partie. Ça fait trop peur ici !
Alternatives à la bidouille
C'est bien beau de soulever des problèmes. C'est encore mieux de proposer des solutions.
La liberté qu'offre Python et le fait qu'il soit souvent perçu comme un simple langage de scripting fait que bidouiller avec ce langage est très tentant. Mais bidouiller avec Python sur un projet qui s'inscrit dans la durée, c'est gâcher son potentiel.
Le code Python peut devenir un allié de choix dans le processus de développement. Pour cela, il faut lui accorder l'attention qu'il mérite en donnant un ton plus professionnel à son code Python. Python confère de grands pouvoirs et de grandes possibilités, mais à condition d'être bien encadré. Après tout comme disait tonton Ben : "De grands pouvoirs impliquent de grandes responsabilités".
Dans les prochains épisodes de cette série d'articles, nous allons parler de différentes pratiques qui permettent de faire du Python sans bidouiller.
Restez à l'écoute et rendez-vous dans le prochain épisode 😉
Aller plus loin
https://towardsdatascience.com/18-common-python-anti-patterns-i-wish-i-had-known-before-44d983805f0f
