※本記事は、Mohamed Taman による “Refactoring Java, Part 1: Driving agile development with test-driven development” を翻訳したものです。

本記事を PDF でダウンロード（英語）

リファクタリングで組織のコードがシンプルになり、バグの減少と容易なメンテナンスにもつながる

October 9, 2020
 

リファクタリングとは、コードをシンプルにして一貫性を高めることです。シンプルなコードにすれば、融通が利くようになるほか、すばやく変更したり、新しい機能を導入したり、組織において変化を続けるニーズに合わせたりすることが容易に可能になります。

本シリーズでは、リファクタリングについて、練習を通して学びます。その目的は、コードを書いてリファクタリングや最適化を行い、その過程で新機能を追加することにあります。コードを適切にリファクタリングすることで、開発者がより迅速に問題を解決できるようになり、顧客に喜んでもらえる高品質なソフトウェア製品を短時間で開発できるようになります。

 

学習する内容

本シリーズ記事では、実践的な「形」（かた）に基づいて、アジャイル開発に適したリファクタリングの基本について説明します（「形」については、後ほど説明します）。最初の記事となる今回は、テスト駆動開発（TDD）環境をセットアップし、変数名の変更、メソッドの抽出、メソッドのインライン化などの基本的なリファクタリング・テクニックを紹介します。

2回目の記事では、明らかな技術的負債（不注意なプログラミングによって紛れ込んだ効率の悪さやエラー）に対処することで、どうすればレガシー・コードを安定させることができるかについて取り上げたいと思います。

3回目の記事では、リファクタリングを行って、コードをシンプルにし、重複を削除し、再利用可能なオブジェクトを増やす実例を紹介する予定です。シンプルになったコードベースにすばやく新機能を追加する方法を実際に紹介するので、リファクタリングによってアジャイル・ワークフローがどのように補完されるかをわかっていただけると思います。

まずは、基本的な定義や考え方から紹介します。

リファクタリングとは：リファクタリングはコードを改善するプロセスです。リファクタリングの目的は、品質を改善し、ソフトウェア製品の変更を容易にすることにあります。リファクタリングを行うと、コードはシンプルになります。コードの行数が少なくなれば、潜在的なバグの数も少なくなります。

ここで適用できる、アジャイル・ソフトウェア開発に関する2つの原則は、シンプルさと技術的優位性です。

  • コードをシンプルにすれば、技術的な俊敏性を高めることができます。たとえば、コードをすばやく変更して新機能を追加できるようになります。
  • 技術的な俊敏性を高めれば、ビジネスの俊敏性を高めることができます。つまり、ユーザーなどのステークホルダーが持つ、変化を続けるニーズを満たすために、テック製品を簡単に変更できるチャンスが増えます。

そのため、適切にリファクタリングされたコードベースからは、ビジネスの問題が迅速に解決されるとともに、皆に愛される高品質なソフトウェア製品が短時間で開発されて提供されるという柔軟性がもたらされます。

品質第一のテスト駆動開発：リファクタリングの土台となるのは、確かなテストです。コードの動作が正しいことを検証するために適切に定義したテスト・ケースがなければ、リファクタリングによってコードの外部動作が変わっていないことを保証できません。リファクタリングのプロセスは、コードの外部動作に影響を与えずに、その内部構造を変えることです。

本記事では、TDDのテスト記述法に従い、コードが正しく動作することを証明する自動テストを記述します。新しくコードを書くとき、TDDは正しいコードを書くための指針となります。そしてリファクタリングする場合、すなわち現在のコードを改善する場合には、リファクタリングを安全なものにするためのガイド・レールがTDDから提供されます。

新しい機能を記述する場合、TDDはインタラクティブなプロセスになります。このプロセスは、赤、緑、リファクタリングという3ステップで表されます。

  • 新機能のテストを新しく記述します。もちろん、新機能はまだ動作しないので、コードのテストは失敗します。TDDでは、テストは赤の状態になったと言います。
  • 新機能を実装するJavaコードの記述を、テストに合格するまで続けます。他のすべてのテストにも合格し続けている必要があります。つまり、テストは緑の状態になっています。
  • リファクタリングにより、実稼働環境のコードをクリーンアップして改善します。これによって、よりよいコードとなります。すべてのテストに合格し続けている必要があります。
     

