En regardant le code de gaufre.py · main · gopher / gaufre · GitLab, et étant confronté dans un code récent à cette question, je me demande à partir de quel critère il est conseillé de découper un module en sous-modules (longueur, clarification, …).
Pour ma part (pour des raisons pédagogiques, j’ai tendance à faire plein de fonctions donc j’arrive à des codes longs et peu pratiques en maintenance/correction.
Je me demande donc quelles sont les bonnes pratiques en la matière.
Pour ma part, je fais du “un fichier Python, un traitement”. Par exemple, là je finis un miniprojet jinjaNG pour sa première RC. J’ai choisi de créer un fichier pour la gestion de configs utilisateur, un autre pour l’analyse des données, et un dernier construisant un fichier souhaité.
J’ai aussi pris l’habitude de mettre les configs internes à part.
Une classe sert à regrouper des attributs qui vont ensemble (je viens du C, pour moi une classe c’est une struct).
Un module sert à regrouper des constantes, classes, fonctions, … qui vont ensemble.
J’essaye de ne pas « découper pour découper », quitte à ce que certains fichiers soient un peu longs, tant que je m’y retrouve ça va. Mais bon quand je commence à m’y perdre dans un fichier c’est qu’il est temps de se calmer et de voir ce qu’on peut faire pour améliorer la situation.
Je veux dire par là que j’évite « la pelletée de fichiers de trois-quatre lignes », dans les projets comme ça je m’y perds dans l’arborescence, c’est pas mieux.
Et je veux dire par là que je ne m’en soucie pas beaucoup (sauf si la belle occasion se présente). Je préfère me soucier d’avoir les bonnes classes, avec des noms bien choisis, avec les bons attributs bien choisis, eux aussi avec des noms bien choisis.
En Python on peut souvent facilement réorganiser son code sans pour autant casser le code qui l’utilisait (passer d’un module à un paquet en ajoutant quelques imports dans le __init__.py par exemple) : profitons-en.
Au moment où je prends la décision de découper (c’est ta question je crois ?) je pense que j’essaye de voir ce qui va (sémantiquement) ensemble. C’est donc pas forcément du tout 50%/50%. Typiquement c’est une classe qui a bien mûri, qui commence à être utilisée à plusieurs endroits, qui va gagner le droit d’avoir son propre module, avec ses constantes, ses imports… Tant pis si c’est que 10% du module qui s’en va : il faut que ça ai du sens.
Pour répondre à ta question en prenant appui sur le code cité (qui est mon code donc), il y a également l’historique si on peut dire : je souhaitais réaliser un serveur le plus simple possible et sans composant externe. J’obtenais donc, au départ, un code de moins de 200 lignes.
Dans ce cas là, multiplier les fichiers ne me semblait pas intéressant. Seule la configuration (au format python donc pour ne pas avoir à gérer un format spécifique et simplifier l’import et diminuer le nombre de lignes) a été mise à part pour des raisons évidentes par rapport à l’évolution du code source potentielle du serveur lui-même.
Au final, la config n’est plus “directement” liée au dépôt, seul subsiste un fichier exemple. C’est plus pratique de faire un simple pull pour mettre à jour le serveur.
Enfin, j’ai également ajouté une notion de plugins afin de permettre au serveur d’avoir des fonctionnalités supplémentaires qui ne sont pas liées directement avec la RFC. Ce sont donc, à nouveau, des fichiers externes, mais là ça parait plus logique.
Si le code du serveur devait évoluer vers des choses plus épaisses (parce que disons-le clairement, moins de 300 lignes c’est très facile à relire), alors oui, je découperai certainement celui-ci. Mais je vais tâcher de ne pas trop l’épaissir, il est désormais assez stable (a priori, au moins chez moi).
“This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decompositions are discussed. The unconventional decomposition, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.”