プログラミングの法則
こんにちは、かねこです。
まえがき
世の中にはプログラミングの法則というものがありまして、知っていると知らないでは、コーディングの効率性や保守性に大きな差が出るような代物なので、代表的なやつを書いてみよう。
で、これが言われてみれば当たり前のことなのですが、時間や制約との戦いの中でコードかいてるとしれーっと知らないフリをしてしまったりするのです。
人間て困ったもんだ。
KISS
Keep it simple, stupid！（シンプルにしておけバーカバーカ！）ということで、不必要な複雑さは排除しましょうということです。
これは、ソフトウェア界隈の言葉だと思ってたんだけど、Wikipediaを見ると、かなり昔の1900年代前半くらいに、戦闘機設計の世界で生み出された言葉だった。
あたりまえのことだけど、意識していないと意外と忘れてしまうのです。
DRY
こちらは、Don’t repeat yourself（繰り返しちゃだめ！）てことです。コピペしたらダメよ。
DRY原則を意識しつつ、どの部分をあえて冗長化するかというところが腕のみせどころであります。
YAGNI
You ain’t gonna need it！（そんなもん作っても、必要にならねぇ）です。将来使うかも！って思っても我慢して、使うときに書きましょう。
このあたりは、Javaの標準API作ってる人たちとかすごいなーと思うところですね。
書いたけど使わなくなったメソッドも、きちんと消しましょう。過去の遺産はCVSがきちんと管理していてくれるのです。
開放閉鎖原則
別名、オープン・クローズドの原則。拡張に対して開いており、修正に対しては閉じていなさいという原則です。オブジェクト指向の大原則で、カプセル化・ポリモフィズムのベースになっている考え方です。
要は、OOPの場合、利用者はインタフェースのみを知っていればよく、内部構造を把握する必要がない。また、インタフェースを知っていることで、将来的な動作の変更や仕様拡張が容易になるのである（エヘン）
SoC
Separation of Concerns（感心事の分離）。
これは、いろいろな観点があるのだけれど、たとえばMVCとかオブジェクト指向のクラス化とか。どのモデルに基づいてアーキテクチャを設計するかとか。そういうの。
境界を明確化した設計を心がけましょうということです。
DIP
Dependency Inversion Principle（依存関係逆転の原則）
Java界隈では標準的な考え方になっているやつで、オブジェクトがそれぞれ個別にいろいろなオブジェクトを管理して強い依存を抱えるのではなく、サービスの利用時に別の誰かからオブジェクトを自動的に受け取ることで、オブジェクト同士の結びつきを切り離しましょう。という考え方です。
COC
Convention over Configuration(設定より規約)。設計で縛ってコード内に余計な情報を持たせるよりは、規約に基づいたアーキテクチャで単純化と柔軟性の確保を図る。
RailsとかCakePHPとか。
Law of Demetre
Law of Demetre (LoD, デメテル先生のありがたいおことば、と思ってたら違った。デルメルは女神様の名前らしい)。オブジェクト・コンポーネントは知らない奴には話しかけないということです。
オブジェクトが知っている奴とは具体的に、
・自分自身
・オブジェクトのメソッドが渡されたオブジェクト
・オブジェクトのメソッド内でインスタンス化したオブジェクト
・自分自身が保有しているオブジェクト
つまり、連鎖したドット（や、->とか）でメソッド呼び出すなてことですが、
最近のメソッドチェーンとかのパラダイムと反するとこがわりとあるね。ケースバイケース。
90%対90%の法則
前述の一連の法則とちょっと違くて、「コード全体の90%を記述するのに10%の時間がかかり、残り10%を記述するのに90%の時間がいるよ。というありがたいお言葉です。」
最近は、最初の90%をいかに早く記述するかというところは、フレームワークが吸収してくれる部分が多くて、本流の処理に集中しやすくなっています。
ありがたやー
まとめ
せっかく有用な標識があるので、見落としませんように・・・
かねこ
