utamaro’s blog

誰かの役に立つ情報を発信するブログ

リファクタリングを行うタイミングについて

最近リファクタリングについて考える機会がありました。

今回はリファクタリングを実施するタイミングについて、これまで経験したことを記事にしたいと思います。

記事の流れとしては以下のように書きたいと思います。

  1. リファクタリングを行う理由
  2. リファクタリングのタイミングについて
  3. 全体的な開発の流れ

1. リファクタリングを行う理由

リファクタリングを行うことで、内部構造を改善して理解や修正が簡単になります。

この考えは長く開発をしている方はよく理解しているかと思います。

私がこれまで経験した一番悪いケースを紹介すると「10年間リファクタリングをしていないため、重複箇所が多く影響調査に1週間かかる」というものでした。

10年間というキーワードが出てきたことでお気づきかと思いますが、古いシステムです。 PHPを使って作ったシステムで、フレームワークも当時のものを使っています。

控えめに言ってやばいです。

これが原因で上(社長等)から「もっと成果を上げろ」と言われます。

成果を上げるためには重複箇所を修正しなければなりません。 しかし、その修正が目に見えるような成果として出ないものなので、上がなかなか納得してくれません。 説得するための資料を作成するという無駄に時間のかかる作業が必要になり、ベテランのエンジニアが転職していきます。 最終的に、プロダクトを深く理解している人がいなくなり誰も触れないプログラムが出来上がりました。

こうなってしまうと、要件定義から始めて作り直す方が良いかもしれません。

より長く製品を維持するためにリファクタリングが必要になってきます。

2. リファクタリングのタイミングについて

同じコードを2回書いた時に行う

3度目の法則というものがあるのですが、私は2回目で修正を行うべきだと考えています。

経験上、2度同じコードを書いたものは、また別の箇所で同じコードを書いてしまいます。 そして、3つ同じコードが書かれることで修正範囲が広くなってしまい、「修正しよう」という意思が萎えます。 そして重複コードが量産され、作り終わって時間が出来たら直そうという考えに至ります。 そして、その未来はやって来ません。 そうならないように2度目で修正を行います。

修正する際には機能追加や機能改善は行わないようにします。 同時に進めてしまうと、結果の検証時に振る舞いが変わっていないかか確認しづらくなります。

プログラムに手を加えた後で行う

これは多くのチームでやっていないことかと思います。これまで4つのチームで開発を行い全てでやっていませんでした。 機能追加や機能改善、バグフィックス等を行ったあとに、リリース作業を行って終了というケースです。

リリース前にリファクタリング期間を入れます。

手を加えたコードに対して重複箇所をなくしたり、仕方がなく冗長な書き方をしている箇所にコメントを入れたり。 デザインテンプレートを適用して、予想できる機能追加に対して手を打っておきます。

これを行うことによって、製品の品質が維持・向上できます。

リリース前に行う

リリース後のリファクタリングには苦労します。

利用者に影響が出ないように慎重に行う必要がありますし、万が一問題が出たら詫び石を配布しなければならないかもしれません。

twitterで謝罪したり、原因調査等行わないとならないです。

正直面倒です。

そうならないように、リリース前に一度リファクタリングします。

3. 全体的な開発の流れ

リファクタリング期間を入れた際の大まかな開発の流れです。

  1. 設計
  2. 仮実装(要件は満たす状態)
  3. 実装(クラス構造を見直したりする)
  4. テスト作成
  5. リファクタリング(既存のコードと設計を合わせたりする)
  6. リリース or 次の開発

業務では(上からの圧力により)このような流れでできていないのですが、個人開発ではこのように進めています。

がむしゃらに進むより速度は遅いですが、スムーズに進みます。

イメージとしては3歩進んで1回休憩という感じです。 休憩中に、もっと良い方法など考えます。 歩き方が効率化されて、目的地まで疲れずに辿り着けます。