リファクタリング (プログラミング)
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2023/10/11 11:11 UTC 版)
リファクタリングを行うタイミング
いつでもなんでもリファクタリングをすればよいというものではない。例えば、納期がぎりぎりに迫った場合などにリファクタリングを行っている余裕はないし、リファクタリングは将来に備えて行うものであるため、そのリファクタリングが実を結ぶ可能性は少ない。また、リファクタリングといえども、やはりプログラミングであるので、常にミスをする危険性は拭えない。
『リファクタリング』では、機能追加するときと、リファクタリングするときをはっきり区別することを勧めている(このことを比喩して「実装の帽子をリファクタリングの帽子に被りなおす」という)。リファクタリングしてばかりいては開発は進まないし、どのリファクタリングをするべきかはある程度開発が進まないと分からない。リファクタリングを開始するタイミングとして、コードに「不吉なにおい」を感じ始めたら、と提案している。これは似たようなコードの重複や、長すぎるメソッド、ひとつの変更の度に複数のクラスが影響を受ける、などの症状が見つかったときを指している。また、機能追加の前、コードレビュー時、バグフィックス時にもリファクタリングを勧めている。
テストの重要性
リファクタリングでは、プログラムの外観を変更してはならない。そのため、テストが非常に重要である。修正は段階的かつ小刻みに行い、わずかな変更であっても、その度にテストを行うことで、動作の異常をいち早く察知する。テストを行わずに一度にリファクタリングを行うと、プログラムの動作が気付かないうちに変わってしまい、その原因を突き止めることが難しくなる。プログラマにテストをサボらせないため、簡単にテストを実行できるツール (xUnit/JUnitなど) も必要である。また、テストを重要視することは、アジャイルソフトウェア開発のいくつかの開発手法(エクストリーム・プログラミングなど)における「テストファースト」や「テスト駆動開発」の考え方とも一致する。
リファクタリングの課題
リファクタリングには、いくつか課題が存在する。例えば、データベースに変更を加える場合、データを移行する必要がある。たしかに、中間層を挟むことで影響を緩和できるが、やはり時間が掛かることは否定できない。また、リファクタリングでは、従来のようにカプセル化されたクラス内だけでなく、インタフェースも変更することがある。それが広く公開されたインタフェースである場合、新しいインタフェースと古いインタフェースを両方保守しなければならない。また、修正するコードがあまりに酷い場合、新たに書き直したほうが早いこともある。リファクタリングは発展途上の技術であるため、これら以外の課題が見つかる可能性がある。
- ^ Renaming is a common operation related to refactoring source code and VS Code has a separate Rename Symbol command (F2). Visual Studio Code - USER GUIDE - Refactoring - Rename Symbol
- ^ Opdyke & Johnson 1990
- ^ Griswold 1991
- ^ a b Opdyke 1992
- ^ a b Fowler 2003
- リファクタリング (プログラミング)のページへのリンク