Bonjour 👋
Tu es ici parce que quelqu'un t'a envoyé vers ce post en réponse à une idée que tu as suggérée pour améliorer Exercism ?
Avant que notre équipe consacre du temps à explorer ton idée, elle espère que tu liras ce texte et que tu te demanderas si ton idée n'a pas déjà été envisagée, et quels pièges elle pourrait receler.
En ajoutant ces considérations et ces pièges potentiels à ta suggestion, et en réfléchissant aux raisons pour lesquelles ton idée n'a peut-être pas déjà été mise en place, tu obtiendras probablement une réponse plus rapide et plus positive.
Alors, que signifie « la barrière de Chesterton » ?
La barrière de Chesterton est une idée inspirée d'une citation tirée du livre The Thing de l'écrivain G.K. Chesterton, paru en 1929.
Elle est devenue célèbre après avoir été citée par John F. Kennedy.
Voici la citation d'origine :
Dans un tel cas, il existe une certaine institution ou une certaine loi ; disons, pour simplifier, une barrière ou un portail dressé en travers d'une route.
Le réformateur de type plus moderne s'en approche gaiement et déclare : « Je n'en vois pas l'utilité ; enlevons-la. »
À quoi le réformateur de type plus intelligent fera bien de répondre : « Si tu n'en vois pas l'utilité, je ne te laisserai certainement pas l'enlever. Va-t'en réfléchir. Puis, quand tu pourras revenir me dire que tu en vois bien l'utilité, j'autoriserai peut-être sa destruction. »
L'idée derrière la barrière de Chesterton, c'est que si tu ne comprends pas pourquoi quelque chose est là, tu ne comprends probablement pas non plus pourquoi il faudrait l'enlever.
De même, si tu ne comprends pas pourquoi quelque chose n'est pas là, tu ne comprends probablement pas pourquoi on l'a laissé de côté.
Une règle simple à retenir : « Ne retire pas une barrière avant de savoir pourquoi elle a été érigée au départ. »
En quoi cette notion est-elle pertinente pour Exercism ?
Chez Exercism, on a la chance de voir sans cesse de nombreuses personnes rejoindre notre communauté et partager leurs réflexions et leurs idées.
Beaucoup de ces idées sont nouvelles, innovantes, enthousiasmantes, et débloquent notre réflexion.
Donc si tu as une idée ou une suggestion, elle est la bienvenue !
Cependant, le plus souvent, les gens publient des idées qui ont déjà été discutées de nombreuses fois.
Répondre à ces idées, revenir sur nos décisions ou les justifier à nouveau peut être extrêmement éprouvant pour notre équipe.
Cet article vise à aider à préserver ce temps et cette énergie.
Exercism a été conçu, pensé et construit par des milliers de personnes très talentueuses.
C'est un produit très réfléchi : les choses sont là parce qu'elles ont été conçues pour y être, et certaines sont souvent absentes parce qu'elles ont été conçues pour l'être.
Presque tout, chez Exercism, a été débattu, discuté et repensé de nombreuses fois.
Donc avant de publier ton idée, demande-toi si nous ne l'avons pas déjà envisagée, et pourquoi nous avons peut-être fait les choses différemment de ce que tu proposes.
Et souviens-toi : plus ton idée paraît évidente, plus il est probable qu'elle ait déjà été discutée et débattue de nombreuses fois. Alors quand tu la présentes, présente-la en tenant compte des réserves et des pièges potentiels.
Si tu as l'instinct de dire « pourquoi ne pas juste ... », alors ton idée entre presque certainement dans cette catégorie.
Ne crains jamais de publier, mais prends bien le temps de réfléchir avant !
As-tu un exemple ?
Une frustration fréquente : des apprenants soumettent aux mentors du code qui ne passe pas les tests.
Une suggestion tout aussi fréquente est : « Pourquoi ne pas simplement exécuter automatiquement les tests dans la CLI avant que quelqu'un soumette son code ? »
L'idée semble excellente : la CLI n'a qu'à appeler une commande pour exécuter les tests et empêcher l'apprenant de soumettre si les tests échouent.
Alors d'abord, que signifie « simplement appeler une commande pour exécuter les tests » ?
Cela signifie écrire un script, pour chacun des 52 langages d'Exercism, capable d'exécuter les tests et de vérifier le résultat.
C'est un certain effort, mais c'est faisable.
Mais cela signifie aussi écrire ce script pour qu'il fonctionne sous Windows, MacOSX et Linux, dans absolument toutes les versions et configurations possibles. C'est beaucoup de travail, pour ne pas dire une quantité de travail sans limite.
« Pourquoi faut-il gérer toutes les configurations ? » me demanderas-tu peut-être.
Eh bien, parce que tu bloques activement quelqu'un qui veut utiliser Exercism s'il ne peut pas exécuter ce script.
Cela signifie aussi que ce script ne doit jamais échouer.
Si, pour une raison quelconque, le script ne s'exécute pas, l'apprenant est complètement bloqué.
Un bug dans l'un de ces 52*3*n scripts signifie qu'un apprenant ne peut plus utiliser le parcours sur ce système d'exploitation.
Comment tester cela ? Impossible.
Mais, diras-tu, il suffirait d'ajouter une option --skip-tests.
C'est une bonne suggestion, mais elle nous ramène à notre point de départ : les gens peuvent choisir de contourner les tests quand ils le veulent.
Sauf que désormais, il est légèrement moins probable que des tests cassés soient soumis, ce qui fait que les mentors s'y attendent moins, et qu'il est donc d'autant plus perturbant et déroutant de tomber sur des tests réellement cassés.
« Mais les gens ne feraient pas ça en général », objecteras-tu. C'est vrai, pour certains langages où l'exécution des tests prend 0,5 s.
Mais pour les langages où l'exécution des tests prend 20 s, devoir attendre 20 s de plus avant de soumettre est incroyablement frustrant pour les apprenants, et sauter les derniers tests deviendrait alors monnaie courante.
Quel que soit le résultat de cette conversation, il est clair que la complexité en jeu est bien plus grande qu'elle n'en a l'air au premier abord. Il y a des défis techniques à examiner, des problèmes de workflow à considérer, et la prise de conscience que les parcours diffèrent tellement que ce qui est rapide et simple pour l'un est pénible pour un autre.
Ainsi, plutôt que de proposer « pourquoi ne pas exécuter les tests avant la soumission », posons une question : « Pourquoi les gens publient-ils des solutions qui ne passent pas les tests ? »
Et là, ça devient intéressant.
La réponse générale est qu'ils sont bloqués ou perdus.
Et qu'ils ont besoin d'aide.
Ce qui signifie que soumettre des tests cassés est un indice très précieux pour les mentors : cet apprenant a besoin d'aide.
Oui, c'est frustrant, car les mentors ne savent pas immédiatement si le code est « correct » ou non. Cependant, ils peuvent télécharger le code et l'exécuter pour le vérifier (ce que font la plupart des mentors sur les solutions non triviales), puis savoir avec 100 % de certitude s'il est correct ou non.
Et les apprenants bloqués qui ont besoin d'aide ne se retrouvent pas plus bloqués encore, à avoir besoin de plus d'aide : ils arrivent chez un mentor qui peut voir les corrections et les suggérer plus rapidement.
Note : nous résolvons d'ailleurs ce problème en exécutant les tests côté serveur, un chantier vaste et coûteux, mais qui vaut l'effort pour l'expérience améliorée des apprenants et, surtout, pour le temps et l'énergie que cela épargne à nos mentors.
Autre chose ?
Trois choses :
-
Cet article de Second Order Thinking est une bonne lecture. La citation « Ne retire pas une barrière avant de savoir pourquoi elle a été érigée au départ » vient de ce billet.
-
The Thing de G.K. Chesterton est disponible ici https://archive.org/details/G.K.ChestertonTheThing.
- Il se peut vraiment que ton idée soit nouvelle et excellente. N'aie pas peur ni honte de la proposer !
