大きなモジュールを分割することによる悪影響はありますか？[閉まっている]

私はgithubプロジェクトをブラウズしていて、1万行を超えるこのモジュールを見つけました。

単一のモジュールにそのようなコードを含めることは一般的な習慣ですか？

これは複数のモジュールに分割する必要があるように思えます。データベースエンジンごとに1つかもしれません。

開発者は、このような1つの巨大なモジュールを作成すること（「すべてを1か所にまとめる」以外）からどのようなメリットを得ますか？

あなたが遭遇したのは、いわゆる「神オブジェクト」です。なぜなら、それはすべてを行うか、すべてを知っているからです。それから逃げます（可能な場合）。

モジュールごとにLOCの数は明確ではありませんが、コードを簡単に参照し、メソッドの実行内容を簡単に理解できるものでなければなりません。私の個人的な経験から、モジュールが1k行^*を超えると、何か間違ったことをしていることになります。

^{* 1kラインモジュールでさえ非常に大きい。}

これは、通常のサイズ制限が適用されないモジュールのようです。機能の大部分は、コードとコメントの最初の2k行にあります。ファイルの残りの部分は、モジュールに密結合しているように見える多くのアダプタクラスと他のサポートクラスのようです。他の言語では、クラスは適切なサイズの個別のファイルになります。

いくつかのdoc文字列は便利かもしれませんが、すでに大きなモジュールのサイズが大きくなります。コードは明確で、必要に応じて適切なコメントとともに自明です。

もちろん、実際の「制限」は、プロジェクトと多数の要因によって異なります。

しかし、私は大雑把に言って、200行の適切なPythonです。つまり、Pythonで記述されたCまたはJavaコードはありませんが、Pythonでの優れたPythonです。

ワオ。

この質問に対する完全な答えはわかりませんが、「Pythonモジュールはどれくらいの大きさですか？」というタイトルの質問に対する答えとして考えるのが好きです。秘密を隠すパルナスの概念として。この場合、モジュールはそれを適切に行うようです（そして、それはそれが隠しているような大きな秘密です）。

結合と結合に関する多くのことを話している論文を後で掘り下げてきました。多くのdbモジュールがあると、モジュール間の呼び出しが多すぎて、悪い習慣と見なされるもの、つまり凝集度が低くなり、結合が大きくなる可能性がありますか？

私は、優れた慣行が何であれ、シンプルさと理解のために、優れた慣行を犠牲にすることを決定するプログラマーに関する実験データを見てきました。実際、グッドプラクティスにも矛盾が生じる可能性があります。たとえば、パフォーマンスは通常、後でメンテナンスを行う人を幸せにするものではありません。このような大きなモジュールを使用すると、この場合に読みやすさがどのように改善されるかはよくわかりません。

私が気づいたもう一つのことは、コードの一部がジェネリックとして記述されており、残りのdbはそれから拡張されているということです。私はPythonプログラマーではありませんが、おそらくこれは何かを正当化できるでしょうか？

したがって、最終的な答えはありませんが、誰かがこれらのポイントを強調することを願っています！