# 設計の一貫性 ## 定義 設計における一貫性(consistency)とは、似たことは似たやり方で行い、似ていないことは違うやり方で行うという原則である。一貫性は複雑性を下げ、システムの挙動をより明白にする効果を持つ。効果の核心は認知的レバレッジで、ある箇所で一度学んだパターンの知識を、同じパターンが使われる別の箇所にもそのまま転用できる。一貫性が保たれていれば、開発者は見慣れた形から安全に推測でき、誤ったパターン適用によるミスも減る。適用対象は名前、コーディングスタイル、複数実装を持つインターフェース、デザインパターン、不変条件など多岐にわたる。 一貫性は確立に努力を要する一方、崩れやすい。プロジェクトに長く多くの人が関わるほど、あるグループの規約が別のグループに伝わらず、新しく加わった開発者は規約を知らずに違反し、既存の規約と衝突する新しい慣習を生んでしまう。一方で、一度確立した規約を書き換えるコストは高い。新しい規約の方が優れていても、対象コードを全て書き換えられなければ新旧の規約が混在し、かえって一貫性が損なわれる。つまり一貫性は、維持すること自体は(意識すれば)難しくないが、いったん崩れると完全な回復が難しいという非対称な性質を持つ。 一貫性を確保する具体的な手段として、(1) 規約を文書化して開発者の目に触れる場所に置く、(2) 自動チェッカーやコードレビューで違反を検出・防止する仕組みを作る、(3) 新しいコードを書く際は既存コードの構造を観察して倣う(「郷に入っては郷に従う」)、の3つがある。加えて著者は既存の規約を変えないことを強く主張する。新しい規約が「良いアイデア」であるだけでは変更の十分な理由にならず、(a) 旧規約策定時になかった重要な新情報があり、かつ (b) 全ての古い箇所を書き換える手間に見合うほど新規約が優れている、という二条件の両方に組織全体が同意できる場合に限り変更してよいとする。それでも他の開発者が新規約を知らずに旧いやり方を再導入するリスクは残るため、著者は規約の再検討は開発者の時間の使い方として滅多に見合わないと結論づけている。これは著者個人の強い立場であり、一般的な合意事項ではない(Source: [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 17 Consistency]])。 一貫性にはやりすぎの危険もある。表面的に似ているだけの異なるものを無理に同じ変数名や既存のデザインパターンに押し込めると、かえって複雑性と混乱を生む。一貫性が効果を持つのは、開発者が「xに見えるものは本当にxである」という確信を持てる場合に限られる(Source: [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 17 Consistency]])。 ## 横断的知見 - 第14章「命名」は名前における一貫性のベネフィットを扱っており、第17章はその議論を踏まえた上で、一貫性の適用対象を名前だけでなくコーディングスタイル・インターフェース・デザインパターン・不変条件にまで広げ、一貫性を確保する一般的な手段(文書化・強制する仕組み・郷に入っては郷に従う・既存規約を変えない)を論じている(Source: [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 14 Choosing Names]], [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 17 Consistency]])。 - 第18章「明白なコード」は、一貫性をコードを明白(obvious)にするための技法の一つとして位置づけている。一貫性が保たれたコードは読み手が見慣れたパターンから安全に推測できるため、明白さという上位の目標に貢献する手段として扱われている(Source: [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 18 Code Should be Obvious]], [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 17 Consistency]])。 ## 未解決の問い - 自動チェッカーで検出しにくい高レベルな設計上の一貫性(インターフェース設計やデザインパターンの適用が本当に妥当かの一貫性)は、どのような仕組みで強制できるか。 - 「新しい規約への十分な正当化」の二条件(新情報の有無・書き換えコストに見合う優位性)を、組織はどのような基準・プロセスで実際に判定しているか。 - 一貫性のやりすぎ(表面的類似に基づく誤った統一)は、本質的複雑性と偶発的複雑性のどちらに分類されるべきか。[[本質的複雑性と偶発的複雑性]] との関係は今後の ingest で検討したい。 ## 関連 - [[命名]] — 第14章が扱う、一貫性の一適用対象としての名前。 - [[ソフトウェア複雑性]] — 一貫性は複雑性を下げる手段の一つ。 - source: [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 17 Consistency]] / [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 14 Choosing Names]] / [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 18 Code Should be Obvious]] / [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 2 The Nature of Complexity]] - 実体: [[wiki/entities/A Philosophy of Software Design|A Philosophy of Software Design]] ## 出典 - John Ousterhout, *A Philosophy of Software Design*, Yaknyam Press, 2018, Chapter 17.