図1に示すように、新機能に満足するまで、この手順を何度でも繰り返します。

図１：テスト工藤開発の反復ステップ

TDDについてさらに詳しく知りたい方は、筆者の記事「テスト駆動開発：実はそれは設計技術です」をご覧ください。

コードの「形」を学ぶ：コードの「形」とは、新しいコーディング・スキルを学ぶためのテクニックです。武道において、繰り返し練習する一連の動きを「形」と呼びます。ある動きを何度も繰り返すと、体がその動きを覚え、やがては考えることなく、その動きを行うようになります。

コードの「形」も武道と同様ですが、対象となるのはコーディングの問題です。簡単な問題を取り上げ、その問題を解決するための一連の動きに従います。一連の動きを何度も繰り返すと、体がその動きを覚えます。その結果、体と脳は、次に同じようなコーディングの問題に出会ったときにどうすればよいのかを覚えています。

ここで言う一連の動きとは、テスト駆動開発の赤－緑－リファクタリングのループです。赤－緑－リファクタリングのループを何度も繰り返すと、優れたリファクタリングを体が覚えます。目標は、実際の実稼働環境のコードを書くときにリファクタリングのことを考える必要がなくなり、無意識で行うようになることです。

知っておくべきこと：本シリーズ記事から最大限に学ぶには、普段からコードを書いている必要があります。リファクタリングは、どんなプログラミング言語にも適用できます。ここでは、すべての開発とリファクタリングをJavaで行いますが、Javaについて詳しくなくても理解できます。

すべてのソース・コードのファイルは、筆者のGitHubリポジトリから取得できます。または、次のようにしてクローンしてください。


~$ git clone https://github.com/mohamed-taman/Agile-Software-Dev-Refactoring.git

コーディングはせずに読み進めたい方は、本記事の手順をそのままお読みください。実際にコードを追ってみたい方のために言うと、各記事は複数の手順に分かれており、それぞれの手順でTDDの赤－緑－リファクタリングの状態が変わるごとにgitにコミットしています。そのため、コミットをたどれば、差分や、最終的な「形」の要件に向けて行われたリファクタリングを確認できます。

最大限の価値を得るには、お気に入りのIDEを立ち上げて、記事の手順に従って実際にコードを書き、リファクタリングしてみてください。これを行う場合、以下のものが必要です。

これで、最初の演習に向けたセットアップが可能になります。この演習では、ローマ数字をアラビア数字に変換するソフトウェアを書きます。アラビア数字とは、私たちが毎日使っている1、2、3などの数字です。ローマ数字とは、I、V、Xのように文字で表される数字です。この「形」のユーザー・ストーリーは、「生徒が宿題の評価をすばやく確認できるように、ローマ数字をアラビア数字に変換する教師用のツールが求められている」というものです。

 

手順１：新しいコードの「形」をセットアップする

このサンプルでは、全部の要件を深く追求することはしません。その代わり、TDDのリファクタリング・プロセスに関する重要な考え方とテクニックを説明するために、簡単な事例をいくつか提示します。したがって、この簡単なサンプルでプロセスを判断しないでください。数多くの考え方やヒント、秘けつはその次に登場します。

TDDを使ったローマ数字コンバータのサンプルの全体について詳しく知りたい方は、先ほど紹介した、筆者の記事をご覧ください。

