レガシーソフトウェアに手を入れるにあたってまずは計測・可視化をしましょう、というのがいい話だった。ここでも「推測するな、計測せよ」の原理が効いてくる。闇雲にリファクタリングするのではなく、本当に肝心なところを見極めてリファクタリングしましょう、ということを忘れないようにしたい。
リファクタリングを進めるためにチーム・ビジネスを巻き込みましょう、そのためにどういう利益があるのかを示せるようにしましょう、ということを念頭に置いている。とはいえサッと終わるリファクタリングなら勝手にやるほうが早いというのもあり、要はバランス。
全てを書き直すのは最終手段にするのをおすすめします、ということを強調されていた。この言葉は重たい。とはいえ最終手段としてどのように取り組めばよいのかも教えてくれるので勇気づけられる。
結局、最初は「醜悪な実装」に見えたコードが、実は「複雑な仕様」だった、という場合が多く、それについては、大きな改善が望めない。
IntelliJ IDEAには引数が多すぎるコンストラクタをBuilderパターンに修正する機能があるらしくて便利そうだった。こういうツールを作って生産性を上げることができれば何よりの喜びだと思う。
自尊心のあるプログラマなら、そんなのはIDEに任せて、もっと大事な仕事をしよう。
それ以外の具体的なツールの使い方は流し読みした。2016年に初版が出ていて、現代ならDockerを使うでしょう、みたいな記述もある。linterの使い方について書いてあるところは実感が持てる内容だった。linterに振り回されるのではなく、生産性を上げるためにlinterを使う、そのためにはノイズを抑制する、というのはちょっと前に書いていた。
そういえばレガシーソフトウェアの改善ではないけど、ちょっと前にいいことを書いていたのを思い出した。今でもPRが大きくなりすぎないように・ついでにいろいろ解決しまくらないように心がけている。
本に書いてある内容と自分の経験や勘に似通ったところがあると、単なる野生の勘ではなく既に誰かが言語化してくれていたのだ、と安心する。
