はじめまして。入社4年目の「T」と申します。開発エンジニア歴としては11年目になります。
私が所属しているプロジェクトでは、メンバーの技術向上の取り組みの一環として
メンバー持ち回りで勉強会を行っています。
内容としては開発エンジニアの基礎的なこと
から業務で使用する技術で知っておいたほうが
いいものを各メンバーが資料を作成して
定例ミーティングで発表をしています。
最近はリファクタリングについて担当を分けて
勉強会を実施し学んでいる最中なので、
今回のブログのテーマとしては
リファクタリングがどういうときに必要か？
ということを皆さんに、ご紹介します。
■リファクタリングを行う理由
まずリファクタリングとは何か？ですが、既存のプログラムを修正前後で
ふるまいを変えずにコードを分かりやすくする目的で修正することです。
リファクタリングはコードを理解しやすくし、不具合を見つけやすくすることが
できます。
■リファクタリングを行うタイミング
リファクタリングを行うタイミングとしては下記が挙げられます。＊既存のコードに機能を追加するとき
既存のコードを読んだ時に、
・複雑化していてこうしたら機能追加が簡単になるはずと考えたとき、
・リファクタリングをしないとコピーしたコードを追加しなければならず重複したコードが生まれて
しまうとき
＊コードが複雑化して理解しづらいとなったとき
コードを読んだ時に何をしているか理解しづらいなと考えたとき
＊コードは理解できるが書き方が今一つのとき
元々ある関数で代用できるのに複雑な処理になっている場合
＊コードレビュー時
リファクタリングできそうな修正の場合
■リファクタリングの問題点
もちろんメリットだけではありません。
リファクタリングは既存のコードの改善であって、修正前後で機能が変わるわけではないです。
処理が理解しやすくなったからといって、性能の改善につながるわけでもありません。
（上がることもあるが、下がることもある）
それでもリファクタリングを行うことによって、コードが整理されて今後のプログラミングの速度を
上げることができます。
以上で簡単ではありますが、リファクタリングについての説明でした。
リファクタリングが必要がない実装を最初から行うのが一番いいではありますが、スケジュールの都合上
コードの品質よりもスピード重視になってしまい、そのまま修正されることなく継ぎ足しで修正していく
ことは開発現場ではあるあるかなと思います。
コード改善というのは後回しになりがちですが、複雑化したコードのまま保守を続けていくのは理解に
時間がかかったり、不具合を作りこむ原因にもなる為、ぜひリファクタリングのための時間をつくる
ことを考えてみてください。
ちなみに・・・
勉強会の際には参考にしている本があるのですが、今回は下記の本を使っています。
今回はリファクタリング必要性のみで紹介できませんでしたが、
具体的にどういう風にリファクタリングを進めていくかが記載されており、
リファクタリングに限らず実装する際に知っておいたほうがいい内容となっています。
すごく勉強になる本なので興味のある方は参考にしてみてください。
リファクタリング（第2版） 既存のコードを安全に改善する
https://www.ohmsha.co.jp/book/9784274224546/