プログラミングに関する原則、法則など

何かとこの辺を伝える機会が多いので、
自分への備忘録の意味も込めて。

---

■ DRY( Don't repeat yourself )
・重複を防ぐ考え方。

Wikipedia
http://ja.wikipedia.org/wiki/Don't_repeat_yourself

■ YAGNI( You ain't gonna need it )
・機能は実際に必要となるまでは追加しないのがよいとする考え方。

Wikipedia
http://ja.wikipedia.org/wiki/YAGNI

■ KISSの原則( Keep it simple, stupid )
・設計の単純性（簡潔性）は成功への鍵だということと、
不必要な複雑性は避けるべきだということであるという考え方。

Wikipedia
http://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87

■ SOLID原則
・単一責任の原則(SRP : The Single Responsibility Principle)
-> クラスを変更する理由は1つであるべき。

・ オープン・クローズドの原則(OCP : The Open Closed Principle)
-> クラスの振る舞いを変更せずに継承できるべき。

・リスコフの置換原則(LSP : The Liskov Substitution Principle)
-> 継承クラスは基底クラスの代わりになれないといけない。

・インターフェース分離の原則(ISP : The Interface Segregation Principle)
-> インターフェースはクライアントごとに細かく作る。 (クライアントが利用しないメソッドを持った太った
インターフェースは作ってはいけない)

・依存性逆転の原則(DIP : The Dependency Inversion Principle)
-> 実装に依存せず、抽象に依存しなくてはいけない。

Wikipedia
http://wiki.prvten.com/SOLID%E5%8E%9F%E5%89%87

■ デメテルの法則
・最小知識の原則
・基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点

　http://ja.wikipedia.org/wiki/%E3%83%87%E3%83%A1%E3%83%86%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87

■ 驚き最小の原則
・ユーザインタフェースやプログラミング言語の設計および人間工学において、インタフェースの2つの要素が互いに矛盾あるいは不明瞭だったときに、その動作としては人間のユーザやプログラマが最も自然に思える（驚きが少ない）ものを選択すべきだとする考え方である。

　http://ja.wikipedia.org/wiki/%E9%A9%9A%E3%81%8D%E6%9C%80%E5%B0%8F%E3%81%AE%E5%8E%9F%E5%89%87

■ ボーイスカウトの規則
アメリカのボーイスカウトは「自分のいた場所は、そこを出て行くとき、来た時よりもきれいにしなければならない」というもの。
プログラミングに当てはめると、チェックアウト（ソースコードを落とす）したときより、
チェックイン（ソースコードを反映）する時に綺麗にする。

　http://d.hatena.ne.jp/asakichy/20100706/1278377244

■ プログラマの心得
http://beginner-programer.hateblo.jp/entry/2013/10/27/062841

　・臆する事なかれ！
　・全力でサボれ！
　・知る事を楽しむ！
　・伝える事を楽しむ！
　・何がやりたいかをしっかり考える！
　・失敗は気にしない！

　・言い訳をしない。
　-> 関わった所は責任感を持つ。

　・新しい物に捕われない
　-> 様々な改善

・良きプログラミングの条件
　http://homepage1.nifty.com/x6/language/C/knowledge.htm

[ 製品の価値を高める ]
　・操作性
　・デザイン性
　・安全性
　・信頼性
　・長時間動作する
　・精度、性能が高い

[ 経費を抑える ]
　・コストパフォーマンス
　・開発効率（短い時間開発出来る）
　・保守性

■ エクストリーム・プログラミング
・軽量開発手法あるいはアジャイルソフトウェア開発手法と呼ばれる、
　同種の開発手法のなかで代表的なものである。
　柔軟性の高い開発手法であるが、古典的には開発が進むにつれ変更コストは大きくなると言うことを前提に開発手法が構築されているのに対して、自動テストを導入するなど様々な対策をすることにより開発が進んでも変更コストが大きくならないような工夫を持ち込むことにより、変更に対する柔軟性を実現している

何かのときにすっと出したい、プログラミングに関する法則・原則一覧
http://qiita.com/hirokidaichi/items/d6c473d8011bd9330e63?utm_source=Qiita%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9&utm_campaign=f58b219600-Qiita_newsletter_115_30_7_2014&utm_medium=email&utm_term=0_e44feaa081-f58b219600-32850825