はじめに
リファクタリング 第2版を読み進めているので、今回は第2章について。
2章では具体的なテクニックに書かれているわけではなく、定義やなぜするのか等がまとめられている。
リファクタリングの定義
外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウエアの内部構造をさせること。
リファクタリングを行うことによって、以前に書いたコードの設計が向上することになる。
リファクタリングの目的は開発スピードを上げていくということであり、コードを「理解や修正が容易になるように」変化させることであり処理速度を上げるためのものではないということを認識しておくべきだと感じています。
リファクタリングを行う理由
大きく3つの観点で書かれている。
ソフトウェア設計を改善する
アーキテクチャの全体的な理解をせずに、開発者が部分的な変更を行なった場合、コードは構造を失うことになる。こうなると他のメンバーや自分が見直す時に設計を把握するのが難しくなってしまい累積的に悪影響が出てしまう。設計を維持することが難しくなり急速に劣化してしまう。
だからこそ、重複するコードを削除したり、あるべきコードをあるべき場所に移動させたすることが必要であるとのことでした。
ソフトウェアを理解しやすくする
理解しにくいコードを書くことで将来の開発者に負担を強いてしまう。動作はするが上手く構造化さていないコードがあったとして、少しの時間をリファクタリングに充てるだけで、コードの目的がより伝わりやすくなる。
バグを見つけやすく
コードを理解しやすくすることによってバグを発見しやすくなる。自分がそのコードをリファクタリングできれば、プログラムの構造を明確にし、コードに対する推測が正しかったことがわかり、バグ発見に繋がる。
いつリファクタリングをすべきか
機能追加をする時
既存のコードを読んで、もし構造が少しでも違っていたら作業は簡単になるはずだと考え、機能追加をする前にリファクタリングできるところはあるのかを考えることは重要である。
最初に完璧な設計を探さなくても、リファクタリングを行う体制があることにより常により良い解を探し出すことができる。リファクタリングをすることで、コードや設計への理解が深まり、それによって設計の改善が行われていくことが可能であることが述べられていました。ここで重要なのは最善の解が常に変わる可能性があるということを受け入れることが必要であるということを頭においておくべきだと思いました。
ゴミ拾いのためのリファクタリング
現在取り掛かっているタスクに直接関係のないことに時間を奪われたくないと考えるが、将来の変更要求があったときに邪魔になるであろうゴミを放置するのではなく、すぐに実行するべき。修正に手こずりそうな時はメモなどを残しタスクが終わり次第行う。
コードレビュー時
自分にとってのわかりやすいコードも、チームにとってはそうでもないかもしれない。レビューは示唆に富むアイデアを多くの人から引き出す機会を与えてくれる。
さらにチームでリファクタリングを行わなければ出てこなかったような一歩進んだアイデアが浮かんでくることも。
リファクタリングを避ける時
いかなる場合もリファクタリングをするべきだと思われているかもしれなが、リファクタリングの価値がない場合もある。
単なるAPIとしてみなせるのであれば放置しておいてもいい。最初から書き直した方がリファクタリングするよりも簡単な時もある。
ただ、このリファクタリングの判断をするには適切な判断能力、豊富ば経験が必要であり簡単に身に付くことはない。
感想
リファクタリングは開発スピードを向上させるもの、理解しやすい設計、改善、バグ発見など特にチームで開発するには必須であると感じています。
後からコードを読む人、自分も含めてリファクタリングを怠った時はコード設計を把握することも難しくなり、品質の維持に影響が出るためプログラム内部の設計を劣化させることに繋がってしまう。そのためにも常に個人でもリファクタリングをする意識が必要であり、リファクタリングをしながら開発する体制を整えることが重要であると思いました。
読み進めている最中ではありますが、参考になった章をまとめていけたらと思います。