読んだ本の内容はすぐに忘れてしまうため、重要だと思ったポイントを整理して備忘録として残しておきます。
「汚いコードは見つけ次第直すべきか？」 この問いに対し、Kent Beckの新著『Tidy First?』は「究極的にはケースバイケース」という、エンジニアなら誰もが納得（あるいは落胆）する経験主義的な立場をとります。
しかし、そこで思考停止せず「いつ、どう判断すべきか」の基準を、コストの観点から明確に示してくれたのが本書のハイライトです。
タスク実行時の判断
機能追加やバグ修正を行う際、必ず「ついでにここも直したい」という誘惑に駆られます。 しかし、機能変更（振る舞いの変更）と整頓（構造の変更）を混ぜてはいけません。PRの意図が不明瞭になり、レビューが難しくなるからです。
そのため、タスクに着手する際は「今やるか、後でやるか」をロジカルに判断する必要があります。本書では、その判断基準を以下のように定めています。
1. 報酬（キャッシュフロー）優先の原則
「今日の1ドルは明日の1ドルより価値がある」。 もし、その機能を早くリリースすることで得られる報酬（収益やユーザー価値）が大きいなら、整頓は「後回し（Tidy Later）」にするのが正解です。
先に整頓することは「今コストを支払う」行為です。リリースを遅らせてまで整頓を行い、その結果得られたはずの報酬が減少するなら、それは経済合理性に欠ける判断になりかねません。
2. オプション価値とコスト削減
逆に、「今リリースしても報酬は変わらない」あるいは「このままだと変更コストが高すぎる」場合は、「先に整頓（Tidy First）」すべきです。
ソフトウェアの変更コストを押し上げる正体は「結合（Coupling）」です。 先に整頓して結合をほぐしておくことは、「将来の変更を、安く安全に行う権利（オプション）」を購入する投資と言えます。これによって、本題のタスク実装が劇的に楽になるなら、迷わず先にやるべきでしょう。
判断のための数式
この本の素晴らしい点は、これらの判断を以下の数式で表現していることです。理系エンジニアとして、この明快なロジックには救われます。
(1) 先に整頓するかどうかの判断式
この不等式が成立するなら、経済的にも「先に整頓」が合理的です。
ただし、前述の「報酬（キャッシュフロー）優先の原則」も忘れてはいけません。たとえ整頓した方がコストが安くても、今すぐリリースすることの価値（時間価値）が圧倒的に高いなら、あえて「整頓しない」選択もまた正解なのです。
(2) ソフトウェアコストの正体（コンスタンチンの等価性）
つまり、ソフトウェアのコストを下げる唯一の方法は整頓し要素間の「結合」を減らすことです。
「数式によるコスト計算」と「キャッシュフローの時間価値」。 感情論ではなく、ロジックで判断をすること。その時々の「最適解」を導き出すことが大切です。
