Pourquoi lire le code des autres, fera de toi un meilleur développeur ?

Beaucoup de développeurs ne prennent pas le temps d’aller lire le code source des librairies ou frameworks qu’ils utilisent, pensant souvent à tort que cela est une perte de temps. Pourtant apprendre à lire du code que l’on n’a pas écrit fait partie intégrante de notre métier et prendre cette habitude peut faire de vous un meilleur développeur.

Pourquoi lire du code source ?

Depuis de nombreuses années, j’ai pris l’habitude d’aller lire, autant que je peux, le code source des librairies et frameworks que j’utilise. J’ai eu de nombreuses discussions avec d’autres développeurs et peu d’entre eux le font. Quand je leur demande les raisons pour lesquelles ils ne le font pas, les réponses sont souvent celles-ci :

  • “C’est une perte de temps” ;
  • “La documentation est déjà assez claire pourquoi aller lire le code source ?” ;
  • “C’est trop compliqué je n’y comprends rien”.

Pourtant je vais vous montrer dans cet article que lire du code source présente de nombreux avantages, que c’est loin d’être une perte de temps et qu’il n’est pas si compliqué que ça de le faire.

Apprendre des autres

Les librairies ou frameworks les plus populaires sont souvent écrits par des développeurs plus expérimentés que vous. Le code a été passé en revue par des dizaines voir des centaines, si ce n’est des milliers d’autres développeurs, celui-ci est donc souvent de qualité. Lire ce code source vous permet de voir et donc d’apprendre certaines bonnes pratiques pour écrire du code propre, apprendre à mieux architecturer votre code ou encore voir en application certains algorithmes.

La lecture du code source permet également de voir des exemples concrets de certains concepts du langage que l’on retrouve rarement dans les tutoriels qui sont juste là pour vous expliquer les concepts sans réellement présenter d’exemple de la vie de tous les jours.

Un autre point que je trouve enrichissant c’est que vous allez voir différentes façons d’écrire du code, chaque personne possède sa propre manière d’écrire du code. Je compare souvent le développement à un art, chaque développeur est un artiste avec sa propre patte artistique. Cette diversité peut vous ouvrir l’esprit sur le fait qu’il n’existe pas qu’une seule façon d’écrire du code ou de résoudre des problèmes et heureusement sinon on s’ennuierait !

Démystifier le fonctionnement

Pour beaucoup, la documentation est suffisante et il n’est pas nécessaire de comprendre le fonctionnement interne d’une librairie. Et ils n’ont pas forcément tort, sauf que pour certains développeurs le fonctionnement d’une librairie s’apparente à de la magie, certains perdent même leur moyen et paniquent en utilisant des librairies qui paraissent complexes. Lire leurs codes source, va démystifier leurs fonctionnements et vous permettre souvent une meilleure utilisation de celles-ci.

Parfois, certaines documentations ne sont pas assez claires et on ne comprend pas pourquoi cela ne fonctionne pas. Un simple coup d’œil au code source suffit souvent à avoir une réponse et nous évite de perdre du temps à aller chercher celle-ci sur internet.

Il arrive même que la documentation, nous invite à aller voir le code source de certaines librairies pour avoir des exemples concrets. C’est notamment le cas de Fastify, pour l’écriture de plugin.

Bref, arrêtez d’avoir peur du fonctionnement et soyez curieux, après tout ce n’est que du code, apprenez à le dompter et vous finirez par avoir une expertise avec la librairie ou le framework en question.

Vérifier la qualité du code

La présence d’une librairie sur un dépôt ne signifie pas que celle-ci est de qualité. Il n’est pas rare de tomber sur certaines librairies avec un code totalement dégueulasse. Lire le code source est alors primordial pour s’assurer de sa qualité.

Prendre confiance en soi

Qui n’a jamais paniqué en débarquant sur un projet avec une énorme codebase. Cela peut être déconcertant et vous faire douter de vos capacités. Par contre, si vous avez l’habitude de lire du code source qui ne vous appartient pas, vous saurez comment vous y prendre avec n’importe quel code source.

Sans vous en rendre compte, avoir cette habitude de lire du code source va vous faire sortir régulièrement de votre zone de confort, élargir celle-ci et indirectement vous permettre de prendre confiance en vous. Vous allez être de plus en plus à l’aise avec le code et comme je l’ai dit tout à l’heure vous allez démystifier son fonctionnement. En gros, plus rien ou presque ne va vous faire peur et vous n’aurez aucun mal à appréhender les différents projets sur lesquels vous serez amené à travailler.

Devenir plus efficace pour déboguer

La lecture d’un code source n’est jamais linéaire, nous passons de fonction en fonction, nous revenons en arrière, parfois on se perd même. Pour les petites librairies, souvent la compréhension du code est assez simple (mais pas toujours !), mais quand on s’attaque à des plus grosses, cela ressemble souvent à un jeu de piste ou à une enquête.

Que le code soit bien écrit ou pas vous avez toujours cette phase de compréhension et plus vous allez lire de codes sources plus cette phase sera rapide. Vous aurez acquis certains automatismes pour analyser le code, savoir où chercher, etc. Bref, ça ne vous rappelle rien ? Quand vous déboguez du code, vous faites exactement la même chose ! Lire du code source régulièrement et le comprendre va augmenter votre efficacité dans le débogage.

Par où commencer ?

Si vous êtes développeur JavaScript, je vous conseille de lire le code source de lodash qui est assez simple à comprendre. Pour cela, il suffit de vous rendre sur son dépôt Github, et de choisir le code source d’une fonction. Par exemple, voyons voir le fichier filter.js qui contient la fonction du même nom permettant de retourner uniquement les éléments d’une collection vérifiant un prédicat :

Vous voyez ce n’est vraiment pas compliqué ! J’aime bien lodash comme premier code source à parcourir, car les exemples sont simples et la documentation du code via jsDoc est vraiment top, vous pourrez donc vous en inspirer quand vous documenterez votre code.

Pour commencer, vous pouvez également regarder le code source d’une petite librairie que vous connaissez bien. Si vous maîtrisez le langage, rien ne vous empêche d’aller directement voir le code source d’un framework, mais si vous êtes débutant je vous le déconseille, vous allez juste vous décourager.

N’ayez pas peur de ne rien comprendre au début, c’est tout à fait normal, déculpabilisez et avancez à votre rythme. Commencez par des fonctions simples ou d’un niveau d’abstraction plus élevé avant de plonger plus en profondeur dans les entrailles du code.

Et pourquoi pas contribuer ?

Il arrive parfois lors de la lecture du code source que vous tombiez sur certaines erreurs que ce soit des bugs ou encore des fautes d’orthographe. N’hésitez donc surtout pas à ouvrir une issue sur le dépôt Github du projet.

Si vous souhaitez corriger vous-même ces erreurs ou même proposer de nouvelles fonctionnalités, je vous conseille ce guide pour apprendre à contribuer à un projet.

Pour finir…

La lecture de code source fait partie des compétences essentielles pour un développeur et présentes de nombreux avantages dont une partie que l’on a vue dans cet article. On  peut faire le parallèle avec la lecture de livres. Plus vous lisez de livres, plus vous enrichissez votre vocabulaire parfois même sans vous en rendre compte, c’est pareil pour la lecture de code source, plus vous allez lire du code plus vous allez enrichir vos connaissances. Je terminerai cet article avec cette citation :

Si vous n’avez pas le temps de lire, vous n’avez pas le temps (ou les outils) pour écrire. C’est aussi simple que cela.

Stephen King


Annonces partenaire

Je suis lead developer dans une boîte spécialisée dans l'univers du streaming/gaming, et en parallèle, je m'éclate en tant que freelance. Passionné par l'écosystème JavaScript, je suis un inconditionnel de Node.js depuis 2011. J'adore échanger sur les nouvelles tendances et partager mon expérience avec les autres développeurs. Si vous avez envie de papoter, n'hésitez pas à me retrouver sur Twitter, m'envoyer un petit email ou même laisser un commentaire.

6 commentaires

  1. Bonjour,

    Il y a plus de 20 ans, j’ai pratiqué de la sorte pour la maîtrise du Shell que j’ai actuellement.
    Et ce fut pareil pour l’orthographe.
    Puis-je apporter ces quelques petites corrections:
    “tutoriels qui sont juste là pour”
    “N’ayez pas peur de ne rien comprendre au début, c’est tout à fait normal, déculpabilisEZ et avancEZ à votre rythme”
    “Plus vous lisez de livres, plus vous enrichissez Votre vocabulaire”
    “Je terminerai cet article avec cette citation”

    Cela n’a pas nuit au plaisir que j’ai eu à vous lire.

    Cordialement

    1. Je sens un léger petit tacle avec cette phrase “Et ce fut pareil pour l’orthographe” mais c’est bien mérité :D. Merci pour le commentaire et les corrections !

  2. Super article ! Et je suis passé après LeDub donc mes yeux sont restés intacts xD
    La citation de King est juste parfaite !
    Merci pour cette lecture du matin

  3. Hello ! Je viens d’arriver sur ton blog via ton Twitter et via Alex Soyes. Super intéressant merci!
    Je me forme et dans les prochaines étapes de ma formation j’avais notamment envisagé de « lire du code ». Comme c’est le genre de truc que je pourrais facilement procrastiner (je me connais) pourrais-tu me recommander sur Github des premiers codes « faciles » à lire sur Node ou TS?
    Ça m’aiderait à me lancer! Merci!

    1. Hello ! Si tu débutes je te conseille de commencer par Lodash (https://github.com/lodash/lodash) comme je l’ai dit dans l’article. Après je n’ai pas forcément de dépôt avec du code “facile” à lire soit curieux et regarde les libs que tu utilises au quotidien. Le fait de comprendre comment fonctionne telle ou telle lib t’aideras à progresser 😉

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.