Un groupe de trois se répartit

Deux problèmes, et ils sont de nature différente.

1. « Le reste » n'est pas un module. Deux parts sont nommées par ce qu'elles font, la troisième par ce qui n'a pas été nommé. Cette part-là contient donc, sans qu'on l'ait décidé : la boucle de jeu, la lecture du clavier, la gestion des erreurs, l'assemblage, et tout ce qu'on découvrira en route. Elle est la seule à ne pas avoir de limite, et c'est celle qui débordera.

2. Les interfaces n'ont pas été fixées. Celui qui écrit l'affichage doit savoir ce qu'est « une grille » : une liste de listes de caractères ? un dictionnaire indexé par coordonnées ? une chaîne de $9$ caractères ? Tant que personne n'a tranché, chacun choisit — et les trois morceaux, individuellement corrects, refuseront de s'emboîter. Le désastre est daté : il se découvre à l'assemblage, c'est-à-dire tard.

Un troisième problème, plus discret : celui qui a « le reste » ne peut commencer que lorsque les deux autres ont fini, puisque son travail consiste à les enchaîner. La répartition, qui devait paralléliser, sérialise.

Ce qu'il aurait fallu fixer d'abord. Trois choses, dans cet ordre, et qui tiennent sur une demi-page :

• la représentation des données : « une grille est une liste de $3$ listes de $3$ chaînes, chacune valant "X", "O" ou "." » ;
• les prototypes de chaque fonction : son nom, ses paramètres, ce qu'elle renvoie, ce qu'elle exige en entrée ;
• qui écrit quoi, en dernier seulement — la répartition est une conséquence du découpage, jamais l'inverse.

La formulation du cours : on ne répartit pas le travail, on découpe le problème. La différence se voit à une question simple : chacun peut-il vérifier que sa part est juste sans attendre les autres ? Avec « toi l'affichage, toi les règles, moi le reste », la réponse est non pour les trois.