今回の「形」を始めるには、以下の手順に従います。ここではIntelliJを使っていますが、任意のIDEを使用できることを思い出してください。

  1. IntelliJを起動し、新しいプロジェクトを作成します。左側で「Maven」を選択し、「Next」をクリックします。
  2. 今回はローマ数字の「形」なので、NameにはRomanNumeralsなどと入力します。GroupIdにはcom.siriusxi.javamag.kata、ArtifactIdにはRomanNumerals-Converterと入力します。「Finish」をクリックします。
  3. 画面右下隅に、Maven projects need to be importedというウィンドウが表示されます。「Enable auto-import」をクリックします。
  4. プロジェクト・ナビゲータでRomanNumeralsを開き、ソース（src）フォルダを開いてから、testフォルダを開きます。javaフォルダを右クリックし、「New Package」をクリックします。パッケージ名はMavenのGroupIdに合わせます。com.siriusxi.javamag.kataと入力して「OK」をクリックします。
  5. 「com.siriusxi.javamag.kata」パッケージを右クリックし、「New Java Class」を選択します。新しいクラス名にRomanNumeralsConverterTestsと入力し、「OK」をクリックします。

IntelliJによって最初の数行のコードが自動生成されることにお気づきでしょう（図2参照）。実行可能なコードがないので、これは完璧なソフトウェアです。つまり、コードがないのでバグもありません。

図２：IDEで自動生成された、バグのない 0 行のコード

今回の「形」の残りの部分における目標は、コードを前述の理想に可能な限り近づけることです。コードの行数は、可能な限り少なくすべきです。そうすれば、バグが最小限に抑えられ、技術とビジネスの俊敏性が最大限に高まるからです。

 

手順２： TDD のテスト環境をセットアップする

今回の「形」を先に進めるため、テスト・フレームワークとしてJUnitをセットアップします。赤－緑－リファクタリングの3ステップを覚えているでしょうか。まずは、JUnitが存在して問題なく動作することを確認するため、失敗するテストを作成します。

  1. コード・エディタの4行目に@Testと入力し、[Enter]キーを押します。
  2. 続いて、メソッド名public void isJunitWorking()と左波括弧を入力し、[Enter]キーを押します。
  3. 6行目にassertTrue(false)と入力します。

画面上の赤い部分のそれぞれに注目してください。赤い部分が多いので、コンパイルもできません。ここでの問題は、まだ、JUnitフレームワークを使うようにプロジェクトを構成していないことです。この問題をすばやく解決して「形」の解決にさらに集中できるように、IntelliJに構成を修正してもらいます。

  1. 4行目の@Testの上にカーソルを移動し、macOSでは[Option]+[Enter]キー（Windowsでは[Alt]+[Enter]キー）を押し、「JUnit 5.4」を選択してクラスパスに追加します。内部的には、IntelliJによってプロジェクト構成にJUnitが追加されています。さらに、3行目にimport文が追加されていることに注意してください。
  2. 8行目のassertTrueがまだ赤いままであることに注目してください。IntelliJの提案に従って[Option]+[Enter]キーを押すと、5行目にimport文が追加されます。赤い部分がすべてなくなったことにも注目してください。コードがコンパイルできるようになりました。
  3. ここで、単体テストを実行します。「RomanNumeralsConverterTests」を右クリックし、「Run RomanNumeralsConverterTests」を選択します。画面下部のJUnitウィンドウに、isJunitWorkingが失敗したと表示されます。この動作はまったく問題ありません。これは失敗するテストで、TDDの赤－緑－リファクタリングのステップの1つ目です。
  4. ここでの目標は、最小限のコードを書いて、このテストを緑の状態にすることです。10行目のfalseをtrueに変更します。
  5. テストを再実行すると、すべて緑の状態になります。これで、赤－緑－リファクタリングのステップにおける緑の部分に到達しました。コードを見てみると、ここでリファクタリングできるものは何もないように見えます。つまり、改善の余地はないということです。したがって、これで完了です（図3参照）。
     

図２：何もしないものの、最初の単体テストには少なくとも合格する Java コード

 

ところで、ここではIntelliJにプロジェクトの構成を行ってもらいました。最新のIDEは、プロジェクトの構成などの作業を自動で行うのが得意です。今回の「形」を進めるにあたっては、プロジェクトの構成などの作業を可能な限りIDEに任せて自動化します。

 

手順3：最初のリファクタリング　－　変数名を変更する

