「refactoring」（リファクタリング）とは ソフトウェアの表面的な動きは変えずに、プログラムの内部構造を整備してソースコードを直すことです。
開発案件が積み重なっていくと、どうしてもソースコードが複雑なものになっていきますし、開発中も仕様変更が入る場合など、整ったソースコードを書き上げることは難しい状況となりがちです。
そこで、このrefactoringが有効と考えられており、これを行うことで、以下のメリットがあると言われています。
- メンテナンス性が向上し、今後の開発のスピードや質が上がる
- 他の技術者が見ても理解しやすくなり、引継ぎも容易になる
- 結果として、バグが起こりにくくなる。起きた場合も迅速に修正ができる
また、あらためてソースコードの構造を理解し直す機会にもなります。
refactoring（リファクタリング）で気を付けるべき点とは？
上記のような効果が見込めるリファクタリングですが、実施にあたっては留意すべき点があります。
ユーザー側の理解や協力を得られるようにする
refactoringは、ユーザーにとって直ちにメリットを感じられるものではないので、時間と工数をかけるのを理解してもらいにくい場合もあります。
ユーザーからは、「とにかく急ぎの案件を先に開発して！」とリクエストされることも多いでしょう。
特に開発ベンダーとしての立場であれば、無理に進める訳にもいきません。
普段からユーザーとはよい関係を保ち、上記の利点があることを理解してもらうように努めましょう。ユーザー側が全く知らないところで進めるのではなく、実施にあたっては必ず情報をシェアしておくことが必要です。
また、あなたがユーザー側である場合は、後々のことを考え、IT開発者が必要なrefactoringを行えるように積極的に支援しましょう。
refactoring実施がバグを生み出してしまうリスクも
refactoringもプログラミングであり、ソースコードを修正する以上、それが新たなバグを生み出す可能性もあります。
そこでテストが必要になりますので、まずは細かく範囲を分けてrefactoringを進め、テストも都度行うことで、バグがあればすぐ気づけるようにします。
さらに、全体の修正が完了した後、機能や振る舞いが正常に（今まで通り）動くか、他に想定外の影響がでていないかテスト（regression test）が必要です。
IT側では、テストを行う（自動テストツールを使えると効率的です）のは当然ですが、ビジネス側にも念のためテストに協力してもらうことが望まれます。
システム開発や運用では、さまざまな局面でテストが実施されます。システムエンジニアなどIT関係者であれば何らかの形でテストに関与することになるでしょう。そこで今回はいくつかのテストについて取り上げてみます。 Pe[…]
このように、refactoringは、IT、ビジネス（ユーザー）双方での協働が必要ですので、まずは難易度の低い、限定されたソースコード部分に絞って、試してみるのがよいでしょう。
