Stack Overflow overflow

J’ai perdu tellement de temps sur Stack Overflow.

A vrai dire, Stack Overflow, c’est génial, et la connaissance du développement logiciel ne serait pas si avancée et si répandue sans sa grande influence. Ce que je veux dire, c’est que je me suis souvent retrouvé à répéter le schéma sans fin de ‘Hé, j’ai une erreur… Wow, tellement de mots… Googlons ça. Stack Overflow l’a ! Voyons ce qu’ils disent’

Je ne parle pas du fameux syndrome du copier-coller de Stack Overflow, ni ne rejette les excellentes réponses produites par les grands développeurs là-bas, mais plutôt de l’étape manquante dans l’exemple ci-dessus : donner du sens au message d’erreur moi-même avant de chercher une réponse toute faite.

Notre cerveau est si rapide à prendre des raccourcis qu’il nous rend souvent paresseux et nous fait sauter les étapes apparemment inutiles dont notre pensée a besoin pour se développer pleinement. Prenez l’exemple de la marche. Bien que je ne me souvienne pas exactement d’avoir fait mon premier pas dans ce monde, je peux imaginer que c’était un mouvement qui nécessitait tellement de concentration - pour ne pas dire de courage - et de coordination qu’il a dû sembler assez maladroit au début. Aujourd’hui, je n’y pense même pas. Mon cerveau orchestre simplement tout, me permettant d’aller me promener et de penser réellement à autre chose.

Pensez au premier jour où vous avez tapé votre premier programme informatique. Pensez à la façon dont vous pensiez à l’époque. Peut-être que vous apprenez actuellement l’informatique et que de nombreux mécanismes auxquels les développeurs expérimentés ne pensent même pas sont des étapes que vous prenez consciemment, une par une, afin d’atteindre la qualité du code - ou même d’écrire du code qui fonctionne réellement.

Et en apprenant, nous avons tous rencontré des bugs. Le langage dans lequel nous codions nous parlait avec des mots compliqués, et des concepts que nous ne connaissions parfois même pas. Nous avons tous googlé des solutions. Et Stack Overflow est si bien conçu et maintenu que nous y avons très certainement trouvé la réponse. Et cela s’est reproduit. Les messages d’erreur étaient si difficiles à comprendre, si cryptiques, parfois. Nous avons donc simplement continué à copier-coller les messages d’erreur, et il a continué à nous donner des réponses correctes qui, avec un peu d’adaptation, fonctionnaient simplement.

Et puis, votre cerveau a sauté l’étape de lecture du message d’erreur.

Mais nous ne voulons pas juste être de très, très, très talentueux googleurs, n’est-ce pas ?

LTMLEP !

Lisez les p*****s de messages d’erreur !

J’encourage donc tous les apprenants à jeter un long regard sur les messages d’erreur qui sont lancés en pleine face juste au moment où vous attendiez une compilation réussie. Prenez le temps de les lire. Prenez le temps de regarder ces symboles étranges qui apparaissent ici et là. Et vous savez quoi ? Vous n’arriverez peut-être pas au point plus rapidement au début, mais vous gagnerez une connaissance plus profonde de la façon dont votre langage est réellement construit, comment il fonctionne en interne. Vous pourriez voir vos collègues programmeurs augmenter leurs compétences plus rapidement en surface, mais votre compréhension des messages d’erreur finira par faire de vous un Maître Jedi du Code.

Ce qui m’a vraiment fait arrêter de négliger les messages d’erreur a été la lecture de Ruby Under A Microscope par Pat Shaughnessy, un excellent livre sur la façon dont Ruby est réellement écrit en C, la façon dont le parser du langage fonctionne et la façon dont il transforme les mots que vous écrivez en concepts compréhensibles par la machine.

Quelque part dans la première partie du livre qui présente comment le parser fonctionne, l’auteur parle de la tokenisation du langage, qui est - très basiquement - comment le parser prend les mots et comprend comment les faire correspondre avec une fonctionnalité. Et les voilà, dans un exemple de code, mes amis messages d’erreur vus depuis longtemps mais si peu connus, à savoir tSTRING, tCONSTANT et tINTEGER.

Si seulement j’avais su à quoi ceux-ci correspondent avant, des messages d’erreur tels que ceux-ci ne m’auraient jamais fait googler pour trouver une réponse.

Mais comment pouvais-je savoir ? Quand vous googlez ruby tString, vous obtenez toutes sortes de résultats, sautant principalement le t précédent. Pour arriver aux vraies choses, j’aurais dû prendre le temps de lire réellement les messages d’erreur et me demander :

Qu’est-ce que le langage essaie de me dire ?

Et si cela semble étrange, rappelez-vous simplement que votre langage de programmation est en fait un programme informatique écrit par d’autres humains, et demandez-vous :

Qu’est-ce que l’auteur du langage me dit de regarder ?

Il y a de fortes chances qu’il essaie de vous faire regarder des fonctionnalités du langage qui peuvent ne pas être évidentes, mais un peu cachées. Et s’il essaie de vous les faire regarder, vous pourriez tout aussi bien le faire. Et apprendre.

Apprenez à aimer vos messages d’erreur

Non seulement devriez-vous lire attentivement les messages d’erreur, mais vous devriez également prendre le temps de créer les vôtres avec amour et soin. Comme je l’ai dit dans un article précédent, vous devriez toujours essayer d’écrire du code en pensant à votre futur vous. Et je suppose que la même chose s’applique aux messages d’erreur.

Ne vous contentez pas de lever Error, ou StandardError dans votre lib. Écrivez réellement votre propre classe OddError. Donnez-lui un message. Rendez-le clair. Faites en sorte que votre utilisateur - et cela peut être le futur vous - soit impatient de regarder ce que vous avez codé et de comprendre comment c’est architecturé.

Un message d’erreur doit être clair, donc il nécessite que votre code soit clair, et par conséquent il nécessite que votre esprit de programmation soit clair sur ce que le code fait réellement. Les messages d’erreur disent quelque chose sur vous-même.

Les messages d’erreur sont la conversation entre l’auteur d’un programme et ses utilisateurs. En tant que programmeur, vous serez l’un ou l’autre, à tour de rôle, et souvent les deux en même temps.

Les messages d’erreur vous feront grandir en apprenant le logiciel. Ils vous feront grandir en utilisant le logiciel. Ils vous feront grandir en écrivant le logiciel. Ne les rejetez pas simplement et ne sautez pas à l’étape Stack Overflow.