ローマ数字の「形」を解決するため、まずは一番シンプルなテスト・ケースとして、1桁のローマ数字から始めます。たとえば、ローマ数字のIはアラビア数字の1に変換されます。また、Vは5、Xは10を意味します。最初の動作テストを記述するところから、問題の解決を始めます。

11行目で[Enter]キーを2回押します。@Testと入力して[Enter]キーを押してから、public void convertsSingleRomanDigit(){}と入力します。

TDDは問題を解決するソリューションを設計する際の指針であり、記述するテストはソリューションのコードの指針です。ここで必要になるのは、整数を返すメソッドです。このメソッドは、convertのような名前で、変換したいローマ数字を入力文字列として受け取ります。したがって、このメソッドはint arabic = convert(“I”);のようになります。

テスト・ケースを完成させるため、1に等しいことをアサートします。「1」は、ローマ数字のIをアラビア数字の整数値に変換したときに期待される結果で、convertメソッドの戻り値になります。つまり、assertEquals(1, arabic);とします。

この時点では、赤い部分が多数あります。それで問題ありません。赤－緑－リファクタリングのステップの1つ目に戻っています。再び、コードに赤い部分が多く、コンパイルもできない状態になっています。このコードを修正していきましょう。

  1. IntelliJにヒントが表示されています。[Option]+[Enter]キーを押すと、5行目にimport文が挿入されます。これで、assertEqualsはコンパイルできるようになります。
  2. convertが赤くなっているのは、Javaコードにconvertメソッドが実際には存在しないからです。赤い電球のアイコンをクリックし、提案を確認します。ここでは、「Create method convert」を選びます。すべてデフォルトのままとして、[Enter]キーを何度か押します。
  3. テストを実行すると、結果は赤くなります。コードはコンパイルできますが、新しいテストは失敗します。これから、最小限のコードを書いて、テストを緑の状態にします。
  4. 21行目に戻り、1を返すように変更します。テストを再実行すると、今度はすべて緑の状態になります。次は、3ステップの3つ目に入ります。このコードを改善する余地はあるでしょうか。
     

手順３．１：コードの改善　最初に目につくのは、20行目にあるiという名前の引数です。1文字というのは説明が十分ではなく、長期的なメンテナンスには向きません。そこで、もう少しわかりやすく変更します。
iを選択して右クリックし、「Refactor」を選択してから「Rename」を選びます。この引数の名前を、わかりやすく実態に即したものに変更します。ここでは、romanNumeralのような名前にします。[Enter]キーを押し、テストを再実行して、外部動作が変化しなかったことを確認します。引き続き、すべて緑の状態です。
これが最初のリファクタリングです。変数の名前を変更して、目的がわかりやすくなるようにしました。

 

手順４：一連のマイクロリファクタリングを行う

コードを見てみると、他にも改善できる点があることがわかります。テスト・コードの一部であるかのように、テスト・クラスに新しいメソッドを作成していますが、これは正しい方法ではありません。この新しいメソッドは、ソリューションの一部なので、別のクラスに移動する必要があります。そのクラスは、ソース・コードのテスト領域ではなく、メイン領域の一部になるようにします。

これから行うのは、一連のリファクタリングという優れたプロセスです。時として、リファクタリングの規模が大きいこともあります。大規模なリファクタリングは、新たな欠陥が紛れ込む可能性があるために、リスクを伴うことがあります。そのため、1つの大きなリファクタリングではなく、一連のマイクロリファクタリング（細かなリファクタリング）を行います。それぞれのマイクロリファクタリングの後にテストを再実行し、問題がないことを確認します。

手順4.1：convert()をstaticに変更する：最初のマイクロリファクタリングとして試みるのは、convertメソッドを専用のクラスに移動することです。

  1. convertを右クリックし、「Refactor」→「Move」の順にクリックします。ここでIntelliJに、このメソッドを専用のクラスに移動できるようにするには、まずメソッドをstaticにする必要があるというメッセージが表示されます。そのため、これが最初のマイクロリファクタリングになります。
  2. 「Yes」をクリックしてから「Refactor」ボタンをクリックし、変更内容が適切であることを確認します。
  3. テストを再実行し、直前の操作で外部動作が変化しなかったことを確認します。すべて緑の状態のままなので、次のマイクロリファクタリングに移ることができます。

