Laws of Software Engineering¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
ソフトウェア開発でよく参照される法則・原則・経験則を、アーキテクチャ、チーム、計画、品質、スケール、設計、意思決定のカテゴリで整理した一覧サイト。 Conway's Law、Hyrum's Law、YAGNI、Brooks's Law、Gall's Law、Technical Debt、Testing Pyramid、Amdahl's Law、SOLID、Goodhart's Law などを横断的に確認できる。 個別の法則を深く読むというより、設計判断・チーム設計・見積もり・品質改善の観点を引き出すための索引として使える。
本文¶
著作権配慮のため全文転載はせず、確認用の構成メモを残す。
主なカテゴリ:
- Architecture
- Teams
- Planning
- Quality
- Scale
- Design
- Decisions
代表的な法則・原則:
- Conway's Law: 組織のコミュニケーション構造がシステム構造に反映される。
- Hyrum's Law: 利用者が多いAPIでは、観測可能な挙動が暗黙の契約として依存される。
- YAGNI: 必要になるまで機能を追加しない。
- Brooks's Law: 遅れているプロジェクトへの人員追加は、さらに遅延を招くことがある。
- Gall's Law: 動く複雑なシステムは、動く単純なシステムから進化する。
- Technical Debt: 開発速度を落とす設計・実装・運用上の負債。
- Testing Pyramid: 高速な単体テストを厚くし、統合テストやUIテストは必要な範囲に絞る。
- Goodhart's Law: 指標が目標になると、良い指標ではなくなる。
- Amdahl's Law: 並列化による高速化は、直列部分に制約される。
- SOLID: 保守性・拡張性を高めるオブジェクト設計原則。
要点¶
- 設計レビューや振り返りで「今どの法則に引っかかっているか」を考える材料になる。
qualityとplanningの法則は、見積もり・技術的負債・テスト戦略を説明するときに使いやすい。teams系の法則は、組織構造とアーキテクチャの関係を説明するときに使える。decisions系の法則は、技術選定やプロジェクト判断の失敗パターンを言語化するのに向いている。