『Tidy First?』読書感想文
「Tidy First?」とは
几帳面で綺麗すぎな君が好きそうな本が出ているよと、周囲から言われ続け、ようやく時間が出来たので読了することに成功しました。えぇ、I am tidy ですよ。
tidy first? 、つまり先に整頓すべきか？をテーマとした内容で、
本書ではこの整頓を「リファクタリングのサブセット」や「小さなリファクタリング」と表現しています。
リファクタリングと言ってしまうと、機能開発を止めてしまうようなものやあまつさえ振る舞いを変えてしまうようなものまで現れてウンザリなんで、ここでは整頓って言うわ！ってことみたいです。
感想
この本、3部構成で全33章あるのですが、1章あたり1〜3ページしかなく、付録後書き除くと 120ページくらいしかないので、あっという間に読むことが出来ます。が、これで定価2,640円なのでちょっと高いと感じる人もいるとかいないとか。
著者のKent Beckさん的にはこの「Tidy First?」はあくまで個人レベルのソフトウェア設計の話で、続編として、チーム開発ではどうするか、更にはいわゆるビジネスサイドなどステークホルダー全体に対してどうかまで話を広げた3部作となると言う話が書いてありました。
そういう意味ではかなり気軽に読んで直ぐに実践できそーな話が書いてあるかなあと思います。
第1部 整頓
1章〜15章までが第1部となっており、デットコードを消そうとかコメントを書くとか、
振る舞いを変えることなく、構造を変えて整頓出来るお手軽テクニック集となっています。
ある程度の経験がある人であれば、この辺はハイハイ知ってる知ってると流し読みして良いところかと思います。
第2部 管理術と第3部 理論
小手先のテクニック的な話よりも、
表題通り、いつ整頓するのか？しないのか？
とか、どう整頓を推し進めるのか？
の方が気になりどころで、まさにそう言う話が以降の章で解説され、33章に結論が書いてあります。
先にこの本の結論を言ってしまうと、以下のような条件が満たせるなら先に整頓した方がいいよねとしています。
- コスト
- 整頓によってコストが小さくなったり、コストが発生する時期が遅くなったり、コストが発生する可能性が低くなったりする
- 収益
- 整頓によって収益が大きくなったり、収益を手にする時期が早くなったり、収益を生む可能性が高くなったりする
- 結合
- 整頓によってより少ない要素の変更になるか
- 凝集
- 整頓によって変更が必要な要素が、より小さく、もっと集中した範囲になるか
整頓したいモチベーションとしては、まず開発をしやすくしたい、だったり運用を楽にしたいとかなわけですよね。要するに後の開発や運用にメリットしかないのであれば、やればええやん、以上なわけです。
余談
「Tidy First?」の話をしている訳ではないですが、リファラジで全く同じような話を laco さんたちが語っている回があるので、整頓でもリファクタリングでも、どうやって進めていったらいいんじゃろかと悩んでいる人がいたら聴いてみるとふむふむとなって楽しいかもしれません。
本題に戻る
また、整頓いつするのか判断の一つの基準として、以下が本書の中で紹介されています。
- 整頓しない
- このコードを二度と変更しない
- 設計の改善から学ぶことがない
- 改めて整頓する
- 直ぐに見返りがない大きな塊の整頓を抱えている
- 整頓を完了することで、最終的には見返りがある
- 小出しに整頓できる
- あとに整頓する（振る舞いを変更した後で整頓する
- 将来の整頓まで待つとかえって高くつく
- あとに整頓しないとやり切った感が得られない
- 先に整頓する（振る舞いを変更する前に整頓する
- 直ぐに見返りがある。例えば、理解が向上したり、振る舞いを安く変更できたりする
- 何をどのように整頓すればよいかがわかっている
これも本当にそうそうって感じで、割と自分は日頃から意識して自然と実践してる感ある話だったんですが、改めて言語化してくれてありがとうと思いながら読んでいました。
これらの判断基準を持って、整頓を実践する上で、例えば1つのプルリクエストの中で振る舞いの変更と整頓を同時にやらないようにする、は割とわかりやすい話かなと思いますが、複数の整頓はプルリクエストを分けるべき？とかはレビューコストとトレードオフだよねーとかそう言う考察もあって面白かったです（この辺の話は個人のソフトウェア設計の範疇を超えてそうな気もするけど
お楽しみリスト
本書中では改めて整頓するものを「お楽しみリスト」に積んでおくと言う表現をしていましたが、前職では、おそらく数分から長くても1時間以内で終わるであろうタスクを「おやつタスク」と呼んだりして、今日の残り1時間、もうやる気でないしメインタスクのキリが悪いなと思う時につまんでやったりしてましたね。そう言うのに近いのかなと思います。
（本書の）整頓の範疇には含まれていませんでしたが、dependabot や renovate でのライブラリの更新、リリース作業などもおやつとしてよく実践していましたね。こういうのってやった感得られるので気分転換にも良いのですよね。
まとめ
- 乱雑なコードに立ち向かうにはやっぱり小さく小さく、そして高速にやっていくのがやっぱ良さそう
- 本書でいう整頓という粒度にしてしまえば、マージするのも怖くないしね
- ただし、整頓してると次の整頓ポイントを見つけてしまって連鎖して一生整頓してるんだが、に陥る場合があるので注意しよう
- 整頓が目的ではなく、開発しやすく、運用しやすいコードにして、どんどんユーザーに価値届けていこうぜ
Discussion