手順4.2：convert()を専用のクラスに移動する：2つ目のマイクロリファクタリングとして、convertを専用のクラスに移動します。

  1. 「convert」を右クリックし、「Refactor」→「Move」の順にクリックしてから、新しいクラスの完全修飾クラス名を入力します。
  2. クラスは、同じパッケージであるcom.siriusxi.javamag.kataに格納します。このクラスをRomanNumeralsConverterとします。これがソリューションの「形」のクラスになります。「Refactor」ボタンをクリックして、変更内容が適切であることを確認します。
  3. テストを再実行し、直前の操作で外部動作が変化しなかったことを確認します。すべて緑の状態のままなので、次のマイクロリファクタリングに移ることができます。

手順4.3：RomanNumeralsConverterをソースのmainフォルダに移動する：RomanNumeralsConverterクラスをテスト用のソース・コード領域からメインのソース・コード領域に移動します。これを行うには、以下の手順に従います。

  1. プロジェクト・ナビゲータでRomanNumeralsConverterクラスをドラッグし、testのjavaフォルダからmainのjavaフォルダに移動します。パッケージ名を尋ねるプロンプトが表示されるので、同じパッケージ名com.siriusxi.javamag.kataを指定します。
    注：IntelliJではデフォルトでクラスがソースのtestディレクトリに格納されますが、ここではソースのmainディレクトリに格納したいので、そのように選択します。「OK」をクリックし、クラスを正しいディレクトリに格納します。
  2. 「Refactor」をクリックします。テストを再実行し、直前の操作で外部動作が変化しなかったことを確認します。すべて緑の状態のままなので、次のマイクロリファクタリングに移ることができます。

これで3つのマイクロリファクタリングが終わりました。これらを合わせれば、大きなリファクタリングになります。

 

手順５：1桁のローマ数字のテスト・ケースを新しく追加する

「形」の解決を続けましょう。次に扱う文字は、ローマ数字のVとXになります。

  1. まず、Vが5を返すことを確認するテストを書きます。すべてのテストを実行すると、予想どおり、テストは赤の状態になります。
  2. これを解決するために、最小限のコードを書いて、このテスト・ケースを緑の状態にします。たとえば、ローマ数字がIであれば1を返し、そうでなければ5を返すように記述します。テストを再実行すると、すべてのテストが緑の状態になります。問題ありません。ここで改善できることはありそうにないため、次のテスト・ケースに移ります。
  3. 赤の状態になるテストをさらに追加しましょう。上記の1と2の手順を繰り返しますが、新しいテスト・ケースはローマ数字のXです。「X」が10に等しいことをアサートします。テストを実行します。まだソリューションのコードを実装していないので、このテストは赤の状態になります。そこで、テストが緑の状態になる一番単純なコードを書きます。
  4. else if分岐を追加し、ローマ数字がVであれば5を返し、その他であれば10を返すようにします。テストを再実行すると、すべて緑の状態になります。これから、赤－緑－リファクタリングの3ステップのうち、リファクタリングのステップに入ります。

最初のリファクタリングとして、コードの繰り返しに対処します。この作業は、DRY（Don’t Repeat Yourself）とも言われます。重複のあるコードは、時がたつにつれてメンテナンスが難しくなります。繰り返されているコード行のいずれかを少し変更する必要がある場合、その変更を何度も行わなければならないからです。この作業には時間がかかり、技術的な俊敏性が低下します。さらに、変更に漏れがあると、見つけにくい欠陥が紛れ込む可能性もあります。

  1. コードの一部をインライン化するリファクタリングを行います。23行目の「arabic」を右クリックし、「Refactor」→「Inline」をクリックするか、[Option]+[Command]+[N]キーを押します。その結果、23行目の変数arabicが、22行目でarabicに代入されている値で置き換えられ、22行目が削除されます。
  2. 「Refactor」をクリックし、リファクタリングを適用します。テストを再実行し、直前の操作で外部動作が変化しなかったことを確認します。すべて緑の状態のままであり、問題ありません。
  3. 20行目と17行目で同じ手順を繰り返します。それぞれの手順においてテストを再実行し、外部動作が変化しなかったことを確認します。

