比較的大規模なプロジェクトでは、機能をさまざまな機能に分割し、次にさまざまなモジュールに分割し、さまざまなパッケージに分割することについて考える必要があります。場合によっては、さまざまなソースディストリビューション（たとえば、optparserなどの共通ユーティリティを別のプロジェクトに抽出するなど）にまたがって実行することもあります。いくつかの機能を機能、モジュール、パッケージに分割するための推奨方法はありますか？
質問 - 同じモジュールに入れる部品と別のモジュールに入れる部品をどうやって決めるのですか？パッケージについても同じ質問です。
可能ですHow many Python classes should I put in one file?
は、クラス定義の全体的なセットをスケッチ参照してください。
これらのクラス定義を「モジュール」に分割します。
モジュールを個別に実装してテストします。
モジュールをまとめて最終的なアプリケーションを作成します。
注。有機的に進化した作業アプリケーションを分解することは、ほとんど不可能です。そうしないでください。
デザインを早く分解する必要があります。別々のモジュールをビルドします。統合してアプリケーションを構築する。
これはおそらく、開発プロセスの初期段階で行ったことの1つです。私は大規模なプロジェクトでは一度も働いたことはありませんが、何をやろうとしているのか、どこでロードマップを立てるのが理にかなっています。 （あなたが間違えたようにそれについて質問するためにあなたにリブしようとしていない：D）
モジュールは、目的や機能によって何らかの形でグループ分けされています。あなたは、インターフェイスまたは他の接続の各実装を試すことができます。
大規模なソフトウェアプログラムの設計面について書かれています。これは簡単ではないし、すでにコードが書かれているのはやりにくい。私はあなたの地元の本屋に落とし、ソフトウェア設計の原則に関する良い本を拾うことをお勧めします。 どのように物事をグループ化するかと同じくらい重要なのは、モジュール同士の会話の仕方です。うまく設計されたインターフェースは、使いやすいソフトウェアと、バグ満載のソフトウェアとの間で最大の違いです。 –
ペンと紙を取り出します。あなたのソフトウェアがどのように高いレベルで相互作用するかを描こうとしてください。ソフトウェアなどのさまざまなレイヤーを描く。機能性と目的別にアイテムをグループ化する。ソフトウェアに複数の抽象レイヤーがある場合は、それらをグループ化するといいでしょう。高レベルでは、特定のレイヤの要素はすべて同じ汎用性を共有します。これで、ソフトウェアがレイヤーになったので、特定の機能や特殊化に基づいて、これらのレイヤーを異なるプロジェクトに分けることができます。
これを行う必要がある特定の段階については、コードベースで作業している複数の人がいたり、プロジェクトを可能な限りモジュール化しておきたいと思っています。うまくいけば、あなたのコードはこれを行うのに十分なモジュールです。あなたが高いレベルであなたのソフトウェアを分解することができない場合、あなたのソフトウェアはおそらくスパゲッティコードであり、あなたはそれをリファクタリングする必要があります。
うまくいけば、それはあなたに何かを与えるでしょう。
実際に、それはあなたが作成するプロジェクトごとに異なりますが、ここでの例です：
coreパッケージには、プロジェクトなしでは生きてカントあるモジュールが含まれています。これにはアプリケーションの主な機能が含まれている可能性があります。uiパッケージには、ユーザーインターフェイスを扱うモジュールが含まれています。つまり、コンソールからUIを分割した場合です。これは単なる例です。それは本当にあなたがどこに行くべきかを決めることになります。
David Parnasの「モジュールをシステムに分解する基準」という古典的な論文があります。それは古典的なものです（そして、ある年齢なので、少し古いかもしれません）。
たぶん、あなたはそこから起動することができ、PDFはこちら
http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
+1今日はまだまだ関連性の高い古い学校のための+1 – Polaris878
ありがとう、私は今あなたの賛辞の後に幸せに家に帰ることができます:) –
2003は "古い学校"ですか？ –
私はあなたに共感します。あなたは自己疑いに苦しんでいます。心配しないでください。母国語を含むあらゆる言語を話すことができれば、あなたは自分でモジュール化を行う資格があります。証拠については、「The Language Instinct」または「The Math Instinct」を読むことができます。
見てみましょう。あなたは彼らからたくさんのことを学ぶことができますが、あなたはそれらから多くの悪いことを学ぶこともできます。
いくつかのプロジェクト/フレームワークは、多くの誇大宣伝を得る。しかし、機能のグループ化、モジュールに与えられた名前さえも誤解を招くことがあります。彼らはプログラマーの意図を明らかにするわけではありません。彼らは "高い凝集力"テストに失敗します。
書籍はこれ以上ありません。あなたの本の選択に80/20ルールを適用してください。ケープジョーンズの2010年の「ソフトウェアエンジニアリングのベストプラクティス」のような、よく完成した、よく研究された本でさえ、無縁です。それは、10人のアジャイル/ XPチームがWindows Vistaを実行するのに12年かかり、ERPパッケージを実行するのに25年かかっているという。それは、セグメント化のための2009年までの方法、すなわちモジュール化のための用語がないという。私はそれがあなたを助けるとは思わない。
私の主旨は、モデル/参考文献/ソースの例を非常に注意深く選択する必要があります。有名な名前を過大評価せず、過小評価しないでください。
私の経験で証明された私の助けはここにあります。
どの属性がどのDBテーブルに移動するか、どのプロパティ/メソッドがどのクラス/オブジェクトになるかを決定するのと同じくらいですか？より深いレベルでは、家庭での家具の整理、または棚の本の整理に似ています。あなたはすでにそのようなことをしています。ソフトウェアは同じで、大きな問題はありません！
まず「凝集力」について心配してください。例えば書籍（Leo Tolstoy、James Joyce、DE Lawrence）は賢明です（HTML、CSS、John Keats、jQuery、tinymce）。物事を整理する方法はたくさんあります。タキソノミストでさえも、このことに関しては依然として深刻な反論が残っています。
「カップリング」について心配してください。 "恥ずかしがり屋"になりなさい。 "見知らぬ人と話をしないでください"過度にやさしくないでください。可能な限り独立したパッケージ/ DBテーブル/クラス/オブジェクト/モジュール/本棚を自己完結型として作成してください。 Joelは、Excelチームにとって、外部の依存関係をすべて嫌うこと、そして独自のコンパイラを構築することに敬意を表しています。正確な
http://stackoverflow.com/questions/171785/how-do-you-organize-python-modules – SilentGhost
@SilentGhostを複製 - あなたが指摘答えは混乱を整理してやるべきことを持って、私は反対し、サードパーティの依存関係のSridの質問は、私の考えでは、ソフトウェア設計ともっと関係しているようです。 –
Fabioが正しいです。 –