Kent Beck が "Tidy First?" を昨年末に出版した。一見すると Refactoring/Tidying の Tips が詰まった薄い本のように見える。しかし、やはり Kent Beck とも言うべきか。彼の長年の経験と考察に裏打ちされた Software Design に対する哲学的問いの塊であり、その薄さとは裏腹に、読み解くのに長い時間を要する深遠な内容であった。
哲学というのは、答えのない問題に対して問いを提起する、という行為の繰り返しである。この本もまさしくその基本を体現しているように見える。「いつ Refactoring/Tidying するか」という一見簡単なように見える Software Engineering 上の問いに対して、どこまでも深堀りしていくという内容になっている。その答えは "It depends" であり、それで済ませることもできるのだが、かといって読者を置いてきぼりにせず、彼が経験を経て養ってきたフレームワークや考え方を紹介しながら、"So what?" を丁寧に紐解いていく優しい本でもある。
Part I は、明日から使える Tips の羅列である。非常に容易に読めて、すでに知っているような内容も多いことだろう。この章だけを読むと「Refactoring/Tidying のノウハウ本」にも読める。このパートの内容だけをつまみ食いして、明日からより良い Refactoring/Tidying をできる気にさせてくれる。しかし、このパートはあくまで序章である。
真の物語が始まるのは Part II からだ。このパートでは、「いつ Refactoring/Tidying するのか」という問いに対して、Chaining や Batch Sizes、Rhythm といったキーワードを紹介しながら読者と共に考えていく。パートの冒頭で以下のように語っているように、自分自身と対話していくプロセスでもある。
Tidying is software design addressing you, your relationship to your code, and ultimately your relationship with yourself.
そして、最後の Part III で物語が盛り上がる。クライマックスの盛り上がり方ではない、なぜならこの物語は本を読んだところで終わらないからだ。むしろ、本を読んだ後で、Tidying Software という深遠な旅が始まるとも言える。Part I では "What?"、Part II では "When?" を問いてきたのだが、最後で初めて "Why?" と向き合うことになる。
Software が価値を提供するのは、その振る舞いに変更を加えた時点である。新しい機能を追加したり、遅い機能を高速化したり、そうした時に初めてビジネス価値が生まれ、キャッシュ（お金）を呼び込む。したがって、Structural Change すなわち構造上の変更自体は、ビジネス価値を生み出すわけではない。Linting エラーを修正しているだけでは、株価は伸びないし、バランスシートは改善しない。
しかし、だ。明日リリースするために機能実装を最優先するだけでは、中長期視点で見た時のビジネス価値が損なわれる可能性もある。新機能を実装するために、足早に設計したデータ構造によって、来月実装すべきだった機能がリリースできなくなってしまったら？根本的なデータ構造の刷新を必要とするが故に、来年のロードマップに悪影響を与えてしまったら？
将来取るべき選択肢に制限を与えてしまう変更というのは、自分の首を絞めることに繋がる。その大前提としてあるのは「未来は予測不可能」という気づきであり、「この世界は不確実性に満ちている」という悟りである。その前提に立つならば、明日来る未来のために、可能な限り取れるオプションは残しておいた方が良い。
そこで Kent Beck はオプション理論と Software Architecture の交差点を指摘する。そしてここでいう「オプションを保持する」行為というのが、「Refactoring/Tidying することで明日の変更を容易にする」と言い換えられる。
the more volatile the environment is, the more valuable options become
ここで初めて「いつ・なぜ Refactoring/Tidying するか」という問いに向き合うことができる。この目の前の雑なコードベースを、今リファクタリングすることで、将来の変更容易性というオプションを手にすることができるのか？今リファクタリングすることのコストは、リファクタリング抜きで機能を実践する時のコストと比べてどちらが重いか？Tidy first, or not？
Kent Beck の一連の考察をなぞっていくことで、Refactoring/Tidying に必要なのは小手先の Tips だけではないという重要な点に気づかされる。それよりも大事なことは、まず自分とソースコードとの距離感であり、そのサービスのビジネスモデルと市場での立ち位置であり、そのサービスを実装するチームやマネジメントの人間関係であり、ひいては不確実な将来に対してどう向き合いたいかという戦略でもある。
デザインパターンを覚えたり、新しい Linting ルールを追加するだけでは、価値を生み出すことはできない。そして何より、中長期にわたって複雑性を増していくソースコードという怪物と向き合う覚悟がなければ、価値を継続的に生み出すことはできない。
この本を一通り読んだのだが、全く消化しきれていないことに気づいた。
London Tech Talk の Bookclub でちょうど今の本が読み終わるところだったので、次の本として "Tidy First?" を提案し、参加者が最低目安は集まりそうだったので来月から主催していくことにした。
他人との対話を通して、どこまで自分と向き合えるか。本を読んで知識を得て、コードを書いて経験を積み、他人と語って客観的に評価する、という三つの軸を、うまく回していくことができるだろうか。次のチャレンジである。