dans Personnel

Reproduire le métro de Paris sous Minecraft

Ou l’art de se planter lamentablement et de devoir tout recommencer. Je m’explique. Je suis un grand ferrovipathe et un joueur inconditionnel de Minecraft. Alors, un jour, alors que je créais un petit chemin de fer pour me déplacer plus vite dans mon domaine, germa l’idée de refaire le métro de Paris.

Ni une ni deux, la station Argentine était créée. Et puis la ligne 1 commençait à prendre forme. À son apogée, elle allait de La Défense à Tuileries. Mais la ligne 1 du métro parisien n’est pas la seule ligne ; elle a de nombreuses correspondances. Et paf, je me mets à créer toutes les correspondances. J’avance, je suis fier de mon travail (la station Saint-Lazare était magnifique, surtout celle de la ligne 14). Mais un drame terrible va survenir !

J’ai la ligne 12 présente à la station Saint-Lazare, la ligne 8 à la station Opéra ; à la station Concorde, les deux croisent la ligne 1. J’ai donc envie de tout relier. Ni une ni deux, je creuse un tunnel perpendiculairement à la sortie de la station Opéra (pour la ligne 8) et commence à aménager la station Madeleine, où la ligne 14 croise également la 8 et la 12. Mais en creusant la sortie, je me rends compte que je suis juste à côté de la station Tuileries. « Mais où est le problème ? » se demandent peut-être ceux qui n’ont pas l’usage du métro parisien. La réponse en image.

 

La station Madeleine n’est pas du tout collée à Tuileries en vrai.

 

Et vlam ! tout mon travail tombe en ruine tel un château de cartes qui aurait croisé la route d’un ventilateur surexcité. Mais pourquoi ?

Parce que je n’avais rien planifié et tout se faisait à coup d’approximations et au petit bonheur la chance. Et j’étais trop plongé dans les détails pour m’en rendre compte. Et si le manque de planification cause des tords dans Minecraft, n’en serait-il pas de même dans le monde informatique ? D’ailleurs, n’est-ce-pas une des leçons du premier chapitre de The Pragmatic Programmer ?

Voià pourquoi on dit que les meilleurs outils d’un programmeur sont la feuille et le crayon. Ne pas se ruer sur le code mais réfléchir, planifier, envisager, concevoir. « Perdre » un peu de temps avant peut en faire gagner énormément après, quand il s’agit de maintenir ou de faire évoluer.

J’ai appris de mon erreur et j’ai recommencé sur une nouvelle map, entièrement plate (pour se faciliter la tâche) mais en calculant bien mon coup cette fois. Je vous tiens au jus (électrique, mauvaise blague).

Laisser un commentaire