シンプルに保つことは誰もが知っていますよね？
システム間の相互作用の数として複雑さが測定されるのを見てきました。直感以外に、特定の設計またはソフトウェアの複雑さのレベルを判断するために使用できる (できればより客観的な) 方法は何ですか?
あなたの好きなルールやヒューリスティックは何ですか?
7 に答える
3
複雑さは、カップリングと、すべてのオブジェクトの凝集度によって見積もることができます。何かが結合しすぎていたり、まとまりがなかったりすると、デザインはより複雑になります。
于 2008-10-31T15:07:14.700 に答える
3
これが私のものです：
1) 問題を理解しているが解決策を考えたことがない人に説明するのはどれくらい難しいですか? ホールにいる誰かに問題を説明し (その人がホールにいれば、おそらく既に問題を理解しているはずです)、解決策を説明できれば、それほど複雑ではありません。1 時間以上かかる場合は、ソリューションがオーバーエンジニアリングされている可能性があります。
2) ネストされた関数の深さはどれくらいですか? 別のオブジェクトが保持するオブジェクトが保持するプロパティを必要とするオブジェクトがある場合、私がやろうとしていることがオブジェクト自体から離れすぎている可能性が高くなります。オブジェクトをスレッドセーフにしようとすると、これらの状況が問題になります。これは、ロックする現在の位置からさまざまな深さのオブジェクトが多数存在するためです。
3) すでに解決済みの問題を解決しようとしていますか? すべての問題が新しいわけではありません (実際には何もないと主張する人もいます)。使用できる既存のパターンまたはパターンのグループはありますか? できないなら、なぜですか？独自の新しいソリューションを作成するのは良いことです。私はそれを大歓迎しますが、すでに問題に答えている人もいます。STL を書き直すつもりはありません (ある時点で試みましたが)。解決策は既に存在し、優れたものだからです。
于 2008-10-31T15:03:50.230 に答える
3
New England Complex Systems Institute ( http://necsi.org/ ) の Complex Systems Modeling ワークショップに参加したとき、彼らが使用した尺度の 1 つはシステム状態の数でした。
たとえば、相互作用する 2 つのノード A と B があり、それぞれが 0 または 1 の場合、考えられる状態は次のとおりです。
A B
0 0
1 0
0 1
1 1
したがって、バイナリ コンポーネント間の相互作用が 1 つだけのシステムは、実際には 4 つの異なる状態になる可能性があります。要点は、システムの複雑さは、相互作用の数が増えるにつれて必ずしも直線的に増加するわけではないということです。
于 2008-10-31T15:04:17.343 に答える
1
ファイルの数、構成が保存されている場所の数、一部の言語でのコンパイルの順序も適切な尺度となります。
例:
.- プロパティ ファイル、データベース構成、関連情報を保持するための xml ファイル。
.- インターフェイスとデータベース マッピングを備えた数万のクラス
.- 非常に長く複雑なビルド ファイル (build.xml、Makefile、その他..
于 2008-10-31T15:11:55.347 に答える
0
最後に、LOC が実際に測定に役立つものはありますか? :)
複雑さは、相互作用する必要があるものの数として最もよく見られると思います。
複雑な設計には n 層がありますが、単純な設計には 2 つしかありません。
シンプルさでは克服できない問題を回避するには、複雑さが必要なので、常に問題になるとは限りません。
複雑さには通常、それに関連するタスクがあるため、一般的に複雑さを定義する際に問題があります。理解するのは複雑かもしれませんが、見るのは簡単です (たとえば、非常に簡潔なコード) サーバーからコンピューターにこの Web ページを取得する相互作用の数は非常に複雑ですが、http プロトコルの抽象化は非常に単純です。
そのため、対策を選択する前にタスク (メンテナンスなど) を念頭に置いておくと、より便利になる場合があります。(つまり、構成ファイルを追加してアプリにログを記録すると、目的の複雑さが増します [ええ、少しだけ確かです] が、メンテナンスは簡素化されます)。
于 2008-10-31T19:08:02.233 に答える
0
アプリがビルドされている場合は、時間 (特定のタスクの実行にかかる時間) または計算 (タスクが実行されるたびに実行されるコードの量) の観点から測定できます。
設計がある場合は、特定のタスクを実行するため、または平均的なタスクを実行するために設計のコンポーネントがいくつ必要かを調べることができます。たとえば、設計パターンとして MVC を使用する場合、大部分のタスクで少なくとも 3 つのコンポーネントに触れますが、設計の実装によっては、最終的に数十のコンポーネントになる可能性があります (たとえば、3 層）。
于 2008-10-31T15:00:56.677 に答える
-1
于 2008-10-31T15:29:27.650 に答える