設計が壊れ始めるとき、 コードの中では、 ある現象が必ず起きています。

それは、

判断が、コードのあちこちに散らばっている

という状態です。

判断とは何か

本書で言う「判断」とは、 if 文や条件分岐そのもののことではありません。

  • これは今やってよいのか
  • この順番で呼んでよいのか
  • この値を渡してよいのか
  • この状態で変更してよいのか

といった、 「やってよい／いけない」を決める責任 そのものを指します。

この判断が、 どこで行われているか。

それが、 設計の壊れやすさを決めます。

判断が構造として表現されていない場合、何が起こるか

判断が構造として表現されていない場合、 それは次の場所に押し出されていきます。

  • 呼び出し元のコード
  • コメントやドキュメント
  • コードレビュー
  • テスト
  • そして最終的には、人の記憶

この状態では、

  • 正しく使えるかどうかは人次第
  • 知っている人がいないと触れない
  • うっかりミスが即バグになる

という構造になります。

これは、 判断がコードの外に漏れ出している 状態です。

「レビューで防ぐ」は、設計ではない

よくある会話があります。

これはレビューで気づけますよね テストを書けば大丈夫ですよね

一見、正しそうに聞こえます。

しかしこれは、 設計でやるべき判断を、 後工程に押し出している だけです。

  • 書いてはいけないコードが書けてしまう
  • 実行してはいけない状態が表現できてしまう
  • 呼んではいけない順番で呼べてしまう

この時点で、 構造はすでに負けています。

レビューやテストは、 設計の代わりにはなりません。

良い設計は、判断を構造で表現する

良い設計では、 判断は 構造の中 にあります。

  • 正しい順番でしか呼べない
  • 不正な状態を表現できない
  • 間違った依存関係を書けない

こうした制約は、

  • 人が判断して守るもの ではなく
  • 構造が勝手に守るもの

です。

判断が構造で表現されると、何が変わるか

判断が構造に埋め込まれると、 コードの性質が変わります。

  • 書いていて迷わない
  • 正しい使い方が自然にわかる
  • 間違った方向に進もうとすると止められる

このとき開発者は、

  • 毎回考える人 ではなく
  • 構造に従う人

になります。

これは、 スキルが低いという意味ではありません。

思考を より価値の高い場所に使える という意味です。

判断が構造で表現されていないコードの特徴

判断が構造で表現されていないコードには、 共通した兆候があります。

  • 「ここは注意してください」というコメントが多い
  • 正しい呼び出し方が暗黙知になっている
  • 同じような if が何度も出てくる
  • テストでしか仕様がわからない

これらはすべて、

判断を構造として表現できていない サインです。

判断が構造で表現されると、コードは強くなる

判断が構造で表現されたコードは、 驚くほど壊れにくくなります。

それは、

  • 人が賢くなったから ではなく
  • 構造が判断を引き受けたから

です。

設計の仕事は、 人を信用しないことではありません。

人が間違えても大丈夫な構造を作ること です。

この章のまとめ

  • 判断は、必ずどこかに存在する
  • 構造で表現されない判断は、人に押し付けられる
  • 良い設計は、判断を構造で表現する
  • 判断が構造で表現されれば、コードは壊れにくくなる

次の章では、この「判断」を、

  • 状態
  • 依存関係
  • ライフサイクル

といった、 より具体的な構造の中で、 どう扱うかを見ていきます。