設計について語ると、 必ず出てくる問いがあります。

設計は、いつやるべきですか？

この問いに対して、 よくある答えは曖昧です。

  • 最初にやりすぎてもダメ
  • 実装しながら考えるのが大事
  • 状況による

どれも間違ってはいません。 しかし、 判断基準が書かれていない のです。

本書では、 この問いに対して、 はっきりした答えを出します。

設計は「判断を構造に置く」タイミングでやる

設計をやるべきタイミングは、

判断を、人の頭から構造に移す必要が生じたとき

です。

つまり、

  • まだ判断が曖昧な段階
  • 仕様が流動的な段階

では、無理に設計を固める必要はありません。

しかし、

  • その判断が繰り返し使われ始めたとき
  • 複数人が触り始めたとき
  • 変更が入り始めたとき

その瞬間が、 設計のタイミング です。

実装前にやる設計、実装中にやる設計

設計には、大きく二種類あります。

実装前にやる設計

  • 境界の仮置き
  • 責任の大まかな分割
  • 依存関係の向き

これは、 「壊れ方を予測するための設計」 です。

正解を決めるためではありません。

実装中にやる設計

  • 判断が散らばり始めたとき
  • if が増え始めたとき
  • 呼び出し順が暗黙になったとき

このタイミングで行う設計は、

判断を構造として回収する行為 です。

これは、遅すぎると致命的になります。

「動くものを作ってから考える」の落とし穴

「まず動かす」は、非常に強力な考え方です。

しかし注意点があります。

動くものを作る過程で、

  • 判断を仮置きしたまま
  • 境界を曖昧にしたまま
  • 型で表現しなかったまま

進んでしまうと、

その仮置きが、事実上の設計になる からです。

動いているコードは、 心理的にも、 組織的にも、 直しにくくなります。

設計は「早すぎる」のではなく「深すぎる」と失敗する

設計が失敗する原因は、 早すぎることではありません。

深くやりすぎること です。

  • まだ存在しない判断
  • まだ使われない境界
  • まだ確定していない責任

これらまで構造に落とすと、 柔軟性を失います。

設計は、

  • 今、確実に存在する判断
  • すでに痛みが出ている判断

だけを、構造に置く行為です。

良い設計は「観測してから行う」

設計が上手な人ほど、 すぐに決めません。

代わりに、

  • どこで迷っているか
  • どこで判断が繰り返されているか
  • どこで壊れやすいか

を 観測 します。

設計とは、 思いつきではなく、 現象への対応 です。

設計をやるべきサイン

次の兆候が出たら、設計のタイミングです。

  • 同じ判断が何度も出てくる
  • 正しい使い方を説明しないと伝わらない
  • テストが前提条件だらけになる
  • 修正時に触る範囲が読めない

これらはすべて、

判断が構造に置かれていない サインです。

設計は、一度で終わらない

設計は、一度やって終わりではありません。

  • 判断が増えたら
  • 状態が増えたら
  • 境界が変わったら

再び、構造を見直す必要があります。

ただし、

毎回ゼロからやり直すわけではありません。

良い設計は、 変更に耐えながら、 少しずつ形を整えていきます。

設計を「後回し」にしてよいケース

すべてを設計する必要はありません。

次のような場合は、後回しで問題ありません。

  • 一度きりの処理
  • 実験的なコード
  • 捨てる前提の実装

重要なのは、 後回しにしていると自覚しているか です。

無自覚な後回しが、最も危険です。

設計とは、タイミングの技術である

設計は、才能ではありません。

判断を見極める技術 です。

  • 今か
  • まだか
  • ここか
  • もっと内側か

この見極めができるようになると、 設計は怖くなくなります。

この章のまとめ

  • 設計は、判断を構造に移すときにやる
  • 実装前は「壊れ方を予測するための設計」
  • 実装中は「判断を構造として回収する行為」
  • 早すぎるのではなく、深すぎると失敗する
  • 設計は観測してから行う
  • 設計はタイミングの技術である

次の章では、ここまでの概念を使って、

「設計ができる人と、できない人の違い」

を言語化していきます。