比較的大規模なプロジェクトでは、機能をさまざまな機能、さまざまなモジュール、さまざまなパッケージに分割することを考える必要がある場合があります。場合によっては、異なるソース ディストリビューションにまたがる場合があります (例: optparser などの共通ユーティリティを別のプロジェクトに抽出する)。
質問 - 同じモジュールに入れるパーツと別のモジュールに入れるパーツをどのように決定するのでしょうか? パッケージについても同じ質問です。
2373 次
6 に答える
7
David Parnas による「システムをモジュールに分解する際に使用される基準について」という古典的な論文があります。それは古典的です（そして特定の年齢を持っているので、少し時代遅れになる可能性があります）.
そこから始めることもできます。PDF はこちらから入手できます。
http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
于 2009-07-22T22:27:58.380 に答える
4
ペンと紙を取り出します。ソフトウェアがどのように相互作用するかを高レベルで描くようにしてください。ソフトウェアなどのさまざまなレイヤーを描画します。機能や目的ごとに、場合によっては使用するテクノロジーの種類ごとに、アイテムをグループ化します。ソフトウェアに複数の抽象化レイヤーがある場合は、それでグループ化すると思います。大まかに言えば、特定のレイヤーの要素はすべて同じ汎用を共有します。ソフトウェアがレイヤーになっているので、特定の機能や専門分野に基づいて、これらのレイヤーをさまざまなプロジェクトに分割できます。
あなたがこれを行うべきであるあなたが到達する特定の段階については？コードベースで複数の人が作業している場合、またはプロジェクトを可能な限りモジュール化したい場合に、私は言います。うまくいけば、あなたのコードはこれを行うのに十分なモジュール式です。ソフトウェアを高レベルで分解できない場合、ソフトウェアはおそらくスパゲッティコードであるため、リファクタリングを検討する必要があります。
うまくいけば、それはあなたに何かを与えるでしょう。
于 2009-07-22T22:13:07.553 に答える
2
1 つのファイルにいくつの Python クラスを入れる必要がありますか? を参照してください。
クラス定義の全体的なセットをスケッチします。
これらのクラス定義を「モジュール」に分割します。
モジュールを互いに個別に実装してテストします。
モジュールを組み合わせて、最終的なアプリケーションを作成します。
注. 有機的に進化した稼働中のアプリケーションを分解することはほとんど不可能です。だから、それをしないでください。
設計を早期かつ頻繁に分解します。個別のモジュールをビルドします。統合してアプリケーションを構築します。
于 2009-07-23T01:52:10.977 に答える
1
私見ですが、これはおそらく開発プロセスの早い段階で行うことの1つです。私は大規模なプロジェクトに取り組んだことはありませんが、何がどこで行われるかについてのロードマップを作成することは理にかなっています。（あなたが間違いを犯したようにそれについて尋ねるためにあなたを肋骨にしようとしないでください：D）
モジュールは通常、目的や機能によって何らかの形でグループ化されます。インターフェイスの各実装、または他の接続を試すことができます。
于 2009-07-22T22:12:49.707 に答える
1
私はあなたに同情します。あなたは自己不信に苦しんでいます。心配しないで。母国語を含め、どの言語でも話せれば、自分でモジュール化を行う資格があります。証拠として、「The Language Instinct」または「The Math Instinct」を読むことができます。
周りを見回してください。彼らから多くのことを学ぶことができますが、多くの悪いことも学ぶことができます。
一部のプロジェクト/フレームワークは、誇大広告で大いに盛り上がります。しかし、モジュールに付けられた名前でさえ、機能のグループ化のいくつかは誤解を招くものです。それらはプログラマーの「意図を明らかに」しません。それらは「高凝集性」テストに失敗します。
本は良くありません。本の選択には 80/20 ルールを適用してください。Capers Jones の 2010 年の「Software Engineering Best Practices」のような、非常に完全で十分に研究された優れた本でさえ、無知です。10 人のアジャイル/XP チームが Windows Vista を作成するには 12 年、ERP パッケージを作成するには 25 年かかると言われています。モジュール化の用語であるセグメンテーションについては、2009 年まで方法がないと述べています。役に立たないと思います。
私のポイントは次のとおりです。モデル/参照/例のソースを非常に慎重に選択する必要があります。有名人を過大評価したり、自分自身を過小評価したりしないでください。
これが私の経験で証明された私の助けです。
これは、どの属性がどの DB テーブルに割り当てられるか、どのプロパティ/メソッドがどのクラス/オブジェクトに割り当てられるかなどを決定するのとよく似ています。より深いレベルでは、家に家具を配置したり、棚に本を並べたりするのとよく似ています。あなたはすでにそのようなことをしました。ソフトウェアは同じです。大したことではありません。
まず「結束」を心配してください。たとえば、Books (Leo Tolstoy、James Joyce、DE Lawrence) は choesive です。(HTML、CSS、John Keats、jQuery、tinymce) はそうではありません。そして、物事を整理する方法はたくさんあります。分類学者でさえ、これに関していまだに深刻な論争を繰り広げています。
次に、「カップリング」について心配します。「シャイ」になりましょう。「見知らぬ人と話さないでください。」友好的になりすぎないでください。パッケージ/DB テーブル/クラス/オブジェクト/モジュール/ブックシェルフをできるだけ独立した自己完結型にするようにしてください。Joel は、すべての外部依存関係を嫌い、独自のコンパイラを構築した Excel チームへの称賛について語っています。
于 2010-03-02T03:18:55.073 に答える
0
実際には、作成するプロジェクトごとに異なりますが、例を次に示します。
coreパッケージには、プロジェクトがないと生きていけないモジュールが含まれています。これには、アプリケーションの主要な機能が含まれる場合があります。uiパッケージには、ユーザー インターフェイスを扱うモジュールが含まれています。つまり、コンソールから UI を分割した場合です。
これはほんの一例です。そして、何をどこに行くかを決めるのは本当にあなたでしょう。
于 2009-07-22T22:16:23.927 に答える