はじめに
開発者としてプログラミングしていく中で、本記事にて紹介する原理原則を押さえておくことは非常に重要なことと感じたため、備忘録も兼ねて記載する。
1.DRY原則
Don't Repeat Yourself
同じ内容のコードを複数箇所に記載しない。
抽象化や共通化を用いて極力除去すべきであるという原則。
2.KISS原則
Keep It Simple, Stupid
シンプルなコードを書く。
自身だけでなく、誰が見てもすぐ理解できる状態をキープすべきであるという原則。
3.YAGNI原則
You Aren't Going to Need It.
今必要なコードを書く。
あとで必要なコードは使われないことが大半であり、工数が無駄になる。
4.車輪の再発明
既にあるものを作る皮肉
共通化されている処理やライブラリにあるようなコードを自身で作ることはやめようという原則。
「車輪」を知らないは「知識不足」なので知ることから始めよう。
5.プログラマの３大美徳
プログラマは「怠惰」「短気」「傲慢」であれ
「怠惰」
面倒・繰り返しの作業は自分でやらず、怠惰になれるようにプログラムで自動化すること。
そうすることで、全体の時間・労力が削減され、正確性も保証されます。
「短気」
コードが意図通りや効率的に働いていなかったら、短期になり、すぐに書き直すこと。
そうすることで、コードが常に正しく保たれます。
「傲慢」
誰に見せても恥ずかしくないコードを書き、責任を持つことで、仕事の成果について傲慢になること。
そうすることで、読みやすくシンプルなコードを保つことができます。
6. SOLID原則
S (Single Responsibility) 単一責任の原則
クラスは、単一の責任を持つべきだ。
この原則は、変更の結果としてバグが発生しても、他の無関係な動作に影響を与えないように、動作を分離することを目的としています。
O (Open-Closed) オープン・クローズドの原則
クラスは、拡張にはオープンで、変更にはクローズドであるべきだ。
この原則は、クラスの既存の動作を変更することなく、クラスの動作を拡張することを目的としています。
これは、そのクラスが使用されている場所でバグが発生するのを避けるためです。
L (Liskov Substitution) リスコフの置換原則
SがTのサブタイプである場合、プログラム内のT型のオブジェクトをS型のオブジェクトに置き換えても、そのプログラムの特性は何も変わらない。
この原則は、親クラスやその子クラスがエラーなしで同じ方法で使用できるように、一貫性を保つことを目的としています。
I (Interface Segregation) インターフェイス分離の原則
クライアントが使用しないメソッドへの依存を、強制すべきではない。
この原則は、動作のセットをより小さく分割して、クラスが必要なもののみを実行することを目的としています。
D (Dependency Inversion) 依存性逆転の原則
上位モジュールは、下位モジュールに依存してはならない。どちらも抽象化に依存すべきだ。
この原則は、インターフェイスを導入することにより、上位レベルのクラスが下位レベルのクラスに依存するのを減らすことを目的としています。
7.OAOO原則
Once And Only Once
同じコードを書かない。
DRY原則と同じ原則。