簡単よりも単純を選択せよ
1. 原則
簡単よりも単純を選択せよ
- 仕組み作りの意思決定においては単純さを維持することを優先するべし
- 見掛け上の簡単さの為に単純さを犠牲にしてはならない
- 簡単とは少ない手数で最大の利益を得られるような設計または方針
- 単純とは覚えること（把握すること）の少なさを重視
Easy: 手数の少なさを重視（そのかわり覚えることが増え、特定の状況には強いが他には弱い設計になる）
Simple: 覚えることの少なさを重視（そのかわり手数が増えたり、自分で組み合わせたりしなければならない）
2. 根拠
単純であることと簡単であることは異なる
- 複雑な機能を簡単なUIで隠蔽したものを「簡単」と定義する
簡単はブラックボックスを作りがち
- 複雑な仕組みを簡単なインターフェイスで隠蔽すると、実際に内部で動いている仕組みをブラックボックス化することになる
- 簡単なインターフェイスが上手く機能している間は問題無いが、いざ問題が起きた時に手も足もでないというリスクを抱える事になる（将来的/潜在的なリスク要素）
下位レイヤーを知らないエンジニアが破滅的な行為にでる
- 下位層を知らなくても良いのだ」と考えるというメンバが開発してしまうことで、破壊的なダメージをもたらす、という
簡単（Easy）はトレードオフにしている
- 簡単であることはその裏側にある複雑さを隠蔽するものが多い（一般論）
- 単純さは構成要素を分解し、単一用途に特化させたモジュールの集合で構成される（事が多い）
- 単純な機能で構成される仕組みは構成要素の多さから見かけ上複雑に見える（実際に複雑な相互作用を持つことも多い）
- 簡単にする為に複雑さを隠蔽すると「簡単」の領域を超えた場面で手に負えなくなる
単純性という品質は一度失われると取り戻すことが困難
- 単純なものは強い
- 簡単なものは便利だが土台から崩壊することが多い
3. 指針
仕組みを隠蔽しない
無闇にまとめない
作り過ぎない
4. 注意
抽象化の匙加減を見極める
- 複雑な仕組みを抽象化して「簡単」にすること自体は間違いではない
- 抽象化の破れが発生した時に手も足も出なくなるような事態を避けなければならないという話である
- 「簡単」にすることで使用者が仕組みを理解することを放棄するようなデザインは避けるべきである
参考資料
- SimpleとEasyは違う / Simple is not Easy - Speaker Deck
- "simple"と"easy"はどう違う？ Simple Made Easyを解説 Part1 - ログミーTech
- 技術選定の審美眼 / Understanding the Spiral of Technologies - Speaker Deck
- シンプルさの必要性 | eed3si9n
- 漏れのある抽象化の法則
Appendix-1 事例
事例1: ASP.NET
- かつてマイクロソフトが提供している.NETフレームワーク向けのWEBアプリケーションフレームワーク
- マイクロソフトの名作IDEであるVisual StudioのようにUIコンポーネントをドラッグ＆ドロップで配置することでGUIベースで画面を作成することができ、HTMLとCSSとJavaScriptを上手く隠蔽しているように見えた
- しかし、開発を進めているとどうしてもHTML/CSS/JavaScriptを直接触らなければならない場面もあり、そのような場面ではASP.NETとHTML/CSS/JavaScriptの知識、それらの関連性を理解する必要があり、それなりに高度な知識が必要とされた（大抵の場合、経験が浅いエンジニアには手に負えなかった）
- その後、RoRやそのフォロワーのようにHTML/CSS/JavaScriptを隠蔽しない「素直な」MVCアーキテクチャを採用したフレームワークが覇権を握り、ASP.NETは主流にはならず現在に至る（似たようなコンセプトのフレームワークもあまり流行らなかった）
- 広い範囲のレイヤーを抽象化しようとしたことが失敗だったと考えられる
事例2: O/Rマッパー
- RDBMSへのアクセスを抽象化するライブラリ
- SQLを記述せずともRDBMSの操作を行えることがセールスポイントだったが、現実にはクエリのパフォーマンスチューニングがしたくなったり、ちょっとした小技を効かせたい時には結局生成されたSQLを見る必要がある
- O/Rマッパーが生成するクエリの癖とSQL自体の知識が要求されるので最終的な学習コストはO/Rマッパーを使わない場合よりも高くなる傾向にある
関連
- KISS原則
- 一つのプログラムは一つのことをうまくやらせる
- 早まった最適化