Deux méthodes coexistent et c'est un peu le bordel conceptuel :
les deux endpoint de l'API appellent la même fonction compareOldNew avec un argument différent, cette fonction appelle compare
l'organisation des tâches entre les deux est assez déséquilibrée :
compare lance toutes les simulations demandées, y incorpore éventuellement les résultats précalculés, les agrège sous la forme d'un dictionnaire qui a déjà le format de l'API
CompareOldNew fait pas grand chose du coup : il choisit quelles simulations demander en fonction de si des résultats précalculés existent ou pas
C'est pas ouf, parce que deux fonctions sont au courant d'un même truc, à savoir le fait qu'une simulation sur population a des résultats précalculés, et qu'on n'aime pas que des fonctions partagent des secrets, parce que ça veut souvent dire que les tâches ne sont pas proprement réparties.
On pourrait scinder plus efficacement :
compare retourne des résultats bruts de simulation : on lui dit la réforme et un dictionnaire de cas types (ou une absence de dictionnaire de cas types), et il se débrouille soit pour les calculer soit pour aller
compareoldnew est un formatteur de résultat : il prend des résultats bruts et calcule un joli dictionnaire qui est donné à l'API.
Ca permet que la dichotomie des deux fonctions corresponde un peu plus à une dichotomie dans les tâches.
Les deux fonctions gagnent des nouveaux noms :
"compare" devient "get_simulation_results"
compareoldnew devient "get_aggregated_results"
quelques arguments gagnent aussi des nouveaux noms, genre isdecile devient simulation_sur_population (pas besoin de changer / déprécater l'ancien endpoint de l'API, on peut se contenter de clarifier sous le capot)
La génération des simulations par défaut est aussi assez moche : on le fait deux fois (une fois pour la population et une fois pour les cas types). En fait on pourrait le faire sur la population, et jamais sur les cas types (c'est assez négligeable en temps de calcul pour le faire à la volée), ce qui clarifierait également le code. Ca fait du sens de le faire avec cette issue car les principaux consommateurs de ces variables sont compare et compareoldnew, ce sont donc aussi les principales raisons qui en font des variables globales.
Deux méthodes coexistent et c'est un peu le bordel conceptuel :
l'organisation des tâches entre les deux est assez déséquilibrée :
C'est pas ouf, parce que deux fonctions sont au courant d'un même truc, à savoir le fait qu'une simulation sur population a des résultats précalculés, et qu'on n'aime pas que des fonctions partagent des secrets, parce que ça veut souvent dire que les tâches ne sont pas proprement réparties.
On pourrait scinder plus efficacement :
Ca permet que la dichotomie des deux fonctions corresponde un peu plus à une dichotomie dans les tâches.
Les deux fonctions gagnent des nouveaux noms :
quelques arguments gagnent aussi des nouveaux noms, genre isdecile devient simulation_sur_population (pas besoin de changer / déprécater l'ancien endpoint de l'API, on peut se contenter de clarifier sous le capot)
La génération des simulations par défaut est aussi assez moche : on le fait deux fois (une fois pour la population et une fois pour les cas types). En fait on pourrait le faire sur la population, et jamais sur les cas types (c'est assez négligeable en temps de calcul pour le faire à la volée), ce qui clarifierait également le code. Ca fait du sens de le faire avec cette issue car les principaux consommateurs de ces variables sont compare et compareoldnew, ce sont donc aussi les principales raisons qui en font des variables globales.