1点補足ですが、17行目と18行目を削除して、コードを少し整えておくべきでしょう。この行削除によって実際のコードが変更されることはありませんが、それでもテストを再実行する必要があります。変更のたびにテストを実行する習慣をつけてください。すべて緑の状態のままなので、次の段階に進みます。

 

手順６：コードの「形」の解決を続ける

ここまでで、1桁のローマ数字のあらゆるケースを網羅する、テストとソリューション・コードをすべて追加しました。自分でこの部分の「形」を完成させることも、筆者が用意したソリューション・コードを見ることもできます。

それではいよいよ、次のテスト・ケースに入っていきましょう。ローマ数字では、多くの場合、新しい桁の追加が加算のように見えます。

  • IIは1+1と同じです。コードでは値2を返します。
  • IIIは1+1+1と同じです。コードでは値3を返します。
  • VIは5+1と同じです。コードでは値6を返します。

お気づきと思いますが、この例は単純化したものです。というのも、IVは6ではなく4を表すからです。左側に小さい数がある場合、加算ではなく減算を表します。ただし、ここでの目的は、ローマ数字の算術を習得することではなく、TDDとリファクタリングの実例を示すことです。

そのため、最初は単純な加算のテスト・ケースを記述します。

  1. 23行目で[Enter]キーを2回押し、@Test public void romanNumeralAddition(){}と入力します。最初のアサーションは、assertEquals(2, RomanNumeralsConverter.convert(“II”))となります。
  2. テストを実行すると、失敗します。それでまったく問題ありません。現在は、赤－緑－リファクタリングのループにおける赤のステップです。
  3. 最小限のコードを書いて、テストを緑の状態にします。4行目で[Enter]キーを押し、if(romanNumeral.equals(“II”)) return 2と入力します。コードがコンパイルできるように、次の行のifの前にelseを追加します。
  4. テストを実行し、すべてが緑の状態であることを確認します。

言うまでもありませんが、これは問題を解決するための最終的なソリューションではありません。このソリューションは大変素朴で、文字列IIを受け取ったときに2を返しているだけです。実際の加算すらしていません。しかし、「形」ではそれで構いません。今回の「形」で重要な点は、ローマ数字の問題を解決することでは必ずしもありません。

重要なのは、動きを練習することです。ここで練習している動きは、テスト駆動開発の赤－緑－リファクタリングという3ステップです。赤から緑に移るときは、最小限のコードを書くことになります。テストを実行して、緑の状態であることを確認しましょう。問題ありません。テストはすべて緑の状態です。

それでは、IIIとVIのアサーションも追加しましょう。今度のアサーションも同じ手順に従います。

  • 3とRomanNumeralsConverter.convert(“III”)が等しいことをアサートします。後者は1+1+1を表します。テストを実行し、このテストが失敗することに注目します。それで問題ありません。最小限のコードを書いて、このテストを緑の状態にします。
  • このテストを緑の状態にするための最小限のコードは、else if (romanNumeral.equals(“III”)) return 3;のようになります。これもベストなソリューションではありませんが、目的は動きを練習することです。テストを実行すると、緑の状態になります。
  • 最後に、6についても同じことをしましょう。ローマ数字ではVIになります。

実際のTDDで、すべてのローマ数字をアラビア数字に変換する問題に対する完全なソリューションを確認したい方は、先ほども触れた記事「テスト駆動開発：実はそれは設計技術です」をご覧ください。

手順6.1：次のリファクタリングをしやすくするためにコードを整える：convertメソッドは長すぎて、1画面に収まっていません。メソッド名は画面最上部よりも上で、スクロールしなければ確認できません。メソッドの一番下も見えません。エディタの最下部より下にはみ出てしまっています。

いくつかのマイクロリファクタリングを行うと、この状況が改善されます。最初のマイクロリファクタリングとして、1桁のローマ数字を扱うコード・セグメントを抜き出して、メソッドの上部に移動します。

  1. 1桁のローマ数字かどうかを判定するため、if(romanNumeral.length() == 1)と入力します。この条件に一致する場合、1桁のローマ数字の変換操作を行います。一方、複数桁のローマ数字の場合は、複数桁の加算操作を行います。
  2. このマイクロリファクタリングを行うために、1桁のローマ数字に対応するコードを手動で切り取って貼り付けます。15行目から29行目までを選択し、そのコードを切り取って7行目に貼り付けます。コードのコンパイルと実行が可能となるように、29行目に移動して、elseを削除します。
  3. コードの最後に、どの ifにも繋がらない場合の return文も必要です。最後のifを削除し、else return 6に修正します。テストを実行すると、まだ緑の状態です。したがって、このマイクロリファクタリングは成功しました。

メソッドが長すぎる点は変わりませんが、これで次のマイクロリファクタリングがしやすくなりました。

手順6.2：メソッドを抽出するリファクタリングを行う：次のマイクロリファクタリングとして、7行目から21行目までを抽出して別のメソッドにします。7行目から21行目までを選択し、右クリックして「Refactor」→「Extract Method」を選択するか、[Option]+[Command]+[M]キーを押します。新しいメソッドの名前は、convertSingleDigitなどとします。その他はデフォルトのままにして、「Refactor」をクリックします。すると、18行目に新しいメソッドが作成されます。

これで、メソッド全体が1画面に収まるようになりました。この方がわかりやすく、技術的な俊敏性も高まります。

ここで忘れずにテストを実行しましょう。それが3ステップにおけるこの次の動きです。すべて緑の状態なので、外部動作は何も変化していないことが確認されます。このリファクタリングは成功です。

ここでは、新たなリファクタリングを学びました。このリファクタリングはメソッドの抽出と呼ばれており、大きなメソッドの一部から新しいメソッドを作成するものです。皆さん自身でも試してみましょう。

ぜひ、この「形」の取り組みを続けてください。「形」を解決できたかどうかを気にすることはありません。重要なのは、赤－緑－リファクタリングのステップを練習することです。

 

まとめ

コードのリファクタリングは、質の高いコードを書くことにつながります。質の高いコードは、変化にすばやく対応したり、新機能を追加したり、パフォーマンスの優れた製品を提供したりするために必要な土台です。

本記事では、実践的な「形」に基づき、ローマ数字をアラビア数字に変換する問題を題材として、アジャイル開発に適した基本的なリファクタリング・テクニックを紹介しました。

今回は、新しいコードでテスト駆動開発環境をセットアップする方法を学びました。そして、マイクロリファクタリングを通して、変数名の変更、コードの移動、メソッドの抽出、メソッドのインライン化といった基本的なリファクタリング・テクニックを体験しました。重要なのは、赤－緑－リファクタリングの動きを練習することです。

次回の記事では、明らかな技術的負債（不注意なプログラミングによって紛れ込んだ効率の悪さやエラー）を含むレガシー・コードを安定させる方法について取り上げたいと思います。

そして3回目の記事では、リファクタリングを使用して、レガシー・コードをシンプルにし、重複を削除し、再利用可能なオブジェクトを増やす予定です。さらに、シンプルになったコードベースにすばやく新機能を追加する方法を実際に紹介するので、リファクタリングによってアジャイル・ワークフローがどのように補完されるかをわかっていただけると思います。
 

さらに詳しく

 

Mohamed Taman

Mohamed Taman（@_tamanm）：SiriusXI InnovationsのCEOであり、Effortel Telecommunicationsの最高ソリューション・アーキテクト。セルビアのベオグラードを拠点とするJava Champion、Oracle Groundbreaker、JCPメンバーであり、Jakarta EEのAdopt-a-SpecプログラムとOpenJDKのAdopt-a-JSRのメンバーを務める。