ソフトウェア開発の原則・法則

Scott W. Amblerの標準化の法則。標準化ガイダンスを再利用するためのスコープについての法則。

Industry standards > organizational standards > project standards > personal standards > no standards

業界標準 > 組織標準 > プロジェクト標準 > 個人標準 > なし
できる限りスコープの大きい標準を利用したほうがよい。

参考：AmbySoft Inc. Coding Standards for Java

• ダメな標準があることは、標準がないよりもずっと悪い。
• ダメな標準は、業界によって淘汰される。EJBがよい例。

参考：JavaWorld Dayでのロッドジョンソンの講演。

You Aren't Going to Need It.
あらかじめいろいろな事態にそなえて機能を盛り込んでおいても、結局利用されないことが多い。それどころか余計な複雑性を盛り込むことになる。
この無駄をなくすための指針。「それは必要にならない。」

Don't Talk to Strangers（知らないやつには話しかけない。）
メッセージの送信範囲を限定する。その指針は「直接依存するオブジェクトに対してのみ、通信を行う。」というものである。直接依存するオブジェクトは次の通り。
※便宜上、自オブジェクトのことを「自分自身」と記述する。

• オブジェクト自身
• 自分自身が属性として保持しているインスタンス
• 自分自身へパラメータとして渡されたオブジェクト
• 自分自身のメソッド内で生成したオブジェクト

上記のオブジェクト以外との通信を直接行わないことで、オブジェクト同士の無駄な依存関係を排除することが出来る。

Don't Repeat Yourself.
重複したコードを書かないこと。その考えに基づいて設計すること。変化に強く柔軟なシステムを構築するために重要な考え方である。
参考：Orthogonality and the DRY Principle

Keep It Simple Stupid
Keep It Simple and Small
可能な限りシンプルにすること。ソフトウェア開発に限らず、様々なシーンで利用されている原則。