判断は、どこに散らばっていくのか
設計が壊れる原因は、
判断が間違っていたからではありません。
多くの場合、
判断が散らばり、追えなくなったことが原因です。
この章では、
判断がどのようにコードベースの中に散在し、
やがて誰にも把握できなくなっていくのかを見ていきます。
判断は、いつも一か所に書かれるわけではない
一つの機能を実装するとき、
判断は一回で終わるわけではありません。
画面の責務をどう分けるか。
どこでデータを加工するか。
例外はどこで握りつぶすか。
将来増えそうな仕様を考慮するか。
これらは、
実装のあちこちで、少しずつ行われます。
しかもその多くは、
「判断した」という自覚すらないまま下されています。
判断は、気づかないうちに行われます。
条件分岐は、判断の化石である
コードの中で、
もっとも分かりやすい判断の痕跡は、条件分岐です。
if。
when。
早期 return。
それらはすべて、
「どちらを選ぶか」という判断の結果です。
なぜこの条件が存在するのか。
なぜこの分岐は統合されていないのか。
なぜここで例外にしているのか。
理由が分かるうちは、
その判断は生きています。
しかし理由が分からなくなった瞬間、
それは 判断の化石 になります。
コメントが消えたとき、判断も消える
判断を残す方法として、
コメントを書く人も多いでしょう。
しかしコメントは、
とても壊れやすい存在です。
リファクタリングで消される。
意味が古くなる。
「コードを見れば分かる」と判断されて削除される。
そしてコメントが消えると、
判断の前提も一緒に消えます。
残るのは、
なぜ存在するのか分からない構造です。
設計ドキュメントが読まれなくなる理由
「判断はドキュメントに書いてある」
というケースもあります。
しかし多くの現場で、
設計ドキュメントは次第に読まれなくなります。
なぜでしょうか。
理由は単純です。
コードとズレるからです。
仕様変更。
例外対応。
場当たり的な修正。
それらが積み重なると、
ドキュメントは「過去の判断」を書いたものになります。
そして人は、
今動いているコードを信じるようになります。
結果として、
判断はどこにも信頼できる形で残らなくなります。
判断は、人の頭の中に集約される
コードにも。
コメントにも。
ドキュメントにも。
判断が残っていないとき、
最後に残る場所があります。
それは、
特定の人の頭の中です。
「それは〇〇さんに聞かないと分からない」
「触る前に〇〇さんに確認して」
こうした言葉が出始めたとき、
判断は個人に閉じています。
その人がいる間は、
システムは動き続けます。
しかしその人がいなくなった瞬間、
判断は失われます。
属人化とは、判断が共有されていない状態である
属人化という言葉は、
しばしばスキルの問題として語られます。
しかし本質は、
スキルではありません。
判断が共有されていないことです。
同じコードを書けなくてもいい。
同じ発想ができなくてもいい。
なぜそうしたのかを、
追体験できれば十分です。
判断が共有されていれば、
設計は引き継げます。
判断は、なぜ散らばるのか
判断が散らばる理由は、
一つではありません。
速さを優先した。
とりあえず動かした。
全体を見る余裕がなかった。
チームが大きくなった。
どれも、
現場ではよくあることです。
重要なのは、
それ自体を責めることではありません。
判断は、意識しないと必ず散らばる。
この前提を持つことです。
この章のまとめ
設計が壊れるのは、
判断が間違っていたからではありません。
判断が、
コードの断片に散らばり。
理由を失い。
追えなくなった結果です。
次の章では、
この散らばった判断を、
どのように一つの軸で扱うのかについて、
話を進めていきます。