「Tidy First?」 を読んでみた所感

本記事はUzabase Advent Calendar 2023の4日目の記事です

はじめに

最近イベントに参加した時に知りましたが、エクストリーム・プログラミングを提唱したKent Beck氏が今年10月に新しく本を出版していました。

それが今回の記事タイトルにも入れている「Tidy First?」という本です。

いまの現場ではエクストリーム・プログラミングをベースにアジャイル開発をしているので、その提唱者が新しく本を出したのであれば、どういう本なのか興味がありました。

今回はその「Tidy First？」を読み進めて面白いと思ったところの所感と、それを今のチーム開発にどう活かしていくかを考えてみようと思っています。

読んでいて面白いなと思ったポイント

コードベースのTidy（整理整頓）をいつ、どのくらいやるかにフォーカスしている

本の中では、Tidyをリファクタリングのサブセットだと言っています。

読んでいる感じ、あくまで何かしらの機能を追加・変更（behavior change）を行なう事がサポートできる程度の小さな粒度のリファクタリングのことをTidyと表現しているように読み取れました。

この本は三部構成となっていて、パートⅠはTidyのテクニックのカタログとなっています。

ただガード節や説明変数、ヘルパー関数などリファクタリングに関してある程度知識があると、あまり目新しさは無かったです。

どちらかというと、パートⅡ・ⅢにあるTidyを「どのくらい」と「いつやるのか」についてフォーカスした話が纏まって書かれていたのが他では見ない感じです。
（リファクタリング第二版でもいつリファクタリングをやるかという話はありますが、さっと見た感じ、数ページぐらいでした）

どのくらいやるか

どのくらいやるかについては、なるべく小さくというのと、構造の変更と振る舞いの変更は分ける（リファクタリングにも書かれていた2つの帽子の話っぽい）。数分から1時間程度の活動が目安（それ以上掛かっていると、必要な最小限の構造の変更という目的を見失っている可能性が高いとのこと）。

いつやるか

いつやるかについては4種類の選択肢が書かれていました。

• やらない
  • コードを二度と変更することがない
    • 変更しないというのは稀なので、最後の選択肢
• 後で整理する（3つ目よりもっとスパンが長い感じ）
  • いま振る舞いの変更するのに直接寄与しないかつ、大量にコードを修正する必要がある
  • 小分けに整理ができる場合
• 振る舞いの変更をした後で整理する
  • 次にコードを触る時に整理する方が、（整理を容易にできるコンテキストなどを忘れて）コストが掛かる
• まず最初に整理する
  • 整理することで理解しやすくなる、振る舞いの変更のコストが削減できる
  • どう整理すればいいのか分かっている

振る舞いの変更をした後で整理するというのは、TDDのRED->GREEN->REFACTORのリズムに慣れていれば特別違和感は無いと思います。

まず最初に整理するのは、リファクタリングの第2版に記載されている準備のリファクタリングと理解のためのリファクタリングの話に近い印象でした。

なるべくは最初に整理することを推奨されていますが、「Tidy First?」と疑問符で強調されている通り、必ずしも絶対のルールでは無くて状況に応じていつやるかを判断をする必要をしよう、となっています。

あくまでこの本はいつやるか、どのくらいやるか、ということを考えるヒントや考え方について多くページを割いています。

お金の時間的価値とオプションの話

パートⅢは、HowやWhenの話ではなくて、その背景にある理論の話になります。
カップリングがソフトウェアのコストを上げていることや、凝集性については他でも見かける話でしたが、個人的には、ちょっとした経済の話が面白いなって思いました。

詳しい内容は本を読んで頂けたらと思いますが、今日貰える1ドルと明日貰える1ドルを比較した場合に、今日貰える1ドルの方が価値が高い（すぐ使えるし、投資に使うこともできる）という話です。だからこそ早く稼いだ方が基本は良い。

早く稼ぐというのをソフトウェアに置き換えると、早く機能変更を行ってユーザーに価値を届けることであり、そのプレッシャーは私たちが最初、もしくは後での整理をしない選択肢を取ることに繋がる可能性があります。

それに対して、ソフトウェアの将来の変更が容易に可能にできるというのはそれだけで価値である（変更に対するオプションがいくつも選べる事自体に価値がある）。
最初、もしくは後での整理をするという選択肢を選び続け、その結果、コードが理解しやすくなったり、コードの凝集性が高まるなどして、変更に対するオプションを創出するということもできます。

その辺りのバランス感覚は、それぞれのコストがどのくらいかを考えて判断ができるように練習が必要とのことです。

この辺りを読んでみて、どうしてもユーザー価値を早く届けてフィードバックを得たいという気持ちがあったのですが、ソフトウェアが今後どんな環境の変化があっても変更の選択肢を多く残せるようにする事も今より意識しないといけないと感じました。

日々の開発にどう取り込んでいくか

（まだ試してないので、試しに実践しながら変わりそうです）

私がいるチームでは日々ペアプロでやっていますが、その中でよく出くわすのが、パートナーや私自身がコードをリーディングしている最中に理解がすぐにはできずに手が止まる瞬間です。

• ドメインオブジェクトの名前が何を表すのかよく理解できない
• if文などの条件分岐が多かったり、if文の条件が何を表しているのかわかりづらく、処理の流れが追いづらい
• 画面で使われている名前とコード上で出ている名前が一致していなくて、たどり着くのに時間が掛かる

ドメインオブジェクトで使われている名前は、私たちがまだドメインに関して多くを理解していない可能性も否定できないですが、2つ目や3つ目などは、整理する対象になりそうだなと感じました。

また理解しづらい時に私たちはよくホワイトボード（もしくはオンラインのホワイトボードツール）に、絵を描きながら認識を揃えることをしますが、その理解した事を機能追加する前にコードを整理する事をしていけそうだなと思いました（図示するということは理解しづらいという一種の兆候とも言える）

あとはその時に理解したことを次同じコードベースを触る時にコンテキストを持っていられるか？　という問いかけも良さそうです。答えがNoだったり、前にホワイトボードに図示したものを見ないと思い出せない、ということだったら、それはいま整理する対象なんだと判断がつきそうです。

まとめ

パートⅠのところは他の書籍でもよく見かけるところだったので、目新しさはあまり無かったのですが、パートⅡとⅢのいつやるか・どの程度やるかや、背景にある理論が面白く、なんとなく「早く価値を出した方がいいよね」「リファクタリングしたいよね」というところに、別の視点での考え方が持てた感覚でした。

テクニック集を学びたい、みたいなモチベーションだと他の本を読んだ方が良さそうとなりますが、日々どうやってリファクタリングと機能開発のバランスをどう取るかというモヤモヤを持っている方に関しては参考になる書籍だと思いました。