Kent Beckの最新作Tidy First?は、リファクタリングよりも小さな単位でコードを整理するやり方を記した本です。これをTidying（本記事では「片づけ」と呼びます）と呼んでいて、リファクタリングのサブセットと定義付けています。なので片づけはコードの振る舞いは変えないことはリファクタリングから継承します。
Tidy First?はこんまりメソッドの影響も少なからず受けてそうです。
Tidy First?を書いた背景には、リファクタリングが機能開発を止めて行うようになったり、振る舞いを変えてしまうようになったことがある、とKent Beck自身が本書の中で述べています。
最近のKent Beckの講演は、Tidy First？に関連するものになっています。最新は、DDDEUのイベントの講演で第３部の内容が中心に語られています。なおKent Beckのプレゼンは、スライドは用意せずその場で手書きしながら語るという独特のスタイルなので、まだ一度も見たことない人は、ぜひこの動画をご覧ください。
Tidy First？は３部構成になっており、第１部は片づけ(Tidying)の手法のカタログです。
それぞれの手法は、本を読むか、またはTidy First?のページからさわりは確認できます。
https://tidyfirst.substack.com/
そして、これらに特に新規性はありません。自身の著書『実装パターン』と重複しているものも多くあるし、実装パターンの方が記述が丁寧なので、Kent Beckのテクニックを学ぶ目的ではそちらを読んだ方が良いです。
ということで、テクニック自体は本書の主眼ではなく、第２部と第3部の感想および考察を書きます。
片づけとは何か？ いつやるか？
このポストにある通り、片づけとは「変更を簡単にする」行為と言えます。
まず、機能開発（コードのふるまいの変更）と片づけ（コードの構造の変更）は一緒にやるな、少なくともコミット(プルリクエスト)は分けよう、ということが主張されています。
それでもって、この片づけを機能変更の前にやるのか？ 後でやるのか？ それとも当面は放っておく（後回しにする）のかについて考察が加えられています。
- 片づけを後回しにするケース
- すぐには見返りがない大量の片づけをしなきゃいけない
- 片づけを機能変更の直後にやるケース
- 次の片づけまで待つと、かえって高くつきそう
- 片づけをしないとタスク完了した感が得られない
- 片づけを機能変更の直前にやるケース
- 何をどのように片づけるかわかっている
- コードに対する理解が深まり、振る舞いの変更はより安全で簡単にできる
一応の基準を定めていますが、前述のポスト内容から3を推している雰囲気はあります。
結合
実際は少しページを割いて理論展開してあるのですが、詳細は原書を読んでいただくとして、ソフトウェアのコストは変更にかかるコストが支配的であり、変更のコストの最大のパラメータは「結合」であると結論付けています。
したがって、ソフトウェアのコストを下げるには、結合を減らす必要がある、と。ただ結合を減らすのもコストがかかるので、そこにはトレードオフがあります。
全部の要素をばらせない以上、結合しているものは、できるだけひとまとまりになっていて欲しいわけです。これが凝集である、と。
すなわちコードの片づけは、
- 片づけることで、変更しなければならない要素が少なくなるのか？ (結合の観点)
- 片付けることで、変更する必要のある要素がより小さく、より集中した範囲になるのか(凝集の観点)
を勘案しながら行いましょうという結論です。
これも非常に分かりやすい説明がされているものの、新規性はなく、要は疎結合・高凝集を目指しながら、コストの観点をちゃんと踏まえつつ設計改善していきましょう、と昔から繰り返されている話です。
現代における結合度
Tidy First?の中で取り上げられている結合の分析は、Ed YourdonとLarry Constantineの1975年に書かれた『Structured Design』を論拠にしています。これは、今現在でも色褪せることなく有効な概念ですが、システムが大規模化した現代では、他にもコスト影響のある結合度の軸があります。
Yourdon/Constantineの結合度、すなわちモジュール間の結びつきの強さ（結合強度）を表しますが、モジュールより広い概念で、別のコンポーネントやサービスになると影響範囲の調査や組織間調整が増えて、変更のコストが大きくなる、という「結合距離」があります。特に複数チームで開発する場合には、結合距離も合わせて考えないといけません。
さらには、結合距離や結合強度と完全に直交するとは言い難いのですが、これまた統合強度（Integration Strength）が、Learning Domain Driven Designの著者であるVladik Khononovさんによって提唱されています。（統合強度は、Nygardさんの結合度を再整理したもの https://www.slideshare.net/mtnygard/uncoupling-101026908 ）
- 実装結合
- 実装の詳細に依存する
- プライベートインタフェースによって統合される
- 機能結合
- 機能的に関連している
- 業務要求が変わればどちらのコンポーネントも修正が必要
- 物理的な結合を必ずしも意味しない
- モデル結合
- 業務ドメインのモデルを共有する
- 契約結合
- 明示的な統合契約
- 統合のためのモデル（実装モデルとは切り離される)
この統合強度はMicroservicesのようにデータベース分けて、サービス分割したとしても、モデルを共有していたら、その変更はサービス全体に影響してしまうことを示唆しています。
Yourdon/Constantineの結合度を下げることだけが、ソフトウェアのコストを支配する訳ではない、というのはTidy First?を読むうえでも注意しておかなければなりません。
まとめ
Tidy First？はコード改善のテクニックとしては、『リファクタリング』や『実装パターン』を読む方が網羅性があるし、理論的な部分は他のソフトウェア設計に関する書籍や論文の方が手厚いので、まず読むべき1冊とはなりにくい本かと思います。
ですが、片づけを機能変更の直前にやるというのは、新しい概念という訳ではないものの、これまであまり強調されていなかった点で、リファクタリングを技術的負債の返済という大きな塊でしか捉えることのできていない組織にはTidy First?がヒントになるかもしれません。