モジュールの結合

結合の基準
サイズ＝モジュール間結合の数
サイズは小さければ小さいほど良い。
・引数が１つのルーチンは引数が６つのルーチンより結合が弱い（サイズが小さい）
・４個のpublicメソッドからなるクラスは37個のpublicメソッドからなるクラスより結合は弱い

結合の可視化
・引数による結合は、グローバル変数による結合より明示的なので良い

結合の柔軟性
・モジュール間の結合が容易に帰られるほど柔軟性が高い
var employee = {'雇用日': , '職種': , ....};
に対して、雇用日と職種から休日を算出する関数は
function lookupVacationBenefit ( employee) { ... }
とするよりも、
function lookupVacationBenefit ( 雇用日, 職種 ) { ... }
にしたほうが、他のモジュールからも扱いやすくなる。
（過剰な情報伝達が悪になる例でもある）

結合の種類
○単純パラメータ結合
○単純オブジェクト結合
△オブジェクトパラメータ結合
×セマンティック結合

情報の隠蔽と変更の影響の最小化

指針
・情報を隠蔽し、内部構造は必要がなければ考えないで済むようにする
・変更が発生したときに、その影響を一カ所にとどめるようにする


具体的なプラクティス

・ユーザーとのやり取りをするコードを一カ所に集中させる

・マジックナンバーのハードコーディングは避け、定数として一カ所で定義する

・グローバル変数を避ける（必要以上のデータを渡さない）
・循環依存（AからBを参照し、BからもAを参照する）をしない
・変更されそうな部分を予測して、分離する
・状態変数としてブール型ではなく、列挙型を使う
・状態変数は直接参照せずに、アクセスルーチンを使い抽象化する
・他のモジュールへの依存度を減らし、疎結合（弱い結合）にする

ソフトウェア開発のノウハウ

前提：ソフトウェアの開発　＝　知的生産活動
（１）ビジョンステートメント

（２）仕様とアーキテクチャを固めるためのプロトタイピング
（３）スタートダッシュの２０％で８０％の完成を目指す
（４）頻繁なαリリース

前提：ソフトウェアの開発　＝　知的生産活動
クリエイティビティに１００％のコストが集中している。
そのため、どれだけ人数とお金を投入したところで、成果が全くでない事がある。
複数の行程に分割して、それぞれの作業コストを見積もるということも難しい。
大事なのはクリエイティビティ。

（１）ビジョンステートメント
最初に作ろうとしているソフトウェアが成し遂げようとしているビジョンを明確に定めて、それは明文化しておく。これを行うことによって、制作の途中で本来何をすべきだったかを忘れて迷走することを防ぎ、さらにはモチベーションを高めることができる。

（２）仕様とアーキテクチャを固めるためのプロトタイピング
実際に形にしてみないと、本当に必要な仕様や最適なアーキテクチャを理解できない。
つくっていく過程で「ここはこうしたい」「こうすれば他でもうまくいく」など新しいアイデアが生まれてくるのである。細部まで作ってからのアーキテクチャの変更は不可能に近いので、この段階で徹底的に妥協無しで作り直しをする必要がある。