Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage, je m'appelle Nicolas
Brandenvernard et aujourd'hui on va parler de l'impact des logs en production.
Alors la console elle est souvent utilisée pendant le développement pour vérifier que
les différentes étapes d'un code fonctionnent correctement. Mais la question qu'on va se poser
aujourd'hui c'est est ce que ces logs peuvent avoir un réel impact sur les performances ou la
sécurité de votre code en production. Alors évidemment avant d'entrer dans le livre du
sujet il faut se rappeler que la meilleure méthode pour effectuer ça c'est plutôt d'utiliser un
debugger intégré à votre IDE plutôt que de coller des logs absolument partout dans votre code.
On va commencer par l'impact en termes de performance. Si effectivement les logs ont un
impact vraiment minimum quand ils sont exécutés un par un, les logs en production peuvent avoir
un impact très conséquent sur les performances de votre code notamment quand ils sont présents
dans une boucle ou dans un morceau de code qui est très fréquemment appelé par vos utilisateurs.
Pour simuler cette perte de performance j'ai même été jusqu'à créer un script pour faire un petit
benchmark très très simple qui consistait simplement en un une boucle de 1000 iterations et j'ai fait
une version sans log et j'ai mesuré le temps entre le début de la boucle et la fin de la boucle et
une version avec log où j'ai fait la même chose. Le log concitait simplement à afficher le numéro
du tour de boucle qui était qui était en train de se faire. Les résultats et bien ils sont vraiment
probants parce que j'ai exécuté ce script sur trois environnements différents dont deux sur des
machines carrément différentes alors les trois environnements c'était d'abord sous Firefox sur
un pc portable le deuxième environnement c'était sur Node.js cette fois ci avec le même ordinateur
portable et je l'ai fait également sur Node.js avec un vps ovh et donc là les temps et bien
sont vraiment flagrants puisque selon l'environnement le simple log qui est enfermé dans une boucle
et bien multiplie par neuf le temps d'exécution de notre code c'est énorme donc imaginez si ce log
est présent dans une boucle qui est appelé dans une partie très demandée d'une de vos API la perte
est considérable et peut devenir un vrai goulot d'étranglement selon votre charge utilisateur.
Alors maintenant on va parler de l'impact en termes de sécurité évidemment logger des chaînes
de caractère comme test coucou et j'en passe ça n'a pas vraiment d'impact sur la sécurité de
votre application mais maintenant on va imaginer un petit scénario disons que derrière votre API
vous utilisez une base de données chiffrée parce que les données de vos utilisateurs ne doivent
être en aucun cas consultables par quelqu'un d'autre autre que la personne elle-même et maintenant
imaginons que pour débuguer une partie du code vous ajoutiez simplement un petit console log user
et que ce console log part en production. Et bien les données des utilisateurs qui vont utiliser
votre API finiront du coup en clair dans les fichiers de log sur le serveur de production ça c'est
vraiment une cible de choix pour un pirate évidemment mais également simplement ce fichier il
devient consultable par n'importe quel membre de l'équipe de développement ce qui était vraiment
l'inverse qui était voulu puisqu'on avait carrément une base de données chiffrée à l'origine on
perd tout le principe donc il faut vraiment garder en tête que les consoles log c'est pas
simplement quelque chose qui vaut mieux ôter parce que voilà ça fait un code plus clean etc
quand ça part en production non il y a vraiment des impacts en termes de performance mais également
en termes de sécurité qui peuvent venir. Alors pour pas lier à ce problème il existe
énormément de solutions là je vais vous présenter des solutions qui sont plutôt axées javascript
mais pour n'importe quelle langage ça existe forcément. Vous pouvez évidemment déjà choisir
de ne gérer que certains niveaux de log sur vos serveurs de production. Vous pouvez choisir d'avoir
toutes les infos ce qui n'est pas recommandé mais vous pouvez utiliser uniquement les warnings
ou les erreurs. Donc ça appartient normalement les warnings ou les erreurs c'est des choses vraiment
qui vont être utiles pour le coup pour le débugage en production s'il y a besoin mais les infos elles
ne devraient pas l'être en tout cas. La première solution c'est d'utiliser quelque chose comme
ESLint par exemple donc qui est un linter ce qui signifie qu'il va parcourir votre code pour détecter
si certaines pratiques vont à l'encontre de sa configuration. Vous pouvez ajouter la règle
no console par exemple avec ESLint je vous mettrai le lien de la documentation dans les notes de l'épisode
pour être averti si un console log a été oublié. Vous pouvez évidemment faire ça par exemple sur
votre pipeline de CI CD juste avant la production et pas forcément avoir ces warnings dès que
vous exécutez votre linter en local. La deuxième solution c'est d'utiliser un transpiler. Alors
en transpiler on connaît Babel et il y en a d'autres. C'est lui qui va prendre votre code pour le
compiler de manière transversale d'une version d'un langage à un autre et il appliquer des
modifications que vous aurez déterminée. Et il y a des plugins par exemple. Là pour Babel entre guillemets
ce qui est par exemple transform remove console pareil je vous mettrai le lien dans les notes
de l'épisode. Avec ça Babel supprime automatiquement tous les appels console log lors de la transpilation
donc c'est complètement automatique. Alors après vous avez aussi une solution qui là marche plus
tôt pour du séchar ou du javadage comme ça vous avez des flags et donc ça va grâce à ces flags
de compilation vous allez carrément pouvoir supprimer ou du moins éliminer une ligne de code
en disant là si jamais mon flag de compilation c'est pour une compilation en release et bien
je veux que toutes ces lignes de code là soient éliminées. Si jamais vous avez des lignes de debug
des lignes de console log qui sont utilisées quand même simplement même dans votre workflow de
dev vous pouvez les laisser mais les exclure complètement du binaire compilé quand c'est
compilé en release. Donc ça c'est pareil c'est très très utile. En conclusion évidemment je vous
conseillerais de privilégier des configurations de votre projet que ce soit d'un linter,
d'un transpiler ou peu importe mais pour éviter au maximum que vos consoles log partent en
production parce que même si jamais vous mettez vous, vous mettez un point d'honneur à ne pas
utiliser de console log le jour où ça vous arrive vous arrive un collègue ou peu importe et qu'il
y a un ajout sans faire exprès si jamais vous n'avez pas de garde-fous pour ces choses là et
ça peut quand même partir en production donc voilà ça serait quand même dommage de tomber dans
le panneau alors qu'il y a beaucoup de solutions pour se faciliter la tâche. J'espère que cet
épisode vous aurait été utile que vous aurez appris un petit peu plus de choses notamment
autour des logs moi sur ce je vous donne rendez-vous la semaine prochaine pour un prochain épisode
du podcast ou directement sur code-garrache.fr pour retrouver tous nos articles nos épisodes
de podcast et évidemment toutes nos formations pour continuer à vous former et monter en compétence
dans votre carrière. Salut !