🧑‍🔧

ソフトフェア開発に関連した法則や原則のまとめ

2021/02/01に公開

ソフトフェア開発に関連した法則や原則を集めてみました。

法則・原則

ブルックスの法則

遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである

コンウェイの法則

システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう

パーキンソンの法則

仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する

マーフィーの法則

不都合を生じる可能性があるものは、いずれ必ず不都合を生じる

ハインリッヒの法則

1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在するというもの

ランスの法則

「壊れていないなら直すな」(If it ain’t broke don’t fix it.)

90対90の法則

コードの最初の90%が開発時間の90%を占め、残りの10%がさらに90%を占める

KISSの法則

「Keep it simple, stupid.」(シンプルにしておけ!この間抜け)

DRYの原則

Don’t Repeat Your Self:繰り返しを避けること

割れ窓の法則

建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」

パレートの法則

全体の数値の大部分は、全体を構成するうちの一部の要素が生み出しているとした。
[

パーキンソンの凡俗法則(自転車置場の議論)

組織は些細な物事に対して、不釣り合いなほど重点を置く

ハンロンの剃刀

無能で十分説明されることに悪意を見出すな

https://ja.wikipedia.org/wiki/ハンロンの剃刀

ポステルの法則

送信するものに関しては厳密に、受信するものに関しては寛容に」という、通信における設計原則である

スタージョンの法則

どんなものも、その90%はカス(crud)である

ピーターの法則

あらゆる有効な手段は、より困難な問題に次々と応用され、やがては失敗する

ホフスタッターの法則

いつでも予測以上の時間がかかるものである — ホフスタッターの法則を計算に入れても。

ケルクホフスの原理

暗号方式は、秘密鍵以外の全てが公知になったとして、なお安全であるべきである。

リーナスの法則

目玉の数さえあれば、どんなバグも深刻ではない

メトカーフの法則

ネットワーク通信の価値は、接続されているシステムのユーザ数の二乗(n2)に比例する

ムーアの法則

半導体の集積率は18か月で2倍になる

ビル・ジョイの法則

プロセッサーの最大性能は1年単位で毎年倍増する

ギルダーの法則

通信網の帯域幅は6ヶ月で2倍になる

ヴィルトの法則

ソフトウェアは、ハードウェアが高速化するより急速に低速化する

フィッツの法則

目標に到達するまでの時間は、目標までの距離と目標の大きさに依存する

ヒックの法則

意思決定にかかる時間は、可能な選択肢の数に依存する

デメテルの法則(最小知識の原則)

基本的な考え方は、任意のオブジェクトが自分以外(サブコンポーネント含む)の構造やプロパティに対して持っている仮定を最小限にすべきである

驚き最小の原則

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

ボーイスカウトの規則

来た時よりも美しく

YAGNI

You ain't gonna need it"[1]、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよいとする

SOLID

単一責任の原則(Single responsibility principle)

1つのクラスは1つだけの責任を持たなければならない。すなわち、ソフトウェアの仕様の一部分を変更したときには、それにより影響を受ける仕様は、そのクラスの仕様でなければならない。

開放閉鎖の原則(Open–closed principle)

「ソフトウェアのエンティティは(中略)拡張に対して開かれていなければならないが、変更に対しては閉じていなければならない。」

リスコフの置換原則(Liskov substitution principle)

「プログラムの中にある任意のオブジェクトは、プログラムの正しさを変化させることなく、そのサブクラスのオブジェクトと置換できなければならない。」

インターフェイス分離の原則(Interface segregation principle)

「汎用的な目的のインターフェイスが1つだけあるよりも、特定のクライアント向けのインターフェイスが多数あった方がよりよい。」

依存性逆転の原則(Dependency inversion principle)

「具体ではなく、抽象に依存しなければならない」

言い出しっぺの法則

最初に提案した人間が実行するべきであるという理念。

グッドハートの法則

計測結果が目標になると、その計測自体が役に立たなくなる

正常性バイアス

自分にとって都合の悪い情報を無視したり、過小評価したりしてしまう人の特性のこと

確証バイアス

仮説や信念を検証する際にそれを支持する情報ばかりを集め、反証する情報を無視または集めようとしない傾向のこと

ハロー効果

ある対象を評価する時に、それが持つ顕著な特徴に引きずられて他の特徴についての評価が歪められる現象

バンドワゴン効果

ある選択肢を多数が選択している現象が、その選択肢を選択する者を更に増大させる効果

参考URL

ソフトウェア開発にまつわる法則や原則いろいろ

ソフトウェア開発の法則

何かのときにすっと出したい、プログラミングに関する法則・原則一覧

開発の現場にまつわる法則

Discussion