ソフトウェアの標準と部品化 5 /リファクタリング

前回は、アジャイル開発の話題で少し部品化や標準化といったこのテーマから外れているかのようになっていますが、アジャイル開発で重視されることの多いリファクタリングの考え方は、部品とまで言わないまでも、部本的なモジュール(やコンポーネント)のインターフェース仕様を変更しないで改良することから、共通性を有しています。

　　▼リファクタリング【refactoring】
　　　　IT用語辞典 e-Words
http://e-words.jp/w/
E383AAE38395E382A1E382AFE382BFE383AAE383B3E382B0.html

ウォーターフォール型の開発方式では、先に製造された部品的なコードは、よほどの不都合がなければ、改版することは避けることにされていることが多いかと思います。

一方、アジャイル的な開発方式では、テストコードによる品質確保に拠って、リファクタリングなどのコード改変を肯定的に考えられていることが多いようです。

もっとも、実際に導入されている開発現場でリファクタリングが行われるかというと、予算的には難しいことが多いのではないかと推測しますが……

XPプログラミングがリファクタリングで説く「動作を変更せずに、効率やコード記述を改善する」という作業は、対象のソフトウェアが要求される性能を確保しているならば、改悪リスクを伴うだけの金のかかる行為と考えられることも珍しくはないでしょう。

リファクタリングの作業が後の保守や、再利用性などにおいても、また、技術者のスキルアップなどでも大変有効であるという点においては、あまり、反論する方はいないでしょうが、その作業を行うための予算や時間を作ることを無条件に賛成することもまた無いでしょう。

いかに、テストコードによって動作検証の完全性を確保することも考慮はされているとはいえ、肝心のテストコードの設計の質が低い場合もあり得ますし、リファクタリングの対コストの正当性とリスクを評価した場合には難しい判断になります。

ファームウェアの場合には、リアルタイム性能や処理時間が問題になる場合もあります。

　　▼ファームウェア　【firmware】
　　　　IT用語辞典 e-Words
http://e-words.jp/w/E38395E382A1E383BCE383A0E382A6E382A7E382A2.html

テストコードを動作させた状態と実際の状態では環境や動作時間が異なるため、論理的な検証はできますが、処理時間の問題を内包している場合には必ずしも有用ではない場合もあります。

性能がシビアに求められる場合にはI/Oリカバリタイムや待ち同期、プリフェッチ、キャッシュなど、ハードウェアの仕様に対して無駄がないよう考慮されたコードになっている場合があります。

このようなコードではテストコードを安易に用いて検証するということができませんし、リファクタリングによって、処理時間が変わり動作不良を生むリスクがあります。

できるだけ、このような部分は局所化し部品化(ブラックボックス化)したり、そのような方法をとらなくて良いような努力によって、問題にならないようにすることが普通ですが、最初は、可能な限りゆるやかな条件になるように実装しておいて、後に局所的にシビアに改変することで、動作を満たしてから性能を向上するという手法もとられます（パフォーマンス・チューニングなどと呼ばれる作業です）。

もっとも、後に性能向上できる見込みを立てることが難しいので、ハードウェア性能に余裕がある場合や、可能な限り高速である方が好ましいというようなタイプでなければ、後に回すということは難しく、製品の要求上やむなく改造していることの方が普通だろうと思います。

リファクタリングの場合には、プロジェクト終了後に改良することも指しますし、少し違いますが、チューンアップを将来の類似製品が計画された時への対応に向けてや、同製品のソフトウェアが途中生産ロットから切替られる場合に備えて開発プロジェクト終了後に改良したものを備えておく場合もあります。