Aller au contenu

~/billets/bornes-arcade-lecons-dev

Ce que les bornes d'arcade m'ont appris sur le métier de dev

· #dev #retro-gaming #essai

Le jour, j’écris du code. Le soir, il m’arrive de réparer des machines qui en exécutent depuis 1978. À force de faire les deux, je me suis rendu compte que l’atelier m’a enseigné des principes d’ingénierie logicielle plus efficacement que bien des livres. En voici cinq.

1. Vérifie l’alimentation avant d’accuser la logique

Sur la borne Space Invaders, les symptômes hurlaient « carte logique morte ». Le coupable était un condensateur d’alimentation. En dev, c’est pareil : avant de soupçonner l’algorithme, vérifier l’environnement, la config, le réseau, la version. Les pannes spectaculaires ont très souvent des causes triviales, et on perd des heures parce qu’on a commencé par le compliqué.

2. La documentation survit à ceux qui l’écrivent

Le schéma de l’alimentation Midway de 1978 est encore en ligne, maintenu par des passionnés, et il m’a servi 48 ans après sa publication. Pendant ce temps, des README de projets de 2023 sont déjà faux. Une doc n’est pas un livrable de fin de sprint : c’est ce qui permettra à un inconnu, dans dix ans, de réparer ce que vous avez construit. Les communautés rétro l’ont compris mieux que l’industrie.

3. Les standards ouverts font les machines immortelles

Si on peut encore glisser un PC dans une borne SEGA de 1994, c’est parce que le connecteur JAMMA était un standard partagé par toute l’industrie. Les machines propriétaires meurent avec leur constructeur ; les standards traversent les décennies. Chaque fois que je choisis un format ouvert plutôt qu’un service fermé, je pense aux bornes JAMMA encore vivantes et aux systèmes exotiques qu’on ne peut plus réparer.

4. La réversibilité est une vertu cardinale

La règle de la conversion Astro City : zéro modification irréversible, une vraie PCB doit pouvoir revenir en cinq minutes. C’est exactement une migration avec un chemin de retour, un déploiement qu’on peut annuler, une feature derrière un flag. La question « comment je reviens en arrière ? » posée avant d’agir sépare les modifications sereines des catastrophes.

5. Réparer, c’est rejoindre une lignée

Dans la borne de 1978, j’ai trouvé l’étiquette d’un dépanneur lyonnais passé avant moi il y a quarante ans. En ouvrant un vieux code, on trouve l’équivalent : des commentaires, des noms de variables, les traces de ceux qui ont maintenu le système avant nous. On peut mépriser le code legacy, ou comprendre qu’on est juste le maillon suivant, et laisser le système un peu plus clair qu’on ne l’a trouvé, pour celui qui lira notre étiquette.

L’ironie de tout ça : le rétro gaming passe pour de la nostalgie, mais c’est l’une des meilleures écoles d’ingénierie durable que je connaisse.

Questions fréquentes

Quel rapport entre une borne d'arcade et le développement logiciel ?

Les mêmes principes gouvernent les deux : diagnostiquer les fondations avant la logique, documenter pour ceux qui suivront, préférer les standards ouverts et garder un chemin de retour.

Pourquoi vérifier l'alimentation avant la carte logique ?

Parce que des tensions instables produisent des symptômes qui imitent n'importe quelle panne. En logiciel, l'équivalent est de vérifier l'environnement et la config avant de soupçonner l'algorithme.

Qu'est-ce que le standard JAMMA ?

Un connecteur standardisé adopté par toute l'industrie de l'arcade à partir de 1985 : alimentation, vidéo, son et commandes passent par le même bus. C'est lui qui rend ces bornes encore exploitables aujourd'hui.

Comment appliquer la réversibilité en développement ?

Migrations avec retour arrière, déploiements annulables, features derrière des flags : toute modification devrait pouvoir être défaite aussi simplement qu'on débranche une PCB.

armor-alley : un classique de 1990, planqué ici depuis toujours