Kent Beck, (訳)吉羽龍太郎, 永瀬美穂, 細澤あゆみ
あらすじは以下の通り。
乱雑なコードは厄介です。コードを読みやすくするには、管理できる小さなまとまりに分割する必要があります。本書は、エクストリームプログラミングの考案者で、ソフトウェアパターンの先駆者であるケント・ベックが、システム全体の構造を念頭に置き、コードを改善するには、いつどこで整頓するのがよいかを解説します。
整頓のしかたを一気に習得するのではなく、整頓を少しずつ試しながら自身の課題解決につなげます。コード行数の多い大きな関数については論理的にコードを小さなチャンクに分割する方法を学び、その過程で、結合、凝集、ソフトウェアシステムの経済的価値（ディスカウントキャッシュフローやオプショナリティ）などソフトウェア設計の背後にある重要な要素を解説します。また、ソフトウェア設計の基礎理論とそれに作用するフォース、システムにおけるふるまいの変更と構造の変更の違い、先に整頓したりあとに整頓することによるプログラミング体験の向上、大きな変更を小さく安全な手順で始める方法、ソフトウェア設計を人間関係のエクササイズとしてとらえることなどを学びます。
タイトルに「Tidy First?」とあるように、乱雑なコードをいつ・どのように整頓するかを判断するための指針を提供する本。タイトルが疑問形であることからも分かるように、その答えは「（大抵はそうだが）状況による」。
内容は著者 Kent Beck が Substack で投稿している小さな記事を集めたもので、一つ一つの章は非常に短く 2-4 ページにまとまっている。人によっては1時間ほどで読めてしまう分量だと思う。本書は全3部作予定の1冊目で、一人のプログラマーが可能な範囲でのコード設計の改善を主題としている。第2作では一緒にソフトウェアを設計するチームを、最後にはソフトウェアに関わるステークホルダー全体を扱うようだ（参考）。
著者が本書を出版することになった動機は、大学生の頃に読んだ「Structured Design（邦訳: ソフトウェアの構造化設計法）」という教科書を現代向けに調整することにある。同書によれば、ソフトウェアの複雑度を決める要素は以下の3つに集約できる。
どのような部品で構成されているか
部品同士がどのように結合しているか
個々の部品がどれくらい凝集しているか
ソフトウェアの複雑度が低い方が変更を加えやすい（≒ 価値を生み出しやすい）から、プログラマーは周囲に与えられた条件に応じて「結合」や「凝集」を設計する。結合や凝集は条件の変化に対応して変更していく必要があり、これを怠るとコードは乱雑になっていく。
著者によれば、ソフトウェアが価値を生むためには2通りの方法がある。
今日ソフトウェアが行うこと
明日ソフトウェアに行わせることができそうな新しいこと
前者を「振る舞い」、後者を「構造」と呼ぶ。振る舞いは例えば商品を予約購入したり従業員の給与を自動計算するなどの機能を指し、構造は次にどのような振る舞いを実装できるかを指す。構造の変更は直接的に付加価値を生み出していないように見えるが、これは金融の世界でいう「コールオプション」と同じでそれ自体に価値がある。
例えばストックオプションを題材にオプションの性質を考えてみる。ストックオプションは、事前に定められた価額で将来のある時点における株式を取得することができる一種のコールオプションである。株価が上昇すれば差額分の利益を得ることができるし、株価が下がった場合はオプションを行使しなければ損失を被らない。ストックオプションの価値は基本的に原資産の価格、行使価額、行使可能期間、株価の変動率、無リスクの金利などで決まる（本当は他にも要素があるのだが、本題とずれるので割愛）。
同様に、構造つまり「ソフトウェアに将来どのような振る舞いを実装可能かどうか」はある種のコールオプションと表現できる。これは以下の特徴を持つ。
実装可能な振る舞いが多いほどオプションの価値が高まる
ポートフォリオにある個別の振る舞いの価値が大きいほどオプションの価値も高まる
実装するまでオプションを残しておく限り、ポートフォリオにあるどの振る舞いの価値が最大となるかを気にする必要はない
開発を長く続けるほどオプションの価値は高まる
価値予測の不確実性が高ければ高いほどオプションの価値は高まる
本書に書かれていることはどれも経験的に納得できる内容で、個人レベルと銘打っているだけあってすぐに実践することができそうだ。既存のプロジェクトのコードに向き合いどのような方針で品質向上やリファクタリングをしていくか考える上で指針を提供してくれる本だった。