はじめに
「プログラマが知るべき 97 のこと」の「6. リファクタリングの際に注意すべきこと」を読んで考えたことについて書きたいと思います。
リファクタリングについて、自身の中で元々 2 つ問題意識がありました。
一つはリファクタするべきかしないべきかをその都度その都度ゼロベースで考えており、考え方の型を持つことができていないなという点です。意思決定の精度・速度を上げていくためにも何らかの型を身に付けたいなと考えていました。
もう一つは、「リファクタ = 良いこと」と盲目的に考えてしまいがちということです。「ここリファクタしときます」とか言われると、つい反射的に「ありがとう！助かる！」とか返答してしまいがちですが、「それって何のためにやるんだ？」「本当に今それをやるべきなのか？」と自分自身の頭で考えられていないことが多いなと思っていました。
この辺のことについて、またそこから少し逸脱もして、本を読んで考えたこと・まとめたことを書いていきます。
リファクタはいつなんどきでもやるべきという訳ではない
「リファクタリングをする」というとそれはとても良いことのように思ってしまいがちですが、今回本を読んで再認識したのは所詮はリファクタというのは手段の一つでしかないということです。
リファクタをしたからといって、現状が好転するとは限りません。手を入れる前に、まずは冷静に既存コードの「良い点」「悪い点」「強み」「弱み」をしっかり確認した上で、本当にリファクタするか検討するべきです。
また、方針が立ってもいざリファクタをしてみると、さらなる別の問題を見つかって数日では到底終わらない作業になってしまうかもしれません。既存のコードは一見酷く見えても、production で運用されていたコードです。設計が複雑になっているのにはそうせざるを得ない理由があるのかもしれません。
既存の問題点を整理し、解決策を検討した上でそのコスト対効果は見合うのか、このリファクタはちゃんと着地させられるのかが分かって初めて手を入れるべきです。
それでいうと、新技術を使いたいというエゴでリファクタするのも、無意味なことだと言えます。
リファクタに着手すべきタイミング
リファクタは「すぐに」「細かく」「何度も」やるべきだと考えています。
直すべきだと判断したら、その場ですぐに直してしまうのが経験上良いと思います。「ここは後で直しておきます」は大体後で直しません。
またいっぺんに色々なところを書き直そうとすると、「これはちょっと時間が掛かるから明日にしよう」などと後回しにしてしまって結局これもやらないことになってしまいがちです。直すべきと判断したときにすぐに細かく直す、自分が手を入れる前よりは綺麗な状態にするというのが良い塩梅だと思います。
逆にすぐに細かく直す方針が立たないようなリファクタは慎重になるべきです。細かく直せずいっぺんに色々なところを直す必要がある場合はそもそもリファクタの難易度が高く、手を入れて本当に現状より良くなるかは分かりません。
上記のように「すぐに」「細かい」リファクタを「何度も」やっていくことで、コストもリスクも抑えてリファクタを進めることができます。
チームにリファクタ推奨の文化を創るには
定期的にリファクタを行って保守性の高いコードを書くことは大事なことだと頭では分かっていながらも、プロジェクトに追われているメンバーからすると「ちょっとそこまで考える余裕がない」という場合もあると思います。このような状況が常態化すると、チームから保守性の高いコードを書くという文化が消滅してしまいます。
このリファクタのような「重要だが緊急ではないタスク」をチームでどう進めていくべきか、どのようにしたらチームに、リファクタのような保守系のタスクをプロジェクトの合間にもどんどん行っていくことが推奨される文化を創れるのかは最近個人的に頭を悩ませていることです。
まだ答えが見つかっている訳ではないですが、今回本を読んで、チームで各イテレーションで取り組んだ保守メンテ系タスクを共有し、捌いたタスク数等を定点観測しておく、また自身のプロジェクトのタスクだけでなく、保守メンテ系タスクを積極的に行っているメンバーを称賛する場を作るのが良いのではないかなと考えました。
場を作ることでメンバーが互いに刺激を受けたり、「重要だが緊急ではないタスク」をどれだけ捌いているかをある程度定量的に測れるのでチームの健康指標にも使えたりして便利なのではないかなと思いました。早速やってみようかと思います。
終わりに
リファクタリングについて本を読んで考えたことを書いてみました。自身の頭の整理のために書いているものですが、誰かの参考になれば幸いです。