Y a-t-il des effets secondaires négatifs de la division de grands modules? [fermé]

21

Fermé . Cette question est basée sur l'opinion . Il n'accepte pas actuellement les réponses.

Vous souhaitez améliorer cette question? Mettez à jour la question afin d'y répondre avec des faits et des citations en modifiant ce message .

Fermé il y a 5 ans .

Je parcourais un projet github et j'ai trouvé ce module qui a plus de 10 000 lignes.

Est-ce une pratique courante d'avoir autant de code dans un seul module?

Il me semble que cela devrait être réparti sur plusieurs modules. Peut-être un pour chaque moteur db.

Quel avantage le développeur obtient-il à créer un module énorme comme celui-ci (autre que «tout avoir en un seul endroit») ou quel inconvénient y a-t-il à le diviser (autre que «complexité»)?

python code-quality modules

— Mahmoud Hossam
source

Pas 8k lignes - c'est sûr!

— BЈовић

4

Ce n'est pas la taille du module, c'est la façon dont vous l'utilisez ...

— jmq

4

Les programmes sont destinés à être lus par les humains et seulement accessoirement aux ordinateurs à exécuter - Donald Knuth.

— Mahmoud Hossam

1

Un module / sous-module est censé faire une chose particulière. Un module (idiot) pour ajouter 2 nombres en Python serait de 2 lignes seulement. Un module pour faire quelque chose de plus compliqué sera certainement plus gros. Je dis restreindre le module / sous-module à une seule fonction. Gardez cela comme référence.

— c0da

De loin, le point le plus important pour un code orienté objet est d'avoir une structure de classe bien organisée avec une séparation des préoccupations et une sécheresse extrême. La division du module est alors la partie facile.

— Acumenus

14

Ce que vous avez rencontré est le soi-disant « objet de Dieu », car il fait tout ou sait tout. Fuyez-le (si vous le pouvez).

Il n'y a pas un nombre défini de LOC par module, mais cela devrait être quelque chose qui facilite la navigation dans le code et la compréhension de ce que font les méthodes. D'après mon expérience personnelle, si votre module dépasse 1k lignes ^* , vous faites quelque chose de mal.

^{* Même un module de ligne 1k est très gros.}

— BЈовић
source

9

L'exemple donné n'est pas un objet divin , c'est en fait une hiérarchie de classe entière, y compris son doctest , qui se trouve être dans un seul fichier .py. Ce n'est peut-être pas l'idéal, mais il y a des raisons pragmatiques de vouloir le faire et, comme le suggère BillThor , le code lui-même est par ailleurs raisonnablement bien structuré. Il ne correspond certainement pas à la définition classique d'un objet divin , juste un qui a un travail assez complexe à faire et doit être adaptable à un certain nombre de scénarios différents.

— Mark Booth

6

Cela semble être un module où les limites de taille typiques peuvent ne pas s'appliquer. La majorité des fonctionnalités se trouve dans les 2k premières lignes de code et commentaires. Le reste du fichier semble être un grand nombre de classes d'adaptateurs et d'autres classes de support qui semblent être étroitement couplées au module. Dans d'autres langues, les classes seraient dans des fichiers séparés d'une taille raisonnable.

D'autres chaînes de documentation pourraient être utiles, mais elles augmenteraient la taille d'un module déjà volumineux. Le code est clair et explicite avec des commentaires appropriés si nécessaire.

— BillThor
source

5

Bien sûr, la "limite" réelle varie selon votre projet et une multitude de facteurs.

Mais j'interviens avec une règle de base: 200 lignes de Python décent. Autrement dit, aucun code C ou Java écrit en Python, mais bon Python en Python.

— unperson325680
source

1

Sensationnel.

Je suppose que je ne connais pas la réponse complète pour celui-ci, mais j'aime penser comme une réponse à la question du titre "Quelle devrait être la taille d'un module Python?" comme le concept de Parnas, cachant un secret. Dans ce cas, le module semble le faire correctement (et c'est un si grand secret qu'il se cache).

J'ai fouillé dans des articles plus tard qui parlent beaucoup de couplage et de cohésion. Peut-être que le fait d'avoir de nombreux modules db forcerait trop d'appels entre les modules, ce qui augmenterait ce qui est considéré comme une mauvaise pratique, c'est-à-dire une cohésion plus faible et un couplage plus élevé?

J'ai vu des données expérimentales parler de programmeurs décidant de sacrifier les bonnes pratiques dans un souci de simplicité et de compréhension, quelles que soient les bonnes pratiques. En fait, il pourrait également y avoir un conflit entre les bonnes pratiques. Disons que les performances ne font généralement pas plaisir aux personnes chargées de la maintenance plus tard. Je ne sais pas vraiment comment la lisibilité serait améliorée dans ce cas avec un si gros module.

Une autre chose que j'ai remarquée est qu'une partie du code est indiquée comme générique et que le reste des dbs en est étendu. Je ne suis pas un programmeur python, mais cela pourrait peut-être justifier quelque chose?

Donc, je n'ai pas de réponse finale, mais j'espère que quelqu'un mettra aussi ces points en évidence!

— Oeufcoque Penteano
source