リファクタリングとは? わかりやすく解説

Weblio 辞書 > 辞書・百科事典 > デジタル大辞泉 > リファクタリングの意味・解説 

リファクタリング【refactoring】

読み方:りふぁくたりんぐ

コンピュータープログラム動作機能・仕様変えずに、内部構造整理すること。保守管理再利用容易にするために行われる


リファクタリング

【英】 Refactoring

プログラム拡張性高めるために、プログラム動作帰ることなくプログラム内部構造変更すること。プログラム拡張し続けると、メンテナンスしづらいコード生まれることがよく起きるが、そのような場合にリファクタリングを行い、よりメンテナンスしやすく、より拡張しやすいコード作成するまた、リファクタリングには常にプログラム変更することによる危険性潜んでいるので、各修正ごとにテスト行い、リファクタリング前と同じ動作を行うかどうか確認することが重要になる

主なリファクタリングの処理には、長すぎるメソッド抽出細分化大きすぎるクラス分割わかりづらい名称の変更などがある。

関連用語


リファクタリング

プログラミングのほかの用語一覧
コーディング:  例外処理  リテラル  リトルエンディアン  リファクタリング  リファレンス  論理演算  論理演算命令

リファクタリング (プログラミング)

(リファクタリング から転送)

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2025/02/04 02:07 UTC 版)

リファクタリング (refactoring) とは、コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理することである。また、いくつかのリファクタリング手法の総称としても使われる。ただし、十分に確立された技術とはいえず、また「リファクタリング」という言葉に厳密な定義があるわけではない。

リファクタリング登場の経緯と目的

リファクタリングが登場する以前は、一度正常な動作をしたプログラムは二度と手を触れるべきではないと言われていた。なぜなら、下手に手を加えて動作が変わってしまうと、それに伴って関連する部分にも修正が加えられ、やがてその修正作業はプロジェクト全体に波及し対処しきれなくなる可能性があったからである。また、ソフトウェアテストを十分に行い、正常な動作が確認されたとしても、そのプログラムを少しでも改変してしまえば、その後バグ (欠陥) が見つかったときに、改変があったプログラムを疑わなければならない。

しかし、プログラムには必ず変更があり、プログラムはどうしても継ぎ接ぎだらけになることは避けられない。また、仕様が開発開始時から確定していることは少なく、開発をしている間にもソフトウェアに対する要求は日々変わり続けており、ソフトウェアには常に仕様変更に対応できる柔軟さが求められる。さらに、いくら厳密に設計しても実際に動作させないと分からない部分も多く、完璧な設計を行うことは不可能である。変更が必要になったとき、二度と手を触れられないほど煩雑になったソースコードを修正することは困難を極め、プログラマにも勇気が要求される作業になる。

そこで、Smalltalkプログラマなどの間で、常日頃からプログラムを整理し、仕様変更にも対応できる整理されたプログラムを書いていく考え方が生まれた。この過程では、ウォード・カニンガムケント・ベックラルフ・ジョンソンGoFの一人)などの人々が大きな役割を果たした。この手法がリファクタリングと呼ばれている。また、リファクタリングは、プログラムの全容を捉えるためにも効果的である。例えば、バグが検出された場合でも、ソースコードが整理されているので、修正しやすい。また、プログラマとしても、普段から修正しているコードに手を入れるだけなので、修正にも積極的になれる。さらに、設計者も設計ミスによる心残りをなくすことができる。そのため、「リファクタリングは設計の代用にもなる」とする意見もあり、事前設計を非常に簡素化する役割も担っている。

リファクタリングは、オブジェクト指向設計と深く関係している。ほとんどのリファクタリングは、オブジェクト指向の性質に沿ったものであり、オブジェクト指向のコードの再利用性を最大限に引き出すことができる。また、オブジェクト指向プログラミングを行える言語であれば、プログラミング言語の種類に関わらず、リファクタリングを適用できる。

リファクタリングを行うことで、開発が停滞してしまうのではないか、という心配をされることも多い。たしかに、リファクタリングを行っている間は、何の機能追加も行われない。しかし、たいていの場合は、設計が向上することで機能追加やバグフィックスをしやすくなり、開発のスピードは安定するばかりか、速くなることもある。また、すでに機能しているコードを危険に晒すべきでない、とする意見もあるが、手順を守りテストを十分に行えば、ある程度危険を減らすことができる。

主なリファクタリング

