議論: アーキテクチャの書き直しは避けるべきか?

作者 Sadek Drobi, 翻訳者 編集部 投稿日 2008年5月24日 午後6時5分

コミュニティ

Architecture

トピック

設計,

顧客要求,

エンタープライズアーキテクチャ

タグ

Antipatterns

ソフトウェアを新しい需要や要件に適合させることが困難になるほど、アーキテクチャを更新するためにソフトウェアを再構築するという誘惑は強くなる。その取り組みはむしろリスクが高く、適切な戦略を採用することが不可欠である。Andy Singelton氏の最近のブログ記事(source)では、あれこれ戦略を選びながら、考慮すべきコスト、技術的な複雑さ、および潜在的な商業リスクに関してさまざまな妥協点の検討を行っている。彼は、3つの可能なアプローチを特定し、それぞれの利点と不利点を簡単に紹介している。

- 完全に新しいソフトウェアを記述することを示す「プロトタイプと拡張」という選択肢
- コンポーネントの更新と、コードベースを使用し続けたままリファクタリングすることに基づいた「増分」という選択肢
- 新しい要件を満たす既存のソフトウェアを入手することに基づく「購入」という選択肢。

しかし、ブログスペースの数人の著者は、1つ目の選択肢（ゼロからソフトウェアを書き直すこと）は絶対に避けるべきであると主張している。Joel Spolsky氏は、かつて2000年にNetscape 6のリリース発表を受けて、そのようなアプローチに対する意見を主張した(source)。彼は、コードを書き直すというNetscapeの決定を「1つの最大の戦略ミス」と見なし、同様の「ミス」の例証として、BorlandのdBaseとQuattro Pro、およびMicrosoftのPyramidプロジェクトを挙げた。Joel氏は、ソフトウェアの書き直しの必要性として認知されていることが多くの場合は非常に主観的であり、たいていコードの再利用に内在する困難さに関連していると考えている。さらに彼は、実際にコードを読みにくくしているものの多くは現実のテストとバグ修正の長いプロセスに関連していると主張している。

新しいコードが古いコードよりも優れているというのは、明らかに不合理です。古いコードは使われています。古いコードはテストされています。多くのバグが発見され、修正されています。 […]

その2ページの関数に戻ってください。ウィンドウを表示するための単純な関数ですが、その要素は増えており、誰もその理由を知りません。理由をお話しましょう。それらはバグ修正です。 […]

これらの各バグは、現実に使用されてから発見されるまで数週間かかりました。 […]

コードを無駄にしてゼロから始める場合、あなたはその知識すべてを無駄にしています。収集したバグ修正すべてを、そして何年ものプログラミング労力を無駄にしてしまうのです。

また、Joel Spolsky氏は、書き直しプロジェクトが新興成長市場のニーズに対応するチームの能力を弱めるとして、そのプロジェクトを始めることの潜在的なビジネスリスクを強調している。したがって、彼によると、たとえ古いコードベースがアーキテクチャの点で非常にひどい場合でも、完全な書き直しを始めるのではなく、コードをクリーンアップし、インターフェースをリファクタリングして変更する努力をするべきであるということだ。

ソフトウェアの書き直しに関する一般的な議論の1つは、最初のリリース以降に積んだ経験により、チームはより良い仕事ができるだろうという仮定である。しかし、Joel Spolsky氏は、開発チームはほぼ確実に時間とともに変化するという事実を強調している。さらに、Dharmesh Shah氏がつい最近Spolsky氏の記事に同調して(source)そのことが強調されたため、市場の状況が変化する可能性は大いにある。

Dharmesh Shah氏は、ソフトウェアの書き直しを正当化しようとするその他の一般的な理由（たとえば、コードベースが不適当だとか、プラットフォームや言語の初期の選択が間違っていたなど）を挙げて、それらの制限事項を示している。彼は、書き直しを始める誘惑に耐えるべきである理由について次のように詳述している。「そのプロセスは必ず予想より長くなるでしょう。潜在的な市場変化や既存客の需要に応じることができないという大きなリスクがあり、ソフトウェアの競争上の優位性を弱める可能性があります。そして、代替のソリューション、たとえば、コードをクリーンアップして前のリスクを低減する手段となるリファクタリングなどがあります」、と説明している。Dharmesh Shah氏は、書き直しが正当化される状況はごくわずかであると信じている。その状況とは、初期のテクノロジー選択が商業上の成功を妨げる場合や、テクノロジーの状況に大きな変化（たとえば、クライアント/サーバからWebベースのコンピューティングへの移行）があり、ソフトウェアがそれに適合できない場合である。

Quattro ProをModula-2コンパイラからTurbo Pascalへ移植した経験に基づき、Dharmesh Shah氏の投稿記事にコメントした(source)Bob Warfield氏は、しかし、言語を変更するためにソフトウェアを書き直す価値はないと考えている。また、その問題に関する他の見識も追加している。それは、特に再構築の決定が既存のコードの質が悪いために下された場合の人的資源の重要性などだ。彼は、リファクタリングがコード以上のことを可能にすることと、チームが積んだ経験を活用して、たとえばユーザーモデルなどをリファクタリングできることを示唆して、リファクタリングの価値をさらに強調している。

原文はこちらです：http://www.infoq.com/news/2008/05/software-rewrite-4-architecture

• 次へ >