設計力とは、再現可能な判断の質である
ここまで本書では、
モノリスや設計改善という題材を通して、
さまざまな話をしてきました。
一見すると、
章ごとにテーマは違って見えるかもしれません。
しかし振り返ってみると、
私たちはずっと、
同じ対象に対して、別の角度から向き合ってきた
ことに気づきます。
それは、
判断 です。
本書でやってきたことを振り返る
各章で扱ってきた内容を、
「判断に対して何をしてきたか」という観点で整理すると、
次のようになります。
- 判断を 見つける
- 判断を 切り出す
- 判断に 名前をつける
- 判断を 動かす
- 判断の 変化を追う
章ごとに扱っていたのは、
構造でも、クラス分割でも、if 文でもありません。
判断そのものに、どう向き合うか
を扱ってきました。
判断を見つける
多くのモノリスでは、
判断はすでに存在しています。
ただし、
それは明示されていません。
if 文の奥に隠れていたり、
複数の条件に分散していたり、
暗黙の前提として人の頭の中にあったりします。
設計改善の最初の一歩は、
新しい構造を作ることではなく、
「ここには判断がある」
と気づくこと
でした。
判断を切り出す
判断に気づいても、
それがコードの中に埋もれたままでは、
扱うことができません。
そこで私たちは、
- 条件式
- 分岐
- ロジックの塊
から、
判断を切り出す
ということを行いました。
これは、判断を
「独立した存在として扱える状態」に
するための行為です。
判断に名前をつける
切り出された判断は、
まだ不安定です。
なぜなら、
名前がない判断は、
意味が固定されないからです。
- isEligible
- SpecialDiscountPolicy
こうした名前を与えることで、
判断は初めて、
- 何についての判断なのか
- どの文脈に属するのか
を語れるようになります。
名前をつけることは、
判断に意味を与えること
でした。
判断を動かす
判断に名前がつくと、
次に見えてくるのが
置き場所の問題 です。
その判断は、
本当に今の場所にあるべきなのか。
- 呼び出し側にあるべきか。
- ドメインのルールとして存在すべきか。
判断を
「よりふさわしい場所」へ移すこと。
それが、
モノリスを前にしたときの
最初の一手 でした。
判断の変化を追う
判断を動かしたあと、
すぐに構造全体を触りたくなる誘惑があります。
しかし本書では、
そこで一度立ち止まりました。
なぜなら、
判断がどう変わったのか
を追えなくなるからです。
小さな判断の変化を追うことで、
- 何が改善されたのか
- どこに次の一手を打つべきか
を自分たちの言葉で説明できるようになります。
判断を「説明できる」
ここまで、
判断を見つけ、
切り出し、
名前をつけ、
動かし、
変化を追ってきました。
もう一つ、
とても重要なことがあります。
それは、
判断を説明できるかどうか です。
コードがあっても、説明できない設計は多い
次のような説明を、
聞いたことはないでしょうか。
- 「昔からこうなっていて……」
- 「前の担当者がそうしていたので……」
- 「とりあえずこの条件が必要で……」
コードはあります。
動きもします。
しかし、
なぜその判断が存在するのか
を説明できません。
この状態では、
設計はすでに失われています。
判断を説明できるとは、どういうことか
「判断を説明できる」とは、
- なぜこの条件があるのか
- どんな状態を守ろうとしているのか
- 何が変わったら、この判断は変わるのか
これを、
コードを見せなくても言葉で話せる
状態のことです。
判断に所属があると、説明できる
isEligible の例を思い出してください。
class SpecialDiscountPolicy {
fun isEligible(user: User, order: Order): Boolean {
...
}
}
この判断は、
- 特別割引というルールに属している
- 割引の可否を定義している
と説明できます。
一方で、
if (canApplySpecialDiscount(user, order)) {
...
}
この判断は、
- どの概念の判断なのか
- 何を守るための条件なのか
を説明しにくい。
判断の置き場所が決まると、
説明の起点が生まれる
ということです。
説明できない判断は、再現できない
本書では、
設計力を
再現可能な判断の質
と定義します。
説明できない判断は、
再現できません。
- なぜそうしたのか分からない
- どこを真似すればよいか分からない
- 次の場面で応用できない
からです。
逆に言えば、
判断を説明できるようになった瞬間、
設計は他人に渡せるものになります。
設計力とは何だったのか
設計力とは、
特別なテクニックの集合ではありません。
- 正しい構造を一発で作る力でもない
- 複雑なリファクタリング手順を知っていることでもない
それは、
判断を扱う力 です。
見つけ、
切り出し、
名前をつけ、
動かし、
変化を追い、
説明できる。
この一連の行為を、
別のコードベースでも、
別の文脈でも、
繰り返せる。
それが、
再現可能な判断の質
です。
おわりに
モノリスは、
必ずしも悪ではありません。
ただ、
判断が見えなくなったとき、
理解不能な塊になります。
設計とは、
その塊に、
再び意味を与える行為です。
次にあなたが
大きなコードを前にしたとき、
構造を見る前に、
判断を探してみてください。
そこから、
設計はまた、
動き始めます。