「リファクタリング」の進め方と心持ち

 「リファクタリング」を読みました。とてもいい本で、名著と言われる所以が分かった気がします。リファクタリングをしないエンジニアはいないと思います。リファクタリングの方法論について学んだことがない方は、ザッとでも構わないので読んでみると色々捗ると思います。

新装版 リファクタリング 既存のコードを安全に改善する

新装版 リファクタリング 既存のコードを安全に改善する

どのような本か?

 ざっくり言うと、

  • 1)リファクタリングに関する心持ち
  • 2)具体的なリファクタリング方法論・手順

が書かれている本です。2)については、かなり詳細に書かれていて、リファクタ前後のソースコードだけではなく、途中のステップをかなり丁寧に事細かに書いていただいています。

□ 元のメソッドと同じ値を返す問い合わせメソッドを作成
□ 元のメソッドを修正して、問い合わせメソッドの戻り値を返すようにする
□ コンパイルしてテストする
□ 全ての呼び出しに対して(以下略)

このような粒度で、たくさんの方法論が書かれています。2)については、ざっと読み、どのようなシーンで使える方法論があったかをまずは理解するといいと思います。辞書的に手元におきながら、実際にリファクタリングする際に参照できるようにすると捗りそうです。1)については、しっかりと読んで心に刻みたい内容です。

 ここからは、本を通じて学んだたくさんのことの中から、特に勉強になったこと・心に留めておきたいことをメモしていきたいと思います。

既存コードの理解を深めるためにリファクタリングをする

 筆者は、意味がわからないコードを理解するためにリファクタリングを行うそうです。

  • このコードはもしかしてこういう意味だろうか?
  • であればこのテストを追加しても通るはず..
  • であればこのコードはこう書き換えても振る舞いを変えずに動くはず..

というようなステップです。「プログラムの振る舞いを完璧に理解しないとリファクタリングしてはいけない」となんとなく思っていたのですが、「カジュアルにリファクタリングしてもユニットテストが守ってくれるだろう」という思想に変わりました。

リファクタリングの第一歩はきちんとしたテスト群を作ること

 「ユニットテストが守ってくれるだろう」と何気なく書きましたが、心置きなくリファクタリングするためには自動化されたユニットテストが必要です。なければ必ず作りましょう。

 ちょうど本を読んでいるときに、ユニットテストのない(あまり綺麗でない)プログラムに手を入れる必要があったので、まずは既存部分のユニットテストを書くところから始めました。これまでの私だったら、ユニットテストがないことを不満に思いながらも、既存部分のユニットテストから書き始めることはしなかったと思います(自分が手を入れた新機能のテストを作るだけ)。

 しかし、この本に従い、まずは既存機能のテストを書く方法を採用してみました。その結果、積極的なリファクタリングができたのでプログラムの見通しを良くでき、本題の機能追加自体も短い時間でできたと思います。

 「ユニットテストがない」環境を正していく必要がある案件にしばし遭遇しますが、そのようなときに使えそうな心に留めておきたいアドバイスが二つありました。

「実行されない完全なテストよりも、実行される不完全なテストの方がマシである」

 ゼロの状態から、全てをユニットテストで網羅しにいくのは大変です。そうではなくて、リスクの高い、一番怪しいと思う部分から始めるのです。

「バグレポートを受け取ったら、まずはそのバグを明らかにするための単体テストを書く」

  残念ながら不具合が見つかってしまった場合は、まずはその単体テストを書きます。この意識を持つことで少しずつテストを充実させることができます。

リファクタリングは「常に」「何かを行うための手段として」行うべきもの

 リファクタリングは「そのために時間をとって行う活動」ではなく、何かしらの案件を推進する際に常に「自然発生的に行われるべきもの」であるべきです。機能を追加したり、バグを修正したり、あるいはコードレビューをしながらリファクタリングすることもあるそうです。自分も息を吸うようにリファクタリングするマンになります。

「リファクタリング力」を上げることで、事前設計のプレッシャーを減らす

 「設計を完璧に行わないといけない」と思うあまり、無駄に工数が膨らんでしまうことがあります。手戻りが怖いので致し方ない面もあると思います。この本の主張としては、もちろん設計はきっちり行うが、完璧なものを作ることを目指さず、妥当な解決策が見つかったら先に進みましょう、とのことです。未来の要件や機能を事前に考えきれないことはしばしあります。そんなときは、将来の拡張性を考えつつも、「あとでリファクタリングすればいい」という気持ちで先に進んでしまって構いません。

 私は今、新規事業を作る仕事をしています。「考えうる将来の拡張性をすべて設計に盛り込まないと」という意識があり、設計に時間をかけすぎる傾向がありました。このアドバイスにより、不安がひとつ解消できた気がします。

 後半の章に「ツールを使ってリファクタリングコストを下げる」という話があります。ここでも「リファクタリングコストを下げることで、設計ミスのコストも下げられる」と書かれていました。リファクタリング力を上げることで、設計にかける時間を最適かしたいです。

その他

  • デザインパターンを鑑にしたリファクタリング方式が多い。GoFシリーズを理解しているつもりではいたが、息を吸うように使えるかというとそうではない。そのレベルまで理解しないと良いリファクタリングができないと思うので精進したい。
  • これを感じたらリファクタリングをすべきだ!という「コードの不吉な臭い」がとてもよい(3章)。この部分は定期的に読み返したい。また、「3度重複する作業をしたらリファクタリングを試みる」という判断軸も紹介されていた。
  • 「問い合わせと更新の分離」という手順に、「値を返すメソッドは、副作用を持たせないと決めてしまう」というルールが紹介されていた。ふむふむ。

 

まとめ

 ちょうど読んでいる時に、リファクタリング案件をやっていたと書きましたが、

という感想を持つまでになりました(笑)

 この本は、いわゆるエンジニアとしての血肉本だと思います。読んだことがなく、リファクタリングに自信のない方は是非目を通していただきたいと思います。

新装版 リファクタリング 既存のコードを安全に改善する

新装版 リファクタリング 既存のコードを安全に改善する

※「この商品はタブレットなど大きいディスプレイを備えた端末で読むことに適しています。」とのことですが、iPad mini 4 で十分読める形式でした。