「Tidy First?」を読んだ

すごい今更感はあるけども、「Tidy First?」読んだのでその感想。短い本なので、一周読み終わるのはあっという間だったけど、Kent Beckの主張が上手くつかめてなかったので、また読み直して、人の感想読んだりした。

Tidy First? ―個人で実践する経験主義的ソフトウェア設計 | Kent Beck, 吉羽 龍太郎, 永瀬 美穂, 細澤 あゆみ |本 | 通販 | Amazon

Tidy First? ―個人で実践する経験主義的ソフトウェア設計 | Kent Beck, 吉羽 龍太郎, 永瀬 美穂, 細澤 あゆみ |本 | 通販 | Amazon

AmazonでKent Beck, 吉羽 龍太郎, 永瀬 美穂, 細澤 あゆみのTidy First? ―個人で実践する経験主義的ソフトウェア設計。アマゾンならポイント還元本が多数。Kent Beck, 吉羽 龍太郎, 永瀬 美穂, 細澤 あゆみ作品ほか、お急ぎ便対象商品は当日お届けも可能。またTidy First? ―個人で実践する経験主義的ソフトウェア設計もアマゾン配送商品なら通常配送無料。

https://www.amazon.co.jp/Tidy-First-%E2%80%95%E5%80%8B%E4%BA%BA%E3%81%A7%E5%AE%9F%E8%B7%B5%E3%81%99%E3%82%8B%E7%B5%8C%E9%A8%93%E4%B8%BB%E7%BE%A9%E7%9A%84%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E8%A8%AD%E8%A8%88-Kent-Beck/dp/4814400918?tag=st43-22

整頓(Tidy)とは

本著は要するにリファクタリングの本なんだけども、リファクタリングを薦める本ではない。

リファクタリングをよく知る人なら、「振る舞いを変更することなく構造を変更する」として定義されるリファクタリングと、整頓の類似性の高さに気づくだろう。整頓はリファクタリングのサブセットだ。整頓は可愛くてふわふわした小さなリファクタリングなので、誰も嫌いになれないはずだ。

確かに普段開発していて、「リファクタしたいなあ」と思うときって、だいたい仕様変更も入れてしまっていた。昨日まさに見通しの悪いコード読んでて、もっとシンプルに書き直したい欲望が出てきて、それを最初リファクタリングだと思ってたんだけど、そういえばふるまい変えようとしているので、厳密にはリファクタではないなと気づいた。

「整頓」は本当にふるまいを変えずにコードをきれいにすることを意図している。第一部で語られているのは、そのための実践的Tips。ガード節の書き方とか、デッドコードは無慈悲に消せとか、コメントは冗長なものは消し有益なコメントはきちんと残すとか、そんなことが書いてある。

熟練のプログラマーの、言語によらないグッドプラクティクス集という印象。最近SwiftからDartを書くようになって、「この書き方は良くない」という指摘を相当受けてるので、言語によらないというのは大事だなと思ったりもした。

というかSwiftのグッドプラクティス集がプログラミング言語全体で言うと特殊だなとも思う。可読性が高いので、プロパティをそのまま条件式で使うことが多いけど、他の多くの言語だと可読性のために一旦変数にする。言われてみればそうだなと思った。someClass.someArray.isEmpty をif文につっこむんじゃなくて、bool isEmpty = someClass.someArray.isEmpty で一回受けるとかね。

整頓とふるまいを変えるコミットをわける

Kent Beckの薦めている整頓とふるまいを変えるコミット・プルリクエストをわける、というのはいいお作法だなと思った。

というかそもそも「ふるまいを変えない本来の意味のリファクタリングPR」をほとんど出していない。typo修正ぐらいだろうか。でも数行ぐらいなら他のPRに含めてしまう。

Tidy First?

タイトルは「最初に整頓すべきか?」という意味だけど、本著はリファクタリングを推奨する本でもないし、整頓を最初にすべきだと主張する本でもない。

結論を書くと、「整頓に対するコストが十分に低いとき、整頓からはじめて、ふるまいを変更すべきだ。そして大抵の場合は整頓のコストはそんなに高くない」という主張になっている。「整頓をしない/改めてやる/後でやる/先にやる」という比較を21章でしている。

要するに「先に整頓する」ことを薦めている。ただし必ずそうすべきだ、とは主張していない。以下の制約を満たすという前提であれば、先に整頓した方が良いという主張。

cost(整頓) + cost(整頓のあとに振る舞いを変更) < cost(整頓せずに振る舞いを変更) (27章)

よくわからなかった第3部

第3部は理論と題されていているけど、ちょっと飛躍があって、上手く腹落ちしなかった。結合と分離とか、凝縮とか、ソフトウェア開発っぽい概念も出てくるけど、途中で出てくる金融論がTidy First?の主張と上手くつながらなかった。

・今日の1ドルは明日の1ドルよりも価値があるので、早く稼ぎ、あとで使う。 ・カオスな状況では、モノよりオプションのほうが優れているので、不確実性に対してオプションを作る。 (24章)

「今日の1ドルは明日の1ドルよりも価値がある」というのは経済学(金融論?)の現在価値の話で、そこは理解できてるけども、「早く稼ぎ、あとで使う」が逆なんじゃないかと思ってしまった。

たとえば無利子で借金できるとするなら、今日1ドル借りて使ってしまって、明日1ドル稼いで返すのが得だろう(だからこそ現実社会では利子が存在するんだけども)。現在価値の話をするのであれば、「早く使い、あとで稼ぐ」が合理的なので、なんかおかしな主張だなと読んでて思ってしまった。

たぶんプログラマー個人はTidy Firstで実務的・精神的メリットが得られるし、チーム/企業にとっても利益があるというのを理論的に書いてくれているんだけども、あんまり腹落ちしなかった。

まとめ

この本はリファクタリングの本ではないけれど、最後まで主張を咀嚼すると、正しいリファクタリングの作法が書いてあるのかもしれない。副題に経験主義的と書いてあるように、Kent Beckの長年の経験から来る内容、しかも原理主義的ではなく、控えめな主張(そして短い)がウケたのかなという印象。

整頓+ふるまいを変えるPRというのは取り入れても良いなと思っている。自分でどこまで実践するかはちょっと迷い。

あと「ふるまいを変えないでコードベースをきれいにする」というのは意識しようと思いました。

(了)