コードに悩む企業のための実践的リファクタリングのすすめ方
複雑化した大規模システムのコードが抱える技術的な負債は、開発生産性の低下や障害リスクの増大といった大きな問題を生じさせます。これらの深刻な状況を払拭するための有効なアプローチがリファクタリングです。
本記事では、レガシーコードに取り組む多くの企業のシステム担当者の理解の一助となり、リファクタリングへのきっかけになればと考え、リファクタリング実践の恩恵や工夫、アプローチの大切さをできるだけわかりやすく解説したつもりです。
- . リファクタリングの基本
- 1. リファクタリングの基本原則とは何か?
- 1.1. リファクタリングとは
- 2. リファクタリングの基本原則
- 2.1. 基本原則その1. テストを重視する
- 2.2. 基本原則その2. インクリメンタルに小規模な変更を繰り返す
- 2.3. 基本原則その3. コードとドキュメントの同期を保つ
- 2.4. 基本原則その4. チーム全体でリファクタリングポリシーを定める
- 3. 代表的な5つの基本原則
- 3.1. DRY(Don’t Repeat Yourself)の原則
- 3.1.1.1.1. DRYのメリット
- 3.2. 単一責任の原則 (Single Responsibility Principle – SRP)
- 3.2.1.1.1. SRPのメリット
- 3.2.1.1.2. SRPのデメリット
- 3.2.1.1.3. SRPを適用する具体的な手方法
リファクタリングの基本
リファクタリングを進めるにあたって基礎となるリファクタリングの基本理解と原則について解説しています。
リファクタリングの基本原則とは何か?
リファクタリングとは
リファクタリング(code refactoring)とは、ソフトウェアのソースコードの構造や可読性を改善するソフトウェア設計の技法のひとつです。
既存のソースコードの内部構造を崩すことなく柔軟に変更し、保守性、拡張性、可読性を高めることを目的とします。リファクタリングを行うことで、既存のソフトウェアの品質を向上させ、保守性や拡張性を高め、新たな機能の追加やバグの修正を行うことが用意になります。
リファクタリングが広く世に認知されたきっかけとなったのは、ソフトウェア開発分野の第一人者として知られるイギリスの方法論者マーチン・ファウラーによって執筆された「リファクタリング ―既存のコードを安全に改善する―」(1999年)でした。リファクタリングが、今日のソフトウェア開発プロセスにおいて必要不可欠な位置付けにあること示したのは、ファウラー氏の貢献によるところが大きいと言えます。
リファクタリングの基本原則
リファクタリングの基本原則は、以下のとおりです。
- テストを重視する
- インクリメンタルに小規模な変更を繰り返す
- コードとドキュメントの同期を保つ
- チーム全体でリファクタリングポリシーを定める
それぞれの基本原則を詳しくみていきます。
基本原則その1. テストを重視する
リファクタリングは、ソフトウェアの品質を向上させるための手法ですが、品質を向上させたことを確認する必要があります。そのため、リファクタリング前後で動作に変化がないことを保証するために、事前に単体テストスイートを準備し、コード変更後も全てのテストがパスすることを確認します。
- リファクタリング前に単体テストを準備する。
- 単体テスト実施し、動作確認を行う。
- リファクタリング後に単体テストを実施する。
リファクタリングでは、テストにはじまりテストに終わると言っても過言ではありません。それほどにテストを重視する必要があります。
基本原則その2. インクリメンタルに小規模な変更を繰り返す
リファクタリングは、ソフトウェアの構造や可読性を改善するための手法です。そのため、一度に大きな変更を行うと、ソフトウェアの動作に影響を与える可能性があります。
大規模なコード変更を一度に行うと想定外の動作変化が発生するリスクが高いため、小さな変更を積み重ねるインクリメンタルアプローチを取ります。
その後は、小さな変更を繰り返して、ソフトウェアの品質を向上させ、ソフトウェアを徐々に成長させていきます。
基本原則その3. コードとドキュメントの同期を保つ
リファクタリングを行うと、ソフトウェアの構造や可読性が改善されます。そのため、ソフトウェアのドキュメントを更新して、変更を反映させます。
具体的には、ソースコードと設計文書は常に同期を取って変更を管理します。その理由は、ドキュメント未更新によって発生する技術負債を未然に回避することです。常に開発チーム内の情報共有レベルを一致させることで、リファクタリングだけでなく、リファクタリング後の開発速度やコードの品質の向上、バグの混入を未然に防ぐなどソフトウェアの品質向上に大きく貢献することができます。
基本原則その4. チーム全体でリファクタリングポリシーを定める
リファクタリングのポリシーを定めることで、リファクタリング範囲、対象、頻度等の基本方針を組織的に定め、個人レベルでコード品質基準が異なることのリスクを回避します。
リファクタリングのポリシーを定める際には、以下の点を考慮します。
- リファクタリングを行う目的
- リファクタリングを行う範囲と対象
- リファクタリングを行うタイミング
リファクタリングの基本原則を守ることで、ソフトウェアの品質を向上させ、保守性や拡張性を高めることができます。
代表的な5つの基本原則
この章では、リファクタリングを行う上で参考になるソフトウェア設計・開発における代表的な5つの基本原則をご紹介します。
ここで取り上げている5つの基本原則はリファクタリングを行う上での基礎となる考え方を体系的にまとめた概念的なものになりますので、具体的なリファクタリングについて知りたい方はスキップして頂いて構いません。
代表的な5つの基本原則のひとつ目は、”DRY”呼ばれる原則です。正直、あまり聞きなれない単語かもしれませんが、ソフトウェア開発における重要な原則のひとつとなっていますので、ここでご紹介しておきます。
それではさっそくはじめましょう。
DRY(Don’t Repeat Yourself)の原則
まずひとつめは、DRYです。DRYは、Don’t Repeat Yourself 原則の略でソフトウェア開発における重要な原則のひとつです。
DRYの原則は、同じコードや同じ概念をシステム内で複数回繰り返さないようにするというもので、この原則の目的は、コードの重複を最小化し、保守性を向上させ、コードの変更や修正を容易にすることです。
DRYの原則に従うと、同じ機能やロジックが必要な場合は、それを単一の場所に抽象化して再利用可能な形にまとめることができます。これにより、修正が必要な場合や新しい機能が追加される場合でも、変更が一箇所に集中し、コードの一貫性が維持されます。
DRYのメリット
DRYを実践することで、得られるメリットは次の通りです。
- 保守性向上: 重複したコードを排除することで、変更や修正が容易になります。
- 効率的な開発: 同じ機能を再利用することで、新しい機能の実装が迅速になります。
- エラーの削減: 同じコードが複数箇所に存在すると、変更を加える際にミスが生じやすくなります。DRYを実践することで、これらのミスが削減されます。
同じコードが複数箇所に存在すると、変更や修正が煩雑になります。DRYの原則は、同じ情報を複数回書かないようにすることで、コードの品質だけではなく保守性も向上させます。
開発プロセスを効果的にするために広く受け入れられているのがDRYの原則です。
単一責任の原則 (Single Responsibility Principle – SRP)
次にご紹介するのは、Object Mentor社の創業者でありソフトウェア開発であるロバート・C・マーチンが提唱したソフトウェアの品質向上を目的としたSRP(Single Responsibility Principle)単一責任の原則です。
SRPは「1つのモジュールまたはクラスは1つの責任を持つべきである」という考え方であり、具体的には「クラスやモジュールが1つ以上の理由で変更されることを防ぐ」よう設計されるべきという原則です。
単一責任の原則(SRP)を適用するためには、クラスやモジュールの責任を明確に定義し、責任が重複している場合は分割する必要があります。SRPはソフトウェア開発における重要な原則であり、SRPに基づいて設計することでソフトウェアの品質を向上させることができる原則のひとつなのです。
SRPのメリット
SRPを適用するメリットは、次の通りです。
- コードの可読性・保守性の向上
- バグの発生率の低下
- テスト容易性が向上する
- コードの可読性が向上し、理解と保守がしやすくなる
- 変更への頑健性が向上し、要件変更時の影響範囲が限定化される
SRPのデメリット
SRPのデメリット(注意点)としては、責任の定義が曖昧になりがちであること、過剰なモジュール分割によるオーバーヘッドが発生しうることなどがあげられます。
これらの注意点を解決する方法としましては、責任の重複を判断する際の客観的な基準を定めおくことや、クラスやモジュールを分割する際の粒度を予め定めておくことで、これらの問題を解決することができます。
開発チーム内で共有化しておくことも開発を進める上での助けになることでしょう。
その他、SRPの原則を実行する際に注意点は以下の通りです。
- コードの可読性が低下する可能性がある。
- バグの原因をつくってしまう可能性がある。
コードの変更の際に、複数の箇所を修正する必要があるということを念頭においておきましょう。
SRPを適用する具体的な手方法
SRPを適用する具体的な方法は、コード変更の理由を洗い出し、変更原因ごとの影響隔離を行うことです。名前から動機が明らかな小規模なモジュールを多数作成するのが SRP の設計手法といえます。
….
続きは資料ダウンロードよりお読み頂けます。
システム開発にお困りではありませんか?
もしも今現在、
- どのように開発を依頼したらよいかわからない
- どのように開発を依頼したらよいかわからない
- 企画や要件定義の段階から依頼できるのか知りたい
- システム開発費用がどれくらいかかるのか知りたい
- 見積りがほしい
など、システム開発に関するご相談・ご依頼がございましたら、お気軽にご相談ください。APPSWINGBYでは、「アプリでお客様のビジネスを加速し、お客様とともにビジネスの成功と未来を形作ること」をミッションとしています。大手SIerやR&D部門で培った経験やノウハウ、高度な技術力でお客様の「やりたい」を実現します。
リファクタリングエキスパートが
ソースコードを最適化!
APPSWINGBYのリファクタリングサービスでは、外部のふるまいを変更することなくコードの明瞭性を向上させ、不必要な複雑性を排除し、コードを最適な状態にします。これにより、保守性が向上し、将来の変更や追加が容易になります。また、最新の開発ベストプラクティスに基づいてコードをアップデートすることで、セキュリティの向上やパフォーマンスの最適化も実現します。