リファクタリングの進め方・考え方の整理
Takagishiリファクタリングについて調べ直してみる。
Takagishiリファクタリングの定義
リファクタリングとは、外部から見た時の挙動は変えずに、プログラムの内部構造を整理することです。かつては「プログラムが一度完成したら、もう余計な手を加えるべきではない」とされるのが一般的でした。しかし現在では、リファクタリングは安定した長期運用を支える重要な工程とされています。定期的なリファクタリングでソースコードを整理すればトラブル時の対応も容易になり、担当者の負担が軽減されて短時間で解決できるなどの利点があります。
リファクタリング（refactoring）とは、ソフトウェア開発で、プログラムの動作や振る舞いを変えることなく、内部の設計や構造を見直し、コードを書き換えたり書き直したりすること。
リファクタリングとは
リファクタリング(code refactoring)とは、ソフトウェアのソースコードの構造や可読性を改善するソフトウェア設計の技法のひとつです。
既存のソースコードの内部構造を崩すことなく柔軟に変更し、保守性、拡張性、可読性を高めることを目的とします。リファクタリングを行うことで、既存のソフトウェアの品質を向上させ、保守性や拡張性を高め、新たな機能の追加やバグの修正を行うことが用意になります。
リファクタリングが広く世に認知されたきっかけとなったのは、ソフトウェア開発分野の第一人者として知られるイギリスの方法論者マーチン・ファウラーによって執筆された「リファクタリング ―既存のコードを安全に改善する―」(1999年)でした。リファクタリングが、今日のソフトウェア開発プロセスにおいて必要不可欠な位置付けにあること示したのは、ファウラー氏の貢献によるところが大きいと言えます。
リファクタリングの原典
リファクタリングの起源は、イギリスの方法論者マーチン・ファウラーによって執筆された「リファクタリング ―既存のコードを安全に改善する―」(1999年)であるようです。
現在は第二版が出版されています。
マーチン・ファウラー氏の新著「リファクタリング 2nd Edition」が完成、ほぼ全面的な刷新。日本でも11月22日発売
Takagishiリファクタリングの目的
リファクタリングの主な目的は、コードの可読性を高め、メンテナンスしやすくすることです。プログラムは完成後も仕様変更や機能追加が頻繁に発生します。このとき、分かりにくいコードは理解に時間がかかり、バグを招く恐れがあります。
リファクタリングにより、コードが整理されていれば、変更が迅速かつ正確に行えるようになります。また、シンプルなコードはバグの発生を防ぎやすくなります。ただし、リファクタリングを行う際には、プログラムが正しく動作し続けるよう、十分なレビューとテストが不可欠です。これにより、長期的なシステムの安定性と信頼性が向上します。
リファクタリングの目的
リファクタリングは以下の目的で行われます。
パフォーマンス向上
保守性を高める
コード量を減らす
コードの簡略化
コードの可読性向上
DRY（同じようなコードのコピぺをまとめる）
未到達コードの削除
拡張性を高める
コードの可読性向上: コードを理解しやすくすることで、開発効率を高めます。
コードの保守性向上: コードの変更やバグ修正を容易にします。
コードの拡張性向上: 新機能の追加を容易にします。
バグの発見: コードを整理する過程で、潜在的なバグを発見できることがあります。
パフォーマンスの改善: コードの構造を改善することで、パフォーマンスが向上する可能性があります。
なぜ、リファクタリングが必要なのか？
技術的負債は、放置すればするほど雪だるま式に増大し、解決が困難になります。早めの対処が肝心です。
近年、ビジネス環境は急速に変化しており、企業は迅速かつ柔軟に対応することが求められています。しかし、技術的負債を抱えたシステムでは、変化への対応が遅れ、ビジネスチャンスを逃すリスクがあります。
また、デジタルトランスフォーメーション（DX）の進展に伴い、ソフトウェアの重要性はますます高まっています。技術的負債を抱えたシステムは、DX推進の妨げになる可能性があります。
Takagishiリファクタリングができていないと何が起きるのか？
大体、慢性的にリファクタリングができていないコードベースは、以下のような症状を出しています。
しょっちゅうバグが起きる
バグ調査に時間がかかる
開発の効率が致命的に悪化している
エンジニアの不満が続出
パフォーマンスが悪い＝UXが悪い
誰も直せないバグがある＝バグ修正に思いの他時間がかかる
リファクタリングができない理由
なぜリファクタリングをしないのか
純粋に、そこまで興味がない
リファクタリングについて単純に知らない
変更したら壊れることを極端に恐れている
レグレッションを防ぐシステムがない
エンジニアの技量が足りない
諦めているか
プライド
保守の経験がない
上司の理解がない
仕様が定かでない
Takagishiリファクタリングの利点
可読性の向上: コードが読みやすくなり、理解や修正が容易になります。
重複の排除: 重複したコードを排除し、修正箇所を減らします。
複雑性の低減: コードの複雑さを軽減し、バグの発生を抑えます。
テスト容易性の向上: テストしやすいコードにすることで、品質保証を容易にします。
リファクタリングを行う目的は「プログラマーなど作業者の負担を減らすため」「ソースコードを読みやすくするため」「問題発生時に早く処理するため」「システムを安定して長く使うため」といった理由が挙げられます。
ソースコードを精密に検査・整理すれば、内部構造と役割を理解しやすくなるため、もしものトラブルが起きても原因を推測しやすくなります。
また、内部構造を作業担当者間で共有できるため、開発スピードが早まったり、システムを安定的に利用できる点もメリットです。
ソースコードの重複箇所を簡略化すると構造が単純化されるため、煩雑なソースコードが原因になるトラブルやシステムの劣化を防止できます。重複が多いソースコードは他者だけでなく自分自身にも解読が難しく、ロジックを変更するときに負担がかかりかねません。
他者が書いたソースコードは作業を引き継いだときに読みづらく、かえって時間や手間が増える可能性があります。リファクタリングを適切に行えば、誰にでも見やすく・扱いやすいソースコードになるでしょう。自身が書いたソースコードを他者に正しく読んでもらいたいときにも、このリファクタリングが有効です。
リファクタリングによってソースコードがシンプルになるとトラブル部分を発見しやすくなります。バグの発見だけではなく、将来的にバグの原因になりそうな箇所の推測も容易になります。
コード以外と向き合わなくていい
リリース予定日に追われない
妥協せずにコーディングができる
1.リファクタリング：それは技術的負債への処方箋
ソフトウェア開発において、「技術的負債」という言葉をご存知でしょうか？
技術的負債とは、開発スピードを優先した結果、将来的に修正が必要となる可能性のあるコードや設計上の問題を指します。例えるなら、目先の利益のために高金利の借金をするようなものです。短期的には開発を加速できますが、長期的には利息という形でコストが増大し、返済が困難になるリスクも伴います。
1.メンテナンス性の大幅な向上
コードの重複を排除し、モジュール化を進めることで、システムの保守性が格段に向上します。障害の原因特定が容易になり、部分的な変更に伴う影響範囲が限定されるため、システムの柔軟性が高まります。
コードレベルのリファクタリング: ソースコードの品質向上
コードレベルのリファクタリングは、ソースコードの可読性、保守性、拡張性を向上させるための手法です。以下は、リファクタリングで行う手法の一部ですすが、これらの手法は、開発者がコードを理解しやすくし、修正や拡張を容易にします。
関数やメソッドの抽出: 長すぎる関数やメソッドを分割し、役割ごとに独立させます。
変数名の変更: 分かりにくい変数名を、より意味の明確な名前に変更します。
コメントの追加: コードの意図や動作を説明するコメントを追加します。
重複コードの削除: 同じような処理を繰り返しているコードを共通化します。
設計パターンの適用: デザインパターンを適用することで、コードの構造を改善します。
Takagishiリファクタリングのデメリット
初手で壊れる
プロダクト開発は実装を進めるうちにだんだんできあがっていくものですが、リファクタリングの場合は最初の一手で完成品が壊れます。
...
あけてびっくり感がある
対象画面についてある程度把握している場合でも、いざ取りかかってみると裏機能・謎仕様・謎コードと出会うことが多々あります。
...
変わり映えしないテスト
実装が終わるとテストに入りますが、できあがったものはリファクタリング前のものと見た目も機能も全く同じなので、何の新鮮味もありません。
...
実装したもののテスト方法がわからない
仕様が複雑な画面の場合はテスト方法のわからない機能が稀にあり、調査してみると、ものすごくレアケースだったとか、実質呼ばれる機会のないものだったりすることがあります。
時間とリソースのコストが発生する
リファクタリングでソースコード分かりやすくするためには、ある程度の時間とリソースが必要です。そのため、短期的に見るとコストが発生するというデメリットが生じます。ただし、リファクタリングはバグの抑制や開発効率の向上につながるため、長期的な視点ではコストを抑えることが可能です。プロジェクト全体として得られる効果を考慮して、リファクタリングにどの程度の時間とリソースをかけるかを吟味する必要があります。
一時的な開発速度の低下
リファクタリングは、短期的には開発速度の低下を招く可能性があります。コードの整理や改善に時間を割くため、新機能の開発やバグ修正に対するリソースが減少します。
これにより、一時的にプロジェクトの進行が遅れることがあります。また、リファクタリング後には、改変されたコードに対して新たなテストが必要となり、これも開発速度に影響を与えます。特に大規模なリファクタリングの場合、影響範囲が広がり、短期的なパフォーマンスの低下につながる恐れもあるため注意しましょう。
しかし、リファクタリングの達人からすれば、ソフトウェアは「内部で」壊れる可能性もあります。設計に欠陥がある場合、コードは分かりづらく構造化は不十分で、たとえ現在アプリケーションが正確に機能し、外側からは壊れているように見えなくても、やはりリファクタリングを行い、「安定した」設計がなされるべきなのです。この意味で、リファクタリングは、有形とは言えないまでもソフトウェアの決定的な特性（設計、簡潔性、ソースコード理解の向上、信頼性など）を貫いています。
リファクタリングから短期的なメリットは得られない
これには、実際にリファクタリングでプログラムミングの高速化を図るというリファクタリング転向者から圧倒的な同意があります。今までのところ、私が言ったことを証明するために頼りになるような調査結果を知りえていないのですが、経験上、これは事実です。それはただ論理的であるにすぎません。取るに足りない、非現実的なまでに小規模なコードを処理しているのでない限り、全体的にコード少量化、重複箇所の減少化、状態の明確化が進むため、リファクタリングのメリットは、すぐに明らかになります。
Takagishiリファクタリング時の注意点
運用中のソフトウェアをリファクタリングするときには、現在動いているソースコードと別にテストコードが必要になります。リファクタリングは将来起こりうるトラブルを防ぐ効果を持っていますが、既存の動作しているソースコードとは別に追加のソースコードを作成しなければならないため、その作業の重要度を周囲に理解してもらう必要が生じる可能性があります。
リファクタリングは機能追加ではない
リファクタリングは、あくまで内部構造の改善を目的としており、新たな機能を追加するものではありません。
しかし、多くのプロジェクトでは、リファクタリングと新機能開発を一緒にご希望されるケースが多いのが現実です。
新機能開発を実施する場合には、機能追加とリファクタリングを同時に行うことでコードが複雑化し、バグが発生するリスクを回避するために、リファクタリングと機能追加を別のタスクとして計画し、実行することをご提案しています。
十分なテストが必要: リファクタリングの前後で動作が変わらないことを確認するために、十分なテストを実施することが重要です。自動テストを導入することで、効率的なテストが可能になります。
段階的な実施: 大規模なリファクタリングを一度に行うと、リスクが高まります。小さな単位で段階的に実施することで、リスクを最小限に抑えることができます。
コミュニケーション: リファクタリング中は、チームメンバーとのコミュニケーションを密にすることが重要です。進捗状況や問題点を共有し、協力して解決することで、スムーズなリファクタリングが可能になります。
Takagishiリファクタリングを浸透させるために
リファクタリングの文化を根付かせるためにはどうしたらいいか？
マネジメントと話すことかと思います。要するに、組織改革が必要なので、組織改革は一人の力では起こせません。
本当に組織を変えたいのであれば、影響力を持っている仲間を増やしていくしかないのです。
そこで、文化を変えたいあなたに求められるのは、
現実的な計画を作成すること
計画を実施した場合のメリットを説明すること
実施しなかった時のリスクを十分に理解してもらうこと
Takagishiリファクタリングを行うべきタイミング
リファクタリングはいつ行うべき？
A: リファクタリングは、以下のタイミングで行うのが効果的です。
機能追加や修正が困難になった時: 技術的負債が原因で、開発速度が低下している場合は、リファクタリングによってコードの品質を向上させることで、開発効率を改善できます。
システムの保守コストが増大している時: バグ修正や機能追加に時間がかかり、保守コストが増大している場合は、リファクタリングによってコードの可読性や保守性を向上させることで、保守コストを削減できます。
セキュリティリスクが高まっている時: 古い技術や脆弱性のあるコードは、セキュリティリスクを高めます。リファクタリングによって最新の技術やセキュリティ対策を導入することで、セキュリティリスクを低減できます。
新規プロジェクト開始前: 新規プロジェクト開始前に既存システムのリファクタリングを行うことで、新システム開発の土台を整備し、開発効率を高めることができます
Takagishiリファクタリングの進め方
リファクタリングの基本的な作業は、ソースコード内で重複していて読みにくく、バグの原因となりやすい部分の削除です。たとえソフトウェアの挙動に問題がないように見えても、ソースコードには改善の余地があるかもしれません。
その他、順番を入れ替えるなどの方法でネストを浅くする、ソースコード内で使用する変数や関数の名前をできるだけシンプルにするなどの方法も挙げられます。このような処置をすることで、他者や過去のソースコードを自身で見た際に各変数・関数の意味を理解しやすくなるでしょう。
リファクタリングを施していないソフトウェアは、どうしてもソースコードが煩雑になりがちです。無駄な重複が多いとバグ発生のリスクが高まり、修正も難しくなります。
一見して遠回りにも見えるリファクタリングの作業は、結果的に開発速度と品質を向上させます。ソースコードの理解が簡単になり、修正や機能追加を容易におこなえるようになるのです。
現状分析と課題の特定
まずは、現状のシステムを分析し、技術的負債の発生箇所や課題を特定します。
優先順位の設定と計画立案
特定した課題に対して、優先順位を設定し、リファクタリングの計画を立てます。ビジネスへの影響度や緊急度などを考慮して、優先順位を決めましょう。
実行とテスト
計画に基づいてリファクタリングを実行します。リファクタリングの前後で動作が変わらないことを確認するために、十分なテスト設計とテストを実施することが重要です。APPSWINGBYではリファクタリングの効果を最大限に得る為に、リファクタリングだけでなく、必ずテスト設計とテスト、QAによる品質向上についてもご提案しています。
効果測定と継続的改善
リファクタリングの効果を測定し、目標達成度を評価します。効果が不十分な場合は、改善策を検討し、継続的にリファクタリングを実施していくことが重要です。
リファクタリングの基本原則
リファクタリングの基本原則は、以下のとおりです。
テストを重視する
インクリメンタルに小規模な変更を繰り返す
コードとドキュメントの同期を保つ
チーム全体でリファクタリングポリシーを定める
それぞれの基本原則を詳しくみていきます。