Article original : What I Learned from Reading "The Pragmatic Programmer"
Par Pramono Winata
En bref : vieux mais en or.
Publié en 1999, The Pragmatic Programmer est un livre sur la façon de devenir un Pragmatic Programmer. Ce qui signifie vraiment un 'Bon Programmeur'.
Oui, il a été publié il y a environ 20 ans. Mais ce livre offre encore de nombreuses perspectives très pertinentes pour les programmeurs ou les ingénieurs logiciels, comme certains pourraient les appeler de nos jours.
Vous avez peut-être déjà entendu parler de ce livre et vous êtes demandé de quoi il s'agissait réellement. Eh bien, aujourd'hui, je vais partager avec vous certaines des choses intéressantes que j'ai apprises en lisant le livre.
Il y a plus à être programmeur que des compétences techniques
_Photo par [Unsplash](https://unsplash.com/@alexkixa?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Alexandre Debiève / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)
En lisant le titre du livre, vous pourriez vous attendre à ce qu'il donne beaucoup de leçons techniques. Mais en fait, ce n'est pas le cas. Ce qui rend ce livre toujours pertinent 20 ans plus tard, c'est qu'il nous enseigne qu'être programmeur ne se résume pas à la force technique. Et nous oublions souvent ce fait.
Le livre nous enseigne qu'il y a plus à la programmation que les capacités techniques.
Le chat a mangé mon code source
_Photo par [Unsplash](https://unsplash.com/@chen93?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Chen Zhao / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)
C'est le premier chapitre du livre et c'est un concept très intéressant.
Vous souvenez-vous de ce jour où nous n'avons pas fini nos devoirs et où nous avons dit que le chien les avait mangés ? (En fait, je ne m'en souviens pas, car je finissais toujours mes devoirs ?)
Ce que cela - et ce chapitre - nous enseigne, c'est en fait la responsabilité. Lorsque vous avez la responsabilité de quelque chose, vous devez être prêt à en être tenu responsable.
Si vous faites des erreurs et ne pouvez pas remplir ces responsabilités, vous devez vous rattraper et trouver une solution. Ne faites pas d'excuses et ne jouez pas au jeu du renvoi de responsabilité. Vous ne pouvez pas simplement aller au travail et dire à tout le monde qu'un chat vient de manger votre code source.
Proposez des options, ne faites pas de mauvaises excuses.
C'est tout une question de fenêtre brisée
_Photo par [Unsplash](https://unsplash.com/@pawel_czerwinski?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Paweł Czerwiński / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)
Dans le livre, il y a une histoire sur une zone urbaine qui est devenue très désordonnée et délabrée, tout cela à cause d'une fenêtre brisée.
Cela ressemble beaucoup à notre code : lorsque nous voyons du code sale (que nous pouvons voir comme une fenêtre brisée), nous pourrions commencer à penser qu'il est acceptable de laisser le code sale. Qu'il est acceptable de simplement revenir plus tard, ce que nous ne faisons jamais la plupart du temps.
Essayez de ne pas laisser les "fenêtres brisées" non réparées. Lorsque vous trouvez ce genre de code, corrigez-le dès que possible. Lorsque vous continuez à penser que personne n'a le temps de corriger ce code brisé, vous feriez mieux d'aller acheter une benne à ordures juste pour garder votre code.
Ce que ce chapitre discute est en fait simple : il s'agit de l'initiative et de prendre soin de vos affaires.
Prenez l'initiative, soyez le catalyseur
_Photo par [Unsplash](https://unsplash.com/@bradencollum?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Braden Collum / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)
Il peut aussi y avoir des moments où vous savez que soit tout va bien, soit quelque chose doit vraiment être fait. Cela vous vient à l'esprit et vous pensez simplement que c'est la bonne chose à faire.
Si vous continuez à simplement penser, rien ne se passera. Ou si vous demandez simplement à ce que cela soit sur la chronologie du projet, vous pourriez être confronté à de grandes demandes de développement de fonctionnalités et à une dette technique. Donc, cela se termine en une autre année de discussion.
Il est temps d'élever votre jeu. Travaillez sur ce que vous pouvez, ne faites pas trop, mais rendez-le également raisonnable. Une fois que vous avez votre idée complète, montrez-la aux gens. Ils pourraient penser que "Oui, ce serait mieux si nous avions cela."
Montrez-leur un aperçu de l'avenir et les gens se rassembleront autour de vous. Soyez un catalyseur pour le changement.
De plus, ce livre nous enseigne également les bases fondamentales que nous oublions souvent en tant que programmeurs.
Parfois, plus nous nous plongeons profondément dans notre travail, plus nous oublions souvent les choses de base que nous avons apprises il y a longtemps.
Occupés à poursuivre des fonctionnalités et des améliorations technologiques, nous oublions souvent qu'il y a en fait beaucoup plus de choses auxquelles nous devons prêter attention avant d'aller plus loin.
Code propre
_Photo par [Unsplash](https://unsplash.com/@4themorningshoot?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Oliver Hale / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)
L'un des principes les plus basiques que nous oublions souvent est le code propre. À mesure que les fonctionnalités s'accumulent de plus en plus, la base de code devient plus volumineuse et la dette technique augmente.
Mais nous devons toujours nous rappeler de garder notre code cohérent et propre chaque fois que nous l'écrivons.
L'une des choses mentionnées dans le livre est le principe DRY (Don't Repeat Yourself). Il est lié à la réutilisabilité du code. La duplication est mauvaise et c'est la vérité. Le code dupliqué rendra la maintenance de votre code très difficile et peut causer de la confusion lorsque vous devez changer une fonctionnalité ou corriger un bug.
Vous souvenez-vous de ce moment où vous deviez corriger une partie de votre code ? Et vous avez réalisé qu'il y avait du code très similaire à celui que vous veniez de changer ? Donc, vous devez changer cette partie aussi, et une autre aussi, et peut-être cette partie aussi... vous voyez le tableau.
Trouvez les bons outils
_Photo par [Unsplash](https://unsplash.com/@carlevarino?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Cesar Carlevarino Aragon / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)
Comme un bûcheron, trouver les bons outils est très important. Avant qu'un bûcheron ne commence à couper des arbres, il doit décider - a-t-il besoin d'une tronçonneuse ? Ou une hache suffit-elle ? Ou peut-être y a-t-il un tout nouveau sabre laser qu'il peut utiliser. Mais utiliser un couteau de cuisine pourrait prendre un certain temps pour abattre un arbre.
C'est similaire pour les programmeurs : ce livre nous enseigne qu'il est très important pour nous de trouver les bons outils avant de commencer à travailler (comme un bon éditeur de code). Nous ne devrions pas nous lancer directement dans le codage.
Par exemple, il est en fait possible de coder en utilisant le bloc-notes de Windows et de le compiler en utilisant la console. Mais est-ce le bon outil pour vous ? Essayez de trouver le meilleur éditeur avec lequel vous êtes le plus à l'aise. Apprenez-le et maîtrisez-le et cela augmentera votre productivité de plusieurs fois.
Il y a plusieurs éditeurs mentionnés dans le livre, comme Emacs ou Vim. Mais de nos jours, vous pouvez trouver des éditeurs de code plus modernes comme Visual Studio Code. Trouvez celui qui vous convient. C'est comme votre goût pour le café - certaines personnes préfèrent les lattes et d'autres les cappuccinos.
Ne programmez pas par coïncidence
C'est un point très important noté dans le livre. Dans tous nos parcours de programmation, il y a probablement eu des moments où nous codions simplement à l'aveugle et de manière inattendue... et d'une manière ou d'une autre, cela a simplement fonctionné.
Vous n'étiez probablement pas sûr de ce que vous faisiez réellement, alors vous avez continué à ajouter plus de code et cela a encore fonctionné. C'est-à-dire, jusqu'au jour où il y a eu un problème et vous avez essayé de supprimer un morceau de code et cela a complètement tout cassé. Et vous n'étiez pas sûr de quel morceau l'a causé.
Se fier à des inconnues est très dangereux. Lorsque vous n'êtes pas sûr de ce que le code est censé faire, essayez de le simplifier et assurez-vous que le code est fiable en soi, et pas seulement fiable par hasard.
Ne vous fiez qu'aux choses dont vous êtes sûr. Ne programmez pas par coïncidence.
Test unitaire
Les tests sont un sujet brûlant ces jours-ci. Et oui, c'était aussi un sujet important il y a 20 ans (et cela le sera toujours).
Mais parfois, les gens oublient les tests unitaires de nos jours. Ils ont peut-être juste fini leur code et ils ont supposé que tout allait bien... jusqu'à ce que le code se retrouve cassé en production à cause de cas limites.
Afin de maintenir la stabilité et de refactoriser en toute sécurité, nous devons toujours garder notre code protégé en écrivant des tests unitaires. Et ce n'est jamais suffisant si vos tests ne couvrent que le chemin heureux. Effectuez des tests impitoyables sur votre code, et rappelez-vous que votre code n'est pas terminé tant que vous n'avez pas couvert chaque test disponible.
Les tests unitaires vous aideront à être confiant que votre morceau de code est vraiment terminé.
Prendre possession
Il y a une dernière chose dont je veux parler. Comme nous le savons, les programmeurs aiment laisser des 'héritages' derrière eux, sous forme de code. Et oui, la plupart du temps, c'est mauvais.
En tant que programmeur, nous devons être fiers de notre propre travail. Nous devrions être fiers de la responsabilité qui nous a été donnée et du morceau de code sur lequel nous avons travaillé.
Lorsque nous sommes enfin capables d'être fiers de notre code et de le posséder, nous serons capables de laisser un bon héritage derrière nous. Et les gens verront notre code comme une signature. Lorsqu'ils verront notre code, ils sauront qu'il sera solide et bien écrit, par un professionnel.
Conclusion
Il y a encore plus de sujets abordés dans ce livre que je n'ai pas discutés ici, comme les Exigences et le Travail d'équipe. Si vous êtes intéressé à explorer ces sujets, vous devriez essayer de trouver et de lire le livre !
Juste une note, cependant : autant j'ai aimé le livre, certaines choses ne semblaient pas pertinentes, compte tenu de l'âge du livre (20 ans). Il parle de vieux langages comme Prolog, et parle de la POO comme si c'était un concept vraiment nouveau - donc ces bizarreries ne semblent pas correctes.
Mais cela ne peut pas être reproché puisque cela fait déjà quelques décennies.
Mis à part cela, la plupart des sujets abordés dans le livre sont encore assez pertinents à l'âge actuel de la programmation, comme ceux que j'ai abordés ci-dessus.
Si j'essayais de résumer tout ce qui est dans ce livre, je dirais qu'il couvre tout ce que j'ai jamais lu sur le Web pour devenir un meilleur ingénieur.
Merci d'avoir lu mon article sur The Pragmatic Programmer ! J'espère qu'il vous a donné quelques perspectives sur votre parcours en tant que programmeur ou ingénieur logiciel. Et procurez-vous un exemplaire du livre si vous êtes intéressé à en apprendre plus.
P.S. J'ai écrit cet article de ma propre initiative, sans aucun moyen de publicité ou de marketing d'un tiers. La photo de couverture a été prise sur le site d'Amazon.