2000年(日本語版)の『リファクタリング―プログラムの体質改善テクニック (Object Technology Series)』から10年後の2010年(日本語版)に出た Ruby エディションを読んだ。
月末の kanazawa.js v1.7 - Back to Basics - : ATND の JSTDD Intro の準備の過程で、本当に言いたいことってなんだろう？とずっと振り返りをしていた。せっかくなので気になってた本を読んでみた。そしてようやく思い出した。自分のやりたかったことはリファクタリングだったのだと。
年代的にも日本語版で言うと
- 2000年 リファクタリング
- 2003年 テスト駆動開発入門
であり、Red/Green/Refactoring のサイクルはこのリファクタリングの中に出てくる。1
コードの振る舞いを変えずに中をクリーンアップする。重複を削り、責務を明らかにする。その結果メンテナンス性が上がり、新機能の追加や変更、修正を行いやすくなる。確かに自分のやりたかったことはこれだった。
脱線してなぜ自分がリファクタリングを望んでいたのかを書いておこうと思う。
それは10年前に目の前の圧倒的にヒドいコードに打ちひしがれていたから。そこで思ったことは大きく二つ。
- リファクタリングしたい（言葉は知っていた）
- オレのコードもいつか捨てるしかないと思われるのではないか
それからオブジェクト指向を勉強し直したりUML描けたら設計がうまくなるかなと思って試したりしていたが、新規開発でなければやはり実際に動いているコードを相手にする力が必要だと思い知らされる。
「動いているコードをいじるな」
というのはよく言われる最もダメな姿勢の一つだが、不用意に加えた変更でシステムに致命的なダメージを与えたことも何度もある。悲しくもなったし、悔しい思いをしたし、目の前のコードを恨んだ。
ところが実際に自分の書くコードも誉められたものではなかった。今思えば、『リファクタリング』に出てくるダメな例の典型である「多すぎる引数を持った関数」も書いていた。当時の自分はオブジェクト指向は名前を知っている程度だった。オブジェクト指向の本は何冊も読んでいたが、結局のところclassを使えばオブジェクト指向だと思っているようなもんだった。
それでも諦めずに戦っていれば少しずつでも上達する。テストなんて書いたことなくたってより良いコードを目指すことはできる。でもやはり安全で確実なリファクタリングはできなかった。テストがなかったから。コードを書くことで上達はしたがコードが増えたらメンテナンス性は落ちる。
やはり自分に必要なものは確実にリファクタリングできるスキルだった。
TDDはこのリファクタリングを、特別な機会に行うものではなく毎日の開発の中に組み込む手法である2。今ならこう説明できる。リファクタリングはできればやった方がよいものではなく、毎日自然に行うもの、テストもできればやった方がよいものではなく、毎日自然に行うもの。今ならやっと言える。
テストなしにどうやってリファクタリングするの？
10年掛かったよ。もし師匠がいればもっと早くたどり着けたかもしれない。でもぼっちでも10年頑張れば少しは何かがつかめる。それは分かった。
さて最後に紹介を少々。
本書はリファクタリングそのものの紹介、リファクタリングした方がいいコードの特徴、そしてテクニックカタログである。オリジナルが出版されて10年以上経った今読むと、すでに動いているコードにも反映されてるテクニックがいくつもあったりするので、ちゃんとたくさんのコードを読んでいれば自然と気づくものも多い。それでもこれだけまとまったカタログがあると心強い。いくつかは Ruby の特徴を本当に活かしているので他のカタめの言語ではマネできないものもあるが、ほとんどのものはオブジェクト指向言語であれば適用可能だ。
動的なLLでコードを書くすべての人はお守りとして辞書として持っていていい。個人的にはデザインパターンよりも前に読むべきだと思う。具体的でかつ覚えなければいけない用語は少ない。最初から理想的なコードが書かれているわけではなく、あーあるあると思うことが多いのですんなり読めると思う。
いちばんピンときそうなのはやっぱり条件式の単純化の辺りかな。これは分かりやすくて効果がすごく大きいと思う。個人的に今回あーなるほどと思ったのはクラスアノテーションの導入から名前付き引数の流れと、恥ずかしながらやっとしっくりきたNullObjectパターン。これ使えばあちこちで .present? とか書かずに済むんだなー。