|
|
|
|
24.4 安全なリファクタリング
リファクタリングは、コードの品質を向上させるための強力な手段である。強力なツールの常として、リファクタリングは使い方を誤れば改善どころか害をもたらすことがある。リファクタリングの誤りは、いくつかの簡単なガイドラインで未然に防ぐことができる。
■ 最初のコードを保存する
リファクタリングに取りかかる前に、作業を開始したときのコードに戻れるようにする。バージョン管理システムにそのコードを保存するか、正しいファイルをバックアップディレクトリにコピーする。
|
■ リファクタリングの規模を小さく保つ
リファクタリングによっては他よりも規模が大きく、正確に何が「1つのリファクタリング」を構成するのかがあいまいなものがある。リファクタリングを小さく保ち、変更によるすべての影響を完全に理解できるようにする。『Refactoring』（Fowler 1999）では、この方法の例を豊富に交えながら、リファクタリングを詳しく説明している。
■ リファクタリングは一度に1つずつ行う
リファクタリングによっては、他よりも複雑なものがある。きわめて単純なものを除き、リファクタリングはすべて一度に1つずつ実行し、リファクタリングが済んだら、次のリファクタリングに取りかかる前に、コードを再コンパイルしてテストする。
■ 手順をリストアップする
擬似コードプログラミング（上巻の第9章を参照）の延長線上にあるのが、ポイントAからポイントBに進むためのリファクタリングの手順をリストアップすることである。リストを作成しておけば、それぞれの変更を見失わずに済む。
■ 「駐車スペース」を設ける
1つのリファクタリングの途中で、別のリファクタリングが必要であることに気付く場合がある。さらにそのリファクタリングの途中でも、3番目のリファクタリングが役立つことに気付く。そういう場合は、すぐに必要でない変更のための「駐車スペース」を設ける。つまり、いつか必要になるが、今すぐ必要というわけではない変更をリストアップしておく。
■ チェックポイントをこまめに作成する
リファクタリングの途中でコードが突然わき道にそれることがよくある。作業を開始するときに最初のコードを保存するだけでなく、リファクタリングセッションのさまざまな段階でチェックポイントを保存し、コーディングに行き詰まったら動くプログラムに戻せるようにする。
■ コンパイラの警告を利用する
コンパイラをすり抜けてしまうような小さなエラーは紛れ込みやすい。コンパイラの警告レベルを最も敏感なモードに設定し、コードを入力したらすぐにできるだけ多くのエラーを捕捉できるようにする。
■ 再テストする
変更したコードのレビューはテストで補う必要がある。もちろん、きちんとしたテストケースが揃っていることが前提となる。回帰テストや他のテストについては、「第22章 デベロッパーテスト」を参照。
■ テストケースを追加する
古いテストを使って再テストするだけでなく、新しい単体テストを追加して新しいコードをテストする。リファクタリングによって古くなってしまったテストケースはすべて削除する。
■ 変更をレビューする
レビューが1回目の作業で重要であるとすれば、その後の変更ではさらに重要となる。Ed Yourdonの報告によれば、プログラマの1回目の変更にエラーが含まれている確率は、一般に50%以上にのぼるそうだ（Yourdon 1986b）。興味深いことに、プログラマがほんの数行ではなく広い範囲のコードを変更すると、変更が正しく行われる確率が高くなる。具体的には、変更された行が1行から5行に増えると変更を誤る可能性が高くなり、それ以降は変更を誤る可能性が低くなる。
 |
| 図24-1 大きな変更よりも小さな変更の方がエラーは起きやすい（Weinberg 1983） |
プログラマは小さな変更を軽く扱う。机上チェックをさぼり、第三者にレビューしてもらうことをせず、へたをすれば修正がうまくいったかどうかを確認するためにコードを実行することすらしない。
|
■ リファクタリングの危険度に応じて手法を調整する
リファクタリングによっては、他よりも危険なものがある。「マジックナンバーを名前付きの定数に置き換える」といったリファクタリングは、比較的安全である。クラスやルーチンのインターフェイスの変更、データベーススキーマの変更、あるいは論理評価の変更などを伴うリファクタリングは、より危険な傾向にある。簡単なリファクタリングに関しては、リファクタリングプロセスの効率を重視して、一度に複数のリファクタリングを実行したり、再テストを単純にしたり、公式なレビューを省略したりしてもよいだろう。
より危険性の高いリファクタリングに関しては、十分な注意が必要である。リファクタリングは一度に1つずつ行う。通常のコンパイラによるチェックと単体テストに加えて、第三者にリファクタリングをレビューしてもらうか、リファクタリングにペアプログラミングを使用する。
24.4.1 リファクタリングに適さない状況
リファクタリングは強力なテクニックだが、万能薬ではない。使用法を誤ると痛い目に遭う。
■ コードや修正の埋め合わせとしてリファクタリングを使用してはならない
リファクタリングの最悪の問題は、それが乱用されていることである。プログラマはうまくいく方法が見つかることを願ってコードを調整しているだけなのに、リファクタリングしていると言うことがある。リファクタリングとは、プログラムの振る舞いに影響を及ぼさない、動くコードの変更のことである。動かないコードを調整しているプログラマは、リファクタリングしているのではなく、ハッキングしているのだ。
|
■ リファクタリングをコードの書き直しにしない
コードに必要なのは小さな変更ではなく、すべてを捨てて最初からやり直すことかもしれない。リファクタリングが大がかりなものに発展していることに気付いたら、その部分のコードの設計と実装を最初からやり直すべきかどうかを検討しよう。
|
 |
 |
| INDEX | ||
| Code Complete 第2版 上・下 | ||
| 第24章 リファクタリング | ||
| 1．24.1 ソフトウェアの進化の種類 | ||
| 2．24.2 リファクタリング概論 | ||
| 3．24.3 リファクタリングの詳細（1） | ||
| 4．24.3 リファクタリングの詳細（2） | ||
 |
5．24.4 安全なリファクタリング | |
| 6．24.5 リファクタリング戦略 | ||
 |
||
 |
「BOOK Preview」 |
- 第2回 簡潔なコーディングのために （2017/7/26）
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21）
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために （2017/7/19）
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator （2017/7/18）
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
