自分は仕事でプログラミングをすることがよくあります。Web関連であるのは共通しますが、言語も複数扱いますし、新規作成から既存機能の改修や保守と関わるフェーズも様々です。
プログラミングや開発には、色んな考え方や原理原則があり、関わるプロジェクトのメンバー内のルールになっていれば、迷うことは少ないです。（もちろん、迷うこともあり、相談できる相手に相談することは大事です。）また、プロジェクト立ち上げ時のルール未整備な状態で、考える基準が欲しいこともあります。
そんな時、世の中で言われているプログラミングの原則から引用することは一つの手段だと思います。プログラミングの原則は、一部にしか適用できないものから、全体的な考え方で設計思想に関わるものまであります。こういうものがまとまっているのは、確実に自分のためになるので、まとめていこうと思います。
YAGNI
"You ain't gonna need it"の略。「そりゃ必要にならんよ」てな意味。XP(エクストリームプログラミング)に関する格言で、必要になるまで実装するなという意味。ソフトウェア品質の拡張性に関わることではあるが、拡張性を意識しすぎて、無駄が多かったり、複雑化してしまうことによる損失の方が大きいということ。
ソフトウェア実装時の原則で、「今後こんなことが必要になるかも？」と考えて、本来実装しなくてよいことまで、実装してしまうことはよくないということ。
これに対する対策は、シンプルな設計、コードにすること。必要な機能は必要になった時に実装すればよい。
DRY
"Don't Repeat Yourself"の略。「同じことを繰り返すな」という意味。
同じコードを重複して書くなということなのだが、適応範囲はソースコードだけではなく、DBスキーマ、テスト、ビルドシステム、ドキュメントなども対象となる。そして、対象外として、冗長化やミラーリング、単体テスト、バージョン管理等が該当する。つまり、何でもかんでも適用すればよいという考え方ではない。
また、注意点として、DRYの原則によって共通化したことによる密結合が問題となることもある。密結合が進むと、影響範囲が大きくなり、修正の影響確認に時間がかかることがあり、悪影響が出ることもある。
同じだと認識できることは大事で、何をどこまで同じものとして扱うか、別物とするかは常に意識して考えていかなければならないと思わせてくれる、原則。
KISS
"Keep it simple, stupid" の略。「シンプルにしておけバカ」という意味。
設計でもプログラミングでも適応できる考え方で、その言葉のとおり、シンプルに、簡潔にしておくのが良いということ。
例えば、機能てんこ盛りで使われないシステムより、必要なものだけを実装するということ。また、YAGNIと重なる部分があるが、今必要ないものは、実装しないのがよい。
やはり、簡潔であることがよいことなのです。
SOLID
オブジェクト指向設計に関する原則の頭文字をとって「SOLID」とまとめられた原則集。５つの原則がある。
S：SRP Single Responsibility Principle（単一責務の原則）
「クラスを変更する理由は１つでなければならない」
そのままで、クラスに1つの責務（責任）を持たせるもの。例えば、プロパティの管理やDBの管理等。
裏を返せば、１つのクラスで複数のことをいくつも行おうとしているとき、注意して分離することが必要になる。
O：OCP Open/closed principle（開放閉鎖の原則）
「クラスは拡張に対して開き、修正に対して閉じていなければならない」
クラスの拡張とその修正に関わるもので、特定の構成要素に対する影響を最小限にする考え方。例えば、グローバル変数を使わない、インスタンス変数はすべてprivateにする等の根底にある考え方。
L：LSP Liskov substitution principle（リスコフの置換原則）
「サブクラスはそのスーパークラスで代用可能でなければならない」
スーパークラスで、そのクラスがどの型か？によって処理が分かれていると、この原則にNGとなる。そのため、必要なサブクラスに必要な処理を書くことで、この問題を解決することが可能です。
I：ISP Interface segregation principle（インターフェース分離の原則）
「クライアントが利用しないメソッドへの依存を強制してはならない」
インターフェースを設計する際、利用したクラスが共通で使用する必要があるメソッドを実装する必要があるということ。Aクラス、Bクラスで利用しているインターフェースIにAのみで使用するメソッドがあるのはNG。この場合、共通のインターフェースを利用するのではなく、別のインターフェースが必要。
D：DIP Dependency inversion principle（依存性逆転の原則）
「上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。」
柔軟なシステムの作り方の考え方。最も柔軟なのはインターフェースのみに依存している状態。
PIE
”Program Intently and Expressively”の略。「意図を表現してプログラミングせよ」という意味。
コードは意図を明確に表現するように書くということ。なぜ、そのような処理があるのか、そのように書いたのかが分かるようになっていることが、意図を明確にするということ。
また、可読性を上げるためのものなので、読みやすさを意識することになる。
SLAP
”Single Level of Abstraction Principle”の略。「抽象化レベルの統一」という意味。
コードを書くとき、高いレベルの抽象化概念(高水準なコード)と低いレベルの抽象化概念(低水準なコード)を分離するようにすること。外部公開されたユーザー側のコードは高水準なコードとなり、処理や計算、API利用に関わる非公開のコードは低水準なコードとなる。
高水準のメソッドの中に、低水準なメソッドが並んでいる状態はレベルが揃っているので、良い状態といえる。 構造化がポイントとなる。
SoC
”Separation of Concerns”の略。「感心事の分離」
いろいろな観点があるのだが、例としてはMVCとかオブジェクト指向のクラス化、どのモデルに基づいてアーキテクチャを設計するか等。
何をしたいのか毎に構成要素を構成するということ。
最後に
プログラミングの意図を事前に理解し、共有したうえでコーディングをすることで、簡潔で可読性が高く、保守性が高いコードが書ける可能性が高くなる。
また、どこにどのように気を付けるのがよいのか。先人たちが見出した考え方を学ぶのは知恵を取り入れることになり、有用だろう。
