Un groupe veut réaliser un questionnaire à choix multiples

1.

Une question est un dictionnaire : {"enonce": str, "choix": list, "bonne": str}. Cette phrase est le contrat : tant qu'elle tient, les trois modules s'ignorent.

2. correction. Il ne lit aucun fichier, n'affiche rien, ne dépend d'aucune saisie : ses fonctions prennent deux listes et rendent un nombre. On peut l'écrire, le tester et le finir le premier jour, avec des listes écrites à la main.

C'est aussi le module qui porte le plus de logique — donc celui qu'il vaut mieux avoir terminé et vérifié tôt.

3. Le plus risqué est banque, parce qu'il dépend d'une chose extérieure au groupe : le format du fichier. Il faut le lire, le décoder, gérer une ligne mal formée, un fichier absent, un encodage inattendu. C'est là que le temps se perd.

La parade tient en une phrase : écrire tout de suite une version de secours.

def charger(fichier):
    """Version de secours : trois questions ecrites en dur.
    Sera remplacee par la lecture du fichier."""
    return [{"enonce": "Capitale du Portugal ?",
             "choix": ["Lisbonne", "Porto"], "bonne": "Lisbonne"},
            {"enonce": "2 + 2 ?",
             "choix": ["3", "4"], "bonne": "4"}]

Elle respecte exactement le prototype. Le reste du projet peut donc être écrit, assemblé, testé et démontré sans que la lecture de fichier existe. Le jour où elle marche, on remplace le corps de la fonction et rien d'autre ne bouge ; le jour où elle ne marche pas, on présente quand même.

C'est la parade générale au module risqué : on ne le supprime pas, on le remplace provisoirement par quelque chose qui a la même interface. Le risque cesse alors d'être celui du projet entier pour devenir celui d'une seule fonction.