メソッドを抽出する
長すぎるメソッドは再利用性が低い。メソッドを抽出、細分化することで再利用性が高まり、呼び出し側メソッドの記述も読みやすくなる。処理の重複も減る。
双方向関連を単方向へ変更する
不要な参照は管理のための手間を増やし、オブジェクトの破棄を失敗させる。不要になった関連は消す。
クラスの抽出
大きくなりすぎたクラスを分割する。クラスを小さくすることで、そのクラスの役目を明確にできる。
switch文ポリモーフィズムに置き換える
switch文をポリモーフィズムに置き換えることで、新たな条件が追加されても分岐部分には変更の必要がなくなる。
メンバの移動
フィールドやメソッドが不適切なクラスにある場合、他のクラスとの余計な関連が増える。メンバを移動し、クラスの責任を整理する。
継承委譲に置き換える
継承では基底クラスのすべてのメンバを、サブクラスに許さなければならない。基底クラスの一部だけの機能を利用する場合は、継承の代わりに委譲を使う。
ダウンキャストカプセル化する
ダウンキャストは互換性のない型に変換してしまう可能性があるが、それをコンパイル時に察知することは出来ない。総称型テンプレート)がない言語では、カプセル化してクライアント側にダウンキャストの手間を減らすようにする。コレクションクラスなどでは特に必要。
コンストラクタをFactory Methodに置き換える
コンストラクタはそのクラスのオブジェクトを返すことしか出来ない。Factory Methodの導入によって柔軟なインスタンス化が可能になる。
引数オブジェクトの導入
たびたび一緒に受け渡しされる複数の値は、オブジェクトとしてまとめたほうが分かりやすい。

シンボル名の変更(Rename symbol)

シンボルが指す対象をより適切に象徴するシンボル名に更新すること。

シンボル名(クラス名・関数名・属性名など)は対象がもつ役割を正確に象徴・説明すべきである(c.f. 命名規則 (プログラミング))。当初は適切であった名称も、プログラムの変更によって不正確・曖昧になりうる。この場合、シンボル名の変更(リネーム)がおこなわれる。いくつかのエディタではファイルを跨いだシンボル名の一括変更をサポートとしており(VS Code: F2で一括リネーム[1])、リネームに必要なリファクタリングコストは非常に小さくなっている。

マーティン・ファウラーなどの人々が著したリファクタリングの解説書、『リファクタリング プログラミングの体質改善テクニック』(以下『リファクタリング』)では、70種類ほどのリファクタリングが挙げられている。

リファクタリングを行うタイミング

いつでもなんでもリファクタリングをすればよいというものではない。例えば、納期がぎりぎりに迫った場合などにリファクタリングを行っている余裕はないし、リファクタリングは将来に備えて行うものであるため、そのリファクタリングが実を結ぶ可能性は少ない。また、リファクタリングといえども、やはりプログラミングであるので、常にミスをする危険性は拭えない。

『リファクタリング』では、機能追加するときと、リファクタリングするときをはっきり区別することを勧めている(このことを比喩して「実装の帽子をリファクタリングの帽子に被りなおす」という)。リファクタリングしてばかりいては開発は進まないし、どのリファクタリングをするべきかはある程度開発が進まないと分からない。リファクタリングを開始するタイミングとして、コードに「不吉なにおい」を感じ始めたら、と提案している。これは似たようなコードの重複や、長すぎるメソッド、ひとつの変更の度に複数のクラスが影響を受ける、などの症状が見つかったときを指している。また、機能追加の前、コードレビュー時、バグフィックス時にもリファクタリングを勧めている。

テストの重要性

リファクタリングでは、プログラムの外観を変更してはならない。そのため、テストが非常に重要である。修正は段階的かつ小刻みに行い、わずかな変更であっても、その度にテストを行うことで、動作の異常をいち早く察知する。テストを行わずに一度にリファクタリングを行うと、プログラムの動作が気付かないうちに変わってしまい、その原因を突き止めることが難しくなる。プログラマにテストをサボらせないため、簡単にテストを実行できるツール (xUnit/JUnitなど) も必要である。また、テストを重要視することは、アジャイルソフトウェア開発のいくつかの開発手法(エクストリーム・プログラミングなど)における「テストファースト」や「テスト駆動開発」の考え方とも一致する。

リファクタリングの課題

リファクタリングには、いくつか課題が存在する。例えば、データベースに変更を加える場合、データを移行する必要がある。たしかに、中間層を挟むことで影響を緩和できるが、やはり時間が掛かることは否定できない。また、リファクタリングでは、従来のようにカプセル化されたクラス内だけでなく、インタフェースも変更することがある。それが広く公開されたインタフェースである場合、新しいインタフェースと古いインタフェースを両方保守しなければならない。また、修正するコードがあまりに酷い場合、新たに書き直したほうが早いこともある。リファクタリングは発展途上の技術であるため、これら以外の課題が見つかる可能性がある。

歴史

「リファクタリング」という用語が出版文献上初めて用いられたのはウィリアム・オプダイク(英語: William Opdykeラルフ・ジョンソンによる1990年9月の論文だった[2]。1992年に著されたグリスウッド(: Griswold)の博士論文[3]、オプダイクの博士論文[4]も、同じくこの用語を使った[5]。計算機コードのリファクタリングは10年にわたり非公式に行われてきたけれども、オブジェクト指向プログラムのリファクタリングに関する[5]ウィリアム・オプダイクの1992年の論文[4]が後続する、ウィリアム・グリスウッド(英語: William Griswoldの1991年の 博士論文は、機能的かつ手続的プログラムのリファクタリングに関する最初の主な学術的な仕事であり、そしてすべてこれらの理論と機械はずっとプログラム変換処理 (英語: program transformation システムとして可能だったけれども。すべてこれらの文献はリファクタリングの主だった手法の目録を与える;リファクタリングの方法はどのように方法を適用するか、そしていつその方法を適用すべきか(あるいはすべきでないか)について指し示す、記述を持っている。

統合開発環境のリファクタリング機能

最近の統合開発環境には、リファクタリング機能が備わっていることが多い。リファクタリングでは、修正対象のメソッドやクラスがどのクラスから利用されているかを調べる必要が発生する。これを単なるテキストエディタで調べようとすると、かなり面倒な作業になる上、見落としをする可能性も高い。

脚注

  1. ^ Renaming is a common operation related to refactoring source code and VS Code has a separate Rename Symbol command (F2). Visual Studio Code - USER GUIDE - Refactoring - Rename Symbol
  2. ^ Opdyke & Johnson 1990
  3. ^ Griswold 1991
  4. ^ a b Opdyke 1992
  5. ^ a b Fowler 2003

ウェブサイト

  • Fowler, Martin (2003-09-10), EtymologyOfRefactoring 

論文

  • Opdyke, William F.; Johnson, Ralph E. (September 1990), Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems, ACM 
  • Griswold, William G (July 1991), Program Restructuring as an Aid to Software Maintenance, University of Washington 
  • Opdyke, William F (June 1992) (compressed Postscript), Refactoring Object-Oriented Frameworks, University of Illinois at Urbana-Champaign 

参考文献

関連項目


リファクタリング

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/06/18 04:22 UTC 版)

Eclipse (統合開発環境)」の記事における「リファクタリング」の解説

記事参照 リファクタリング getter, setterメソッド自動生成や、try-catchの自動追加、java.util.ResourceBundleによる文字列外部化、クラス名メソッド名・変数名変更(それを参照している部分自動的に書き換わる)、メソッド移動抽出などをウィザード形式行ってくれる。

※この「リファクタリング」の解説は、「Eclipse (統合開発環境)」の解説の一部です。
「リファクタリング」を含む「Eclipse (統合開発環境)」の記事については、「Eclipse (統合開発環境)」の概要を参照ください。

ウィキペディア小見出し辞書の「リファクタリング」の項目はプログラムで機械的に意味や本文を生成しているため、不適切な項目が含まれていることもあります。ご了承くださいませ。 お問い合わせ

リファクタリング

出典:『Wiktionary』 (2021/08/21 07:52 UTC 版)

名詞

リファクタリング

  1. (プログラミング) 外部から見た時のプログラム振舞い変えずプログラム内部構造変えること。拡張性やメンテナンス性を向上するために行われ名前の変更や、長すぎたり頻出する処理の関数化などが含まれる

語源

英語: refactoring



英和和英テキスト翻訳>> Weblio翻訳
英語⇒日本語日本語⇒英語
  

辞書ショートカット

すべての辞書の索引

「リファクタリング」の関連用語

リファクタリングのお隣キーワード
検索ランキング

   

英語⇒日本語
日本語⇒英語
   



リファクタリングのページの著作権
Weblio 辞書 情報提供元は 参加元一覧 にて確認できます。

   
デジタル大辞泉デジタル大辞泉
(C)Shogakukan Inc.
株式会社 小学館
PHPプロ!PHPプロ!
©COPYRIGHT ASIAL CORPORATION ALL RIGHTS RESERVED.
IT用語辞典バイナリIT用語辞典バイナリ
Copyright © 2005-2025 Weblio 辞書 IT用語辞典バイナリさくいん。 この記事は、IT用語辞典バイナリの【リファクタリング】の記事を利用しております。
ウィキペディアウィキペディア
All text is available under the terms of the GNU Free Documentation License.
この記事は、ウィキペディアのリファクタリング (プログラミング) (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。 Weblio辞書に掲載されているウィキペディアの記事も、全てGNU Free Documentation Licenseの元に提供されております。
ウィキペディアウィキペディア
Text is available under GNU Free Documentation License (GFDL).
Weblio辞書に掲載されている「ウィキペディア小見出し辞書」の記事は、WikipediaのEclipse (統合開発環境) (改訂履歴)、JDeveloper (改訂履歴)、NetBeans (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。
Text is available under Creative Commons Attribution-ShareAlike (CC-BY-SA) and/or GNU Free Documentation License (GFDL).
Weblioに掲載されている「Wiktionary日本語版(日本語カテゴリ)」の記事は、Wiktionaryのリファクタリング (改訂履歴)の記事を複製、再配布したものにあたり、Creative Commons Attribution-ShareAlike (CC-BY-SA)もしくはGNU Free Documentation Licenseというライセンスの下で提供されています。

©2025 GRAS Group, Inc.RSS