目次
概要
- はてブロでソフトウェア開発者が知るべき10の法則といういい記事があったのでそれの転載
- 他にも名前の知っている法則はGPTに手伝ってもらって書いた
法則や格言
コンウェイの法則 （Conway’s Law）
- メルヴィン・コンウェイが提唱した法則で、「システムの設計は、それを設計する組織のコミュニケーション構造を反映する」というもの
- つまり、組織内のコミュニケーションの仕方が、その組織が作り出す製品やサービスの設計に影響を与えるという考え方
パレートの法則 （Pareto Principle） / 80-10-10の法則
- ヴィルフレド・パレートによって提唱された法則で、「全体の結果の80%は全体の原因の20%によって生じる」というもの
- この法則はビジネス、経済学、品質管理など様々な分野で応用されている
グッドハートの法則 （Goodhart’s Law）
- チャールズ・グッドハートによって提唱された法則で、「指標として利用されると、その指標は効果を失う」というもの
- つまり、ある指標が目標達成のために使われると、その指標自体の意味が失われるという考え方
パーキンソンの法則 （Parkinson’s Law）
- サイリル・ノースコート・パーキンソンによって提唱された法則で、「仕事は与えられた時間いっぱいに広がる」というもの
- つまり、時間が多く与えられると、仕事が不必要に複雑化し、時間がかかるようになるという考え方
ブルックスの法則（Brooks’s Law）
- フレデリック・ブルックスによる法則で、ソフトウェアプロジェクト管理において、「遅れているプロジェクトに人員を追加すると、さらに遅れる」というもの
- これは、新しい人員の教育やコミュニケーションの負担が増加するため
リトルの法則（Little’s Law）
- ジョン・リトルによって提案された法則で、待ち行列理論において、「長期的に見た場合、システム内の平均在庫数は入力率と在庫滞在時間の積に等しい」というもの
- これは物流や製造業で重要な考え方
ピーターの法則（Peter Principle）
- ローレンス・J・ピーターによる法則で、「組織内では、従業員は自身の無能力のレベルまで昇進する」というもの
- つまり、能力があると認められた従業員は昇進し続け、最終的には自分の能力を超えるポジションに就くことになるという考え方
ハインリッヒの法則（Heinrich’s Law）
- H.W.ハインリッヒが提唱した、安全管理に関する法則で、「1つの重大な事故に対して、29の軽微な事故と300のノンインシデント（事故に至らないが危険な状況）が存在する」というもの
- この法則は、事故予防において、小さな事故や異常に注目することの重要性を示している
ピーク・エンドの法則（Peak-End Rule）
- ダニエル・カーネマンによって提唱された心理学の法則で、「人々は経験を、その最も強い感情があったピーク時と終わりの感情で評価する」というもの
- つまり、長い経験の全体よりも、特定の瞬間の印象が記憶に残るという考え方
ホフスタッターの法則（Hofstadter’s Law）
- ダグラス・ホフスタッターが提唱した法則で、「物事は予想よりも時間がかかる、たとえその予想にホフスタッターの法則を適用していたとしても」というもの
- これは、特にプロジェクトの計画や時間管理において、予測が困難であることを示している
メトカーフの法則（Metcalfe’s Law）
- ロバート・メトカーフが提唱した法則で、通信ネットワークの価値は、ネットワークに接続されているユーザーの数の二乗に比例するというもの
- 特にインターネットやソーシャルネットワークの成長と関連している
ムラフィーの法則（Murphy’s Law）
- 「何か悪いことが起こりうる状況があれば、いつか必ず起こる」という俗説
- 特に工学やプロジェクト管理において、リスク管理の重要性を示唆している
ダニング＝クルーガー効果（Dunning-Kruger Effect）
- 低い能力を持つ人ほど自分の能力を過大評価し、高い能力を持つ人は自分の能力を過小評価する傾向があるという心理学の現象
オッカムの剃刀 （Occam’s Razor）
- 複数の仮説がある場合、最も単純な説明が最も可能性が高いという原則
- 14世紀の哲学者ウィリアム・オッカムにちなんで名付けられた
ジェヴォンズの逆説（Jevons Paradox）
- リソースの効率的な利用がそのリソースの消費量を増加させるという経済学の原則
- 1865年にウィリアム・スタンレー・ジェヴォンズによって提唱された
- 資源効率を高めてもエネルギー消費量が増えるという逆説
クレイトンの破壊的イノベーション理論（Christensen’s Theory of Disruptive Innovation）
- 破壊的イノベーションは市場に革命をもたらし、既存の大企業を脅かす新しい技術やビジネスモデルを指す
- クレイトン・クリステンセンによって提唱された
ベンフォードの法則（Benford’s Law）
- 自然発生的なデータセットにおいて、小さい数字（特に「1」）が最初の数字として現れる確率が高いという法則
割れた窓の法則（Broken Windows Theory）
- 犯罪学の理論で、小さな犯罪や秩序の乱れ（例えば割れた窓）が放置されると、より大きな犯罪や社会の荒廃につながる可能性があるというもの
- ジェームズ・Q・ウィルソンとジョージ・L・ケリングによって提唱された
コンウェイの法則（Conway’s Law）
- ソフトウェア開発において、システム設計はその設計を行う組織のコミュニケーション構造を反映するという法則
- メルヴィン・コンウェイが提唱
エントロピーの法則（Law of Entropy）
- 物理学の第二法則に基づく概念で、閉じた系ではエントロピー（無秩序さ）が時間とともに増加するというもの
- これは物理学だけでなく、経済学や情報理論にも応用されている
ジョシュアツリーの法則（Joshua Tree Principle）
- ソフトウェア開発において、初期のアーキテクチャの決定がプロジェクトの将来の方向性と複雑さに大きな影響を与えるという概念
- ジョシュアツリーの成長パターンに例えられています。
セカンドシステム症候群（Second-system Effect）
- エンジニアが初めて成功したシステムに続いて設計する二番目のシステムが、過剰に複雑で非効率になる傾向にあるという現象
- フレデリック・P・ブルックスが『人月の神話』で記述
車輪の再発明（Reinventing the Wheel）
- 既に存在する方法やツールを知らずに、同じものを新たに作成すること
- しばしば無駄な労力と見なされるが、学習過程や改善には価値がある場合もある
ヤクの毛刈り（Yak Shaving）
- 本来の目標から逸れ、関連しない多くの小さなタスクに引き込まれてしまう現象
- この言葉は、ソフトウェア開発やプロジェクト管理で使われ、予期せぬ問題に対処する過程で目的を見失うことを示している
YAGNI（You Ain’t Gonna Need It）
- ソフトウェア開発における原則で、「現時点で必要ではない機能は実装しない」という考え方
- この原則は、開発の複雑さを減らし、不必要な作業を避けることを目的としています。
ドライ原則 （DRY - Don’t Repeat Yourself）
- ソフトウェア開発において、同じ情報やコードを重複させないことを推奨する原則
- この原則に従うことで、メンテナンスが容易になり、エラーのリスクを減少させることができる
KISS原則 （Keep It Simple, Stupid）
- 設計をシンプルに保つことを奨励する原則です
- 不必要に複雑な設計は、エラーや問題の原因になる可能性があるため、シンプルさを保つことが重要
ビッグデザインアップフロント （BDUF - Big Design Up Front）
- プロジェクト開始前に詳細な設計を行うアプローチ
- この方法は、計画性と予測可能性を重視しするが、柔軟性の欠如や変更への対応の遅さが批判されることもある
早まった一般化（Premature Generalization）
- ソフトウェア開発やデータ分析の分野でしばしば言及される概念
- これは、不十分な情報や経験に基づいて、広範な結論や決定を下すことを指す
オープン-クローズドプリンシプル（Open-Closed Principle）
- ソフトウェアのエンティティ（クラス、モジュール、関数など）は拡張に対してオープンであるべきだが、変更に対しては閉じているべきであるという原則
- つまり、既存のコードを変更せずに新しい機能を追加できるように設計すること
堅牢性の原則（Principle of Robustness）
- シンプルでクリアな設計を心掛けることで、予期せぬ状況にも強い、堅牢なシステムを作るという原則
最小電力のルール（Rule of Least Power）
- 効率的なソフトウェア開発において、必要最小限の能力（電力）を持つ解決策を選ぶべきであるという考え方
Unix哲学
- シンプルで小さなプログラムを書き、それらを組み合わせて大きなタスクを達成するという考え方
- プログラムは一つのことをうまく行うべきで、ユーザーに強力な組み合わせ能力を提供すべき
悪い方が良い（Worse is Better）
- ソフトウェア設計において、完璧よりも実用的でシンプルな解決策を優先する考え方
- これはNJの哲学の事
- c言語が買って、LISPが負けた事もこれに起因する
MITの哲学 vs. NJの哲学
- MITの哲学は"the right thing"
- NJの哲学は"Worse is Better"
- MIT哲学の優先順位
- Correctness = Consistency > Completeness > Simplicity (Interface) > Simplicity (Implementation)
- NJの哲学の優先順位
- Simplicity (Implementation) > Simplicity (Interface) > Correctness > Completeness > Consistency
SOLID（オブジェクト指向設計）
- ソフトウェア設計のための5つの原則のセット
次の5つを含む。
- 単一責任の原則
- オープン/クローズドの原則
- リスコフの置換原則
- インターフェース分離の原則
- 依存性逆転の原則
信頼できる唯一の情報源（SSOT, Single Source of Truth）
- ある種の情報について、その情報の正確で最新のバージョンを保持するためのシステムやプラクティスを指す
- この原則に従うことで、データの一貫性、正確性、信頼性が保たれ、データの重複や不一致を防ぐことができる
単一真実のバージョン（Single Version of the Truth, SVOT）
- 組織内の情報やデータに関して、その情報の一貫性と正確性を保証するためのアプローチ
- SVOTは、特定のデータに関して、その最も信頼できる、正確な、そして常に最新のバージョンが一箇所に存在し、
- 全ての関連するプロセスや意思決定がこのバージョンを基に行われるべきであるという考え方を指す
Nocode
- 信頼できるプログラムを作る方法は、プログラムを書かない事という哲学
- Dockerfileで
from scratchだけ書いたリポジトリでそれを示した
自分
ワンパスを通す
- システムで枝葉に拘らずに細くてもいいので一度全体を作り上げる法則
- 最低限の機能をざっくり作ってMVPを狙うと行ってもいいかもしれない
テストは依存性が無い所からテストする
- MVCのアプリケーションでテストを書く時は依存性が少ないところから書く
- すなわち、Modelから書くべし
- そうでないと、Controllerから書くとModelのテストの後にまたテストの修正をする二度手間になるから
QCDのうち一番大切なのはCとD
- アプリも命（ライフサイクル）がある。なので、アプリがビジネスとして役立って長生きする可能性もある
- しかし、その逆の可能性もある
- 故に、正直、お金がなくなったらプロジェクトやアプリは終わる
- ゆえに、QCDのうち、CとDが最も大切
- 特に速度、速度がないなら意味がない。変なアプリに3か月も待ってられない
- 実行速度はビジネスとしての仮説が検証されてお金を生み出すものと分かってからリファクタやリプレイスしてもいい
- とにかくDevSpeed。じゃないと作ってもゴミとなる
テストリポジトリで試す
- 本当にわけが分からないときはテストリポジトリを作る
- 条件を削って最低限度でテストしてみる
- めんどくさいが、これが一番確実
一行はemacs、複数行はvimバインドを使う
- emacsバインド、ctrl-a,e,k,uで操作できるので早い
- 複数行はvimバインドが速い
先に理解してから開発する
- 理解すれば作れる
- 逆に理解していないと作れない
- なので作る前に必ず理解する
技術調査でいい数字が出ない時の対処
- 使い方を変える
- シンプルに現状の使い方、課題では使えないが、別の使い方を考える
- 例えばある別の課題を解くための特徴を生成するための機能として使うなどという感じ
- 部分適用する
- 全体に適用はできなくても、部分適用ではいい数字を出す場合がある
- シンプソンのパラドックスパターン
- 例えば、全体では70%、これは使えない
- でも部分では、前提を絞ったら90%これは使えるなどという感じ
- 前提を変える
- 元々の数字がおかしいパターン
機械学習では80点を絶対狙う
- 30点をたたき出したら死刑宣告と同じ
- データの範囲を変えたり、指標を変えて80点を狙う
- それ以外は、異民族に蹂躙される
- 80点ならその後に90点を出されてもメンタルが持つ
- 30点から80点をだされたらメンタルブレイクする
- これは機械学習のスコア以外にもなんでも当てはまる
- 基本的にRecall -> Precisionと進む
見積もりと実際は大体3倍の差がある
- 不確実性のコーンから
- 見積から2倍から3倍の工数がかかる
まとめ
- まあ色々な法則があるし、他にも設計系の格言や法則は色々あるだろう
- ただし、経験上、あくまでこれらはrecommendationのレベル
- これらは経験則的なもので、first principleとまではいかない
- 適材適所でこれをベースに演繹して考えるのがいい気がする