ポイント: コードリファクタリングは、その機能性を変更することなく、コードの可読性と保守性を向上させ、技術的負債に対処します。それは「汚れたコード」をクリーンなコードに変え、将来のソフトウェア開発を促進します。
- リファクタリングは、理解を高め、コードの保守を簡素化します。
- 定期的なリファクタリングは、技術的負債を防ぎ、ソフトウェアの品質を向上させます。
私たちは皆、こういう状況に直面したことがあるでしょう：次のリリースのために、プログラムに最後の機能を追加する必要がありますが、コードを整理し、構造化し、他の部分と整合させるための時間がありません。代わりに、機能を少し雑な方法で追加しなければならず、そうすることにしました。幸運なことに、リリースは順調に進み、機能はスムーズに追加され、次のスプリントに移ることができます。しかし、最もクリーンでも明確でもないそのコードはどうなるのでしょうか？以前の記事では、技術的負債について話しました。これは、ソフトウェア開発中に特定の作業が遅れることで、時間通りに納品するための考え方です。こうした短期的な解決策は今は機能しますが、長期的にはソフトウェアにとって最善ではありません。この作業は「負債」になり、最終的には対処しなければなりません。この記事では、技術的負債を減らす手段としてのコードリファクタリングを見ていきます。
コードリファクタリングの意味
コードリファクタリングは、外部の挙動や機能を変更したり追加したりせずにコンピュータコードを再構成するプロセスとして定義されています。リファクタリングには多くの方法がありますが、最も一般的には、一連の標準化された基本アクションを適用することから成ります。この変更は、ソフトウェアの挙動と機能を保持します。なぜなら、それらの変更は非常に小さく、新しいエラーを生成または導入する可能性が低いからです。
コードリファクタリングの重要性
最初は、その目的が少し冗長に思えるかもしれません。確かに、コードリファクタリングは、ソフトウェアの非機能的属性を改善していますが、それが全体的な機能性に役立たないのであれば、何の意味があるのでしょうか？専門家は、コードリファクタリングの目的は、汚れたコードをクリーンなコードに変えることで、プロジェクトの全体的な技術的負債を減らすことだと言います。汚れたコードは、保守や更新が難しく、理解や翻訳がさらに難しいコードを指す非公式な用語です。汚れたコードは、開発中に発生する締切の結果として典型的に発生します。必要に応じて機能を追加または更新する必要があるため、バックエンドの外観が理想的でなくてもそうせざるを得ません。汚れたコードは、そのコードの匂いによって見つけることができます。これは技術的負債の考え方です。コードが可能な限りクリーンであれば、後の反復で変更や改善が容易になります。そうすることで、将来の自分や、コードを扱う他のプログラマーがその構造を評価できます。汚れたコードが清掃されない場合、それは雪だるま式に膨れ上がり、将来の改善を遅らせます。なぜなら、開発者は変更する前にコードを理解し追跡するために余分な時間を費やさなければならないからです。汚れたコードの種類には以下が含まれます：
- 操作があまりにも大きくて扱いきれないコード、メソッド、またはクラス
- オブジェクト指向プログラミング原則の不完全または不正確な適用
- 冗長な結合
- 望ましい変更が適切に機能するために、複数の領域で繰り返しコード変更が必要なコードの領域
- 不要なコードであり、それを削除しても全体的な機能性に悪影響を及ぼさない
一方、クリーンなコードは、はるかに読みやすく、理解しやすく、保守が容易です。そのため、将来のソフトウェア開発が容易になり、短期間で高品質の製品を得る可能性が高まります。
リファクタリングのタイミング
リファクタリングの適切なタイミングを知るのはそれほど難しくありません。あなたが開発者であれば、必要な機能を作成するためにどこで妥協したかをすでに知っているでしょう。プロジェクトを共有しているチームの一員であれば、リファクタリングを優先するのが難しいかもしれませんが、いくつかのヒントがあります：
- 3の法則に従ってリファクタリングすること：
- 初めて何かを行う場合は、汚れたコードであっても、ソフトウェアが必要なように機能するために完了させます。
- 同様の変更を2回目に行う場合は、同じ方法で再度行います。少し知識があるので、よりスピーディーに行えるかもしれませんが、コードはまだ完全にクリーンではありません。
- この変更に3回目に出くわしたときは、リファクタリングを始めます。
- コードレビュー中にリファクタリングすること。 これは、コードが本番環境に投入される前にクリーンアップする最後の機会です。2人でのレビューを試みることで、迅速かつ簡単な変更を修正し、どの難しいコード変更が時間をかける価値があるかをよりよく評価できます。
- 定期的にリファクタリングすること。これは、全日を献げる必要はありませんが、ルーチンに組み込むことができます。例えば、作業日の最後の1時間をリファクタリングに使うことです。(ボーナス：プロアクティブなリファクタリングは、マネージャーやチームが追加の時間を割く必要がなくなることを意味します。)
リファクタリングを行う際に、一部のリファクタリング純粋主義者は、バグを修正しているときにリファクタリングを行うべきではないと主張します。リファクタリングの目的は機能性を改善することではありません。しかし、クリーンなコードは本質的にバグの数を減らします。バグは汚れたコードの結果であることが多いためです。コードを清掃することで、リファクタリングセッションを設けたり、バグを修正したりしても、問題が発生する前にバグを軽減できます。
コードリファクタリングの手法
コードをリファクタリングする方法はいくつかありますが、最良のアプローチは、一度に一歩ずつ進め、各変更後にテストを行うことです。テストは、主要な機能が保持されることを保証し、コードが予測可能かつ安全に改善されることを確保します。リファクタリングは、手動プロセスであることが多かったですが、一般的な言語用の新しいリファクタリングツールにより、プロセスを少し速めることができます。それでも、ツールが実際に何をしているのかを理解することが役立つ場合があります。また、あまり一般的でない言語の場合、優れたリファクタリングツールが利用できないこともあります。どの手法を採用するかは、コードの問題によって異なることがよくあります。以下は一般的なリファクタリング手法です：
- 今後の変更を容易にするために、重複を削除し、ストリームラインするために構成メソッドを修正すること。
- 時間が経つにつれて不要に複雑になる条件式やメソッド呼び出しを簡略化し、クラス間の相互作用のインターフェースを改善すること。
- 機能をオブジェクト間で移動させ、クラス間の機能をより適切に分配すること。これには、機能を安全に移動させたり、新しいクラスを作成したり、実装の詳細を隠したりすることが含まれます。
- データを整理し、クラス間の関連付けを改善して、クラスが再利用可能で移植可能になるようにすること。
- 一般化を改善すること。
コードリファクタリングチェックリスト
クリーンなコードの良い停止ポイントは何ですか？このチェックリストは、コードがクリーンであるかどうかを判断するのに役立ちます：
- 他のプログラマーにとって明白であること。これは、より明確な構造を命名、クラス、メソッドのために作成することや、より洗練されたアルゴリズムを改善することができます。
- 重複がないこと。変更を2重にするたびに人為的エラーの可能性が高まります。
- 可動部が最小限であること、クラスの数のように。覚えるべきことが少ないほど、保守が楽になり、クリーンアップも簡単になります。
- すべてのテストに合格すること。大部分がテストに合格している場合でも、コードは汚れています。
- 保守が容易であること。将来の改善にかかる時間が少なくなります。
リファクタリングの利点
リファクタリングの主な利点は、汚れたコードをクリーンにすることで技術的負債を減らすことです。クリーンなコードは、元の開発者にも、将来そのコードに取り組む他の開発者にも読みやすく、保守や将来の機能追加が容易になります。複雑さが少ないコードは、ソースコードの保守を向上させ、内部アーキテクチャをより表現力豊かにします。クリーンなコードは、設計要素やコードモジュールが再利用可能であることを意味します。コードがうまく機能し、クリーンであれば、それは他の場所でのコードの基盤になる可能性があります。リファクタリングは、開発者がコードや設計の決定をよりよく理解するのにも役立ちます。初心者レベルとより高度なプログラマーの両方が、他の人がどのようにコードの中で作業し、機能が増加し変化する中で構築してきたかを見ることで利益を得ることができます。これにより、集団的な所有感が促進されます。つまり、一人の開発者がコードを所有するのではなく、チーム全体がそれに責任を持つということです。リファクタリングの行為は、フロントエンドの目的がない小さなコードの部分を変更することを意味しますが、優先度の高いタスクと比較すると重要性が低く思えるかもしれません。しかし、そのような変更の累積効果は重要であり、より良い機能を持つチームやプログラミングアプローチにつながる可能性があります。
これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を代表するものではありません。