「リファクタリング―プログラムの体質改善テクニック（Refactoring: Improving the Design of Existing Code）」の著者であるMartin Fowler氏が、最近自身のサイトにて、日々のプログラミング作業に効率的にリファクタリングを組み込むための様々なワークフローを研究した記事を公開した。
Fowler氏は記事の中で様々な種類のワークフローの利用方法について説明し、「リファクタリングを最も効果的な方法で使用するには、全てのリファクタリングワークフローを組み合わせる必要がある。そうすることでリファクタリングは開発作業の中にシームレスに流れ込めるのだ。」と提案している。
またFowler氏はリファクタリングを「...外部からの振る舞いを保ちつつ内部の構造を変化させる、既存のソースコードを再構築するための統制のとれた手法」と定義している。
Joshua Kerievsky氏は著書「パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法（Refactoring to Patterns）」の中でこう提案した。
継続的にコードの設計を改善していくことで、どんどんそのコードを扱いやすくなる。これは、ほとんどリファクタリングせず、便宜上新しい機能を追加する際に多大な注意を払う、というようなよくある状況とは雲泥の差だ。もしあなたに継続的リファクタリングの衛生的習慣が身についたなら、いかに拡張や維持が容易になるかよく分かるだろう。リファクタリングは今や周知の手法だとFowler氏は述べているが、多くのチームはリファクタリングの際に使用できる様々なワークフローをより良く理解する必要がある、と彼は示唆している。そうすることで、それぞれの状況に一番合ったものを適応出来るからだ。
SourceMakingのウェブサイトではDon Roberts氏による3のルールに基づいてリファクタリングが必要となるような次のような状況を説明している。
「初めて何かを行うときは、ただやるのみだ。2回目に何か似たようなことを行うとき重複に気付いてたじろぎ、それでも同ようにやるだろう。似たようなことを行うのが3回目なら、リファクタリングしよう。」
- 機能を追加するとき
- バグを修正するとき
- コードレビューと共に
Fowler氏は「二つの帽子」の比喩を引きあわせて、プログラミングのタスクをこなす際の、新しい機能の追加（ファンクションの帽子をかぶること）と、コードの品質向上（リファクタリングの帽子をかぶること）について説明している。そして、「プログラミング中は、頻繁に、ことによると数分毎に2つの帽子を取り替えることになるだろう。しかし、一度にかぶれる帽子はどちらか1つだけだ。」と彼は述べている。
この比喩の流れでFowler氏は、おそらく最も広く利用されている最初のワークフロー"TDDリファクタリング"について説明している。TDDリファクタリングは、グリーンの状態から始め、失敗するテストを書き、動作するように修正し、最終的にコードの質を向上させる、というサイクルで成り立っている。planetgeek.chのUrs Enzlerここで詳しく述べている。
次は"Litter-Pickup（ゴミ拾い）リファクタリング"について説明している。Fowler氏はその利用について、コードの中に散らかった部分を見つけたそのときに行うべき、と提案している。その指針の背景については「そのコードを扱うときに綺麗にすることで、次回そのコードを扱う必要がある際に早く片付けることが出来る。おそらく今変えるよりもさらに早く。」と記している。
そしてFowler氏は"Comprehension（理解）リファクタリング"の詳細について説明している。これはつまり、コードを理解しやすくすることで使いやすく、メンテナンスしやすくする、ということに他ならない。この考えの補足として、Ward Cunningham氏のこの文章が引用されている。
そのコードが何をしているか考えなくてはならない時、あなたは頭の中で理解を確立しようとしている。一度理解が確立出来れば、それをコードに残すべきだ。そうすれば、他の人は二度とゼロから理解しようと試みる必要がなくなる。
彼はさらに、最初の3つと同じくらい大切とされる3つのワークフローについて説明している。
- 新しいタスクを始める際に適応する"Preparatory（予備の）リファクタリング"
- 広範囲において多大な注意を払う必要があるような問題のあるコードが存在する場合に適応する"Planned（計画的）リファクタリング"
- 複数回の反復を通して大きなモジュールをリプレースする際に適応する"Long-Term（長期の）リファクタリング"
あなたも最近、リファクタリングしていますか？