レガシーソフトウェア改善ガイド
リファクタか、リライト(作り直し)か。
この大きなテーマについてこの本で言及されています。
レガシーソフトウェア改善ガイド (Object Oriented Selection)
リファクタか、リライトかの結論
結論からいうと
「リライトしたい欲求と戦い、どうにかリファクタで解決できないか考えるべし。最善を尽くしてどうしても駄目であればリライトを検討しても良い」
ということでした。
リライトのリスク
最初に明らかにしておくが、完全な書き直しは、ほとんど常によくないアイデアだと私は信じている。けれど「あなたも信じなさい」と言うのではない。できれば納得していただきたい。以下に、リライトに対する詳しい反論を書く。
から始まる"リライトへの反論"が以下の通りです。(だいぶ要約してあります)
リスク
大規模な開発プロジェクトで、何ヶ月、あるいは何かかることにより、以下のようなリスクを抱える
- 潜在的な数え切れないバグがあるかもしれない
- 計画より長い時間がかかり、予算を超過するかもしれない
- 新しいアーキテクチャが現プロダクションレベルを満たすかがわからず、途中で不可能であることが判明するかもしれない
オーバーヘッド
新規プロダクトのセットアップには非常に多くの実装がひつようになり、技術者はそのオーバーヘッドを過小に見積もりがち。
リライト時の原稿プロダクトへの対応策が難しい
以下の3つどれも現実的ではない。
- 元のソフトウェアの開発を、リライト期間は凍結する
- 仕様変更を許し、リライト期間常に追いつくようにする
- 仕様変更は許すが、リライトはどの変更も実装しない
「まっさらな新天地」は長く続かない
リライトでは以下のような自体が起こりがち
- 新鮮で素晴らしい設計でスタート
- 実装してみたらモデルの不備に気づき、ヘルパーコードを追加
- 古いコード似合った不必要だと思ったコードが使われていることが判明し、サポート機能を実装する
- DBの中で、存在するはずのないデータに遭遇し、不必要なはずのチェックを実装する
- この時点で、新しいコードと置き換えようとしているコードが驚くほど似ていることに気づく
リライトの条件
これに対して、リライトをして良い条件で以下のものが挙げられています。
リファクタリングを試みたが失敗した
一旦リファクタリングにある程度の時間と労力を注ぎ込んでから検討するべき
パラダイムシフト
テクノロジーの根本的な変化があった時。
最も一般的な変化は、言語の変更。COBOLからJavaへの移植のように。
第3の道
また、リライトをする際にも以下のものを検討するべきだと書かれています。
第3の道として、インクリメンタルな書き直し
全てのリライトはコストもリスクも大きすぎるので、リライトの単位を分割する。
機能を分割してそれぞれをコンポーネントとして分割して書き直すアプローチを試みる。詳細は本の5章「リアーキテクティング」に記載あり。
感想
自分のプロジェクト経験をかんがみた際に、心当たりがあることが非常に多く振り返っていろいろ考えるきっかけになりました。。
「リライトしなくてもリファクタでこれだけやれることがある」というのは心強いメッセージですね。この本にはその詳細も書いてあるので、そちらも参考にしたいと思います。
