プログラミングを含め、システム開発全般に関わる原則や法則、理論を纏めました。

目次

OAOO原則
DRY原則
驚き最小の原則
ブルックスの法則
デメテルの法則
ヴィルトの法則
コンウェイの法則
逆コンウェイの法則
割れ窓理論
ボーイスカウトルール
YAGNIの法則

OAOO原則

「Once And Only Once」の略です。
プログラミングにて、同じ処理を行う際は似たソースコードを何度も書かずまとめなさいという考えです。

DRY原則

「Don't Repeat Yourself」の略です。
同じ情報を複数の場所に重複して置かないようにするという考えです。
同じ情報が複数の場所にあると、修正が発生した際にその情報の数だけ修正が必要になり、
抜けや修正ミスが発生する可能性が高くなります。そのため、同じ情報は一箇所で管理すべきという原則です。
OAOO原則と似ていますがOAOO原則よりも含意が広く、DRY原則はシステム全体としての意味合いが強いです。なので、ドキュメントやDB設計にもDRY原則があてはめられます。
ソースコードの例でいうと、「そのコードが何をしているか」を記載しているコメントもDRY原則違反になります。ただ、コードからでは読み取れない意味のある補足情報はDRY原則違反にはならない。
※ソースコードとコメントで情報が異なるため。

「DRY原則を早まって適用しないこと」をGoogleが呼びかけていました。
共通化しすぎている箇所は分岐が多くなりがちで、逆に改修の難易度が上がる場合もありますね。
https://gigazine.net/news/20240605-google-not-dry-prematurely/

驚き最小の原則

「利用者にとって、できる限り驚きの少ない設計を心がけましょう」という原則です。
たとえば、プログラムでも変数名がマジックナンバーになっていたり、
メソッドでメソッド名とは異なる処理を行っていたりすると驚きは強くなります。
プログラム以外にも当てはまりますが、
このように相手にとっての驚きを最小限に抑える選択をするべきという考えです。

ブルックスの法則

遅れているプロジェクトに要員を追加すると、プロジェクトをさらに遅らせてしまうという法則です。
遅れてしまう理由としては、プロジェクトに慣れるまでの時間が必要なことや、
情報連携のために既存メンバーの工数も多くかかってしまうこと、などが挙げられます。

デメテルの法則

最小知識の原則ともいわれます。
クラス間の結合度はなるべく減らした方が良いという原則です。
クラス間の結合度が高くなると、ユニットテストが難しくなったり (モックを多く作成しなくてはいけない等)、改修の際の影響範囲が広くなり、デグレが起きやすくなります。

ヴィルトの法則

「ソフトウェアは、ハードウェアが高速化するより急速に低速化する」という法則です。
ハードウェアが進歩しても、ソフトウェアの速度は変わらないように感じるということです。

コンウェイの法則

「システム設計は、組織構造をそっくり反映させたものになる」という法則です。
例えば、システム同士を結合する際、チーム同士で上手くコミュニケーションが取れていないと結合が難しくなります。
このように、コミュニケーションがうまくいっていない領域のシステムは問題点が多くなってしまいます。

逆コンウェイの法則

コンウェイの法則を元に考えられました。
コンウェイの法則に縛られてしまうのなら、
逆に実現したいシステムアーキテクチャーに合わせて組織体系をつくればよいという考えです。

割れ窓理論

割れている窓をずっと放置さていると、他の窓も割られやすくなるという理論です。
プログラムも、設計やコードの観点で悪い箇所が数箇所あり放置されていると、
改修を行う際も「悪いコードを書いてもいい、なぜならすでに汚いから」という考えになってしまい、その結果品質が下がりやすくなってしまいます。

ボーイスカウトルール

コードを「来たときよりも綺麗にしよう」というルールです。
よく上げられる例として、「自分が来た時にキャンプ場が汚くなっていて、汚したのが自分ではなくても、キャンプ場を綺麗にしてからその場を去る」というものがあります。
それをプログラミングに当てはめた考え方です。
「コードをチェックアウトした際、一か所でよいからより美しくしてチェックインする」という考えが開発メンバーにあると、少なくとも品質が今より落ちることはありません。
新しいコードを書く場合も、もちろん美しく書きます。
たとえ少しずつでもモジュールを改善する努力を続けると、遠くない未来、今よりモジュールの品質が高まっています。

YAGNIの法則

「You Aren't Going to Need it」の略です。
コードを書く際に、「これは後で必要になりそう」という部分は、今は書いてはいけない、という法則で、
「実際に必要となるまでは追加しない方がよい」という考え方です。
汎用性や拡張性を意識しすぎてしまうと、YAGNIの法則違反になってしまう可能性があります。
この法則が提唱されるのは、以下のような理由があります。

後で使うだろうと予測して書いても、結局その10％くらいしか後で使われない。そのため、費やした時間が無駄になる
必要以上の機能を追加すると、設計部分が複雑になってしまう (コードも無駄に複雑になってしまう可能性がある)