ソフトウェアの腐敗

ソフトウェア腐敗(ビット腐敗、コード腐敗、ソフトウェア侵食、ソフトウェア崩壊、またはソフトウェアエントロピー) とは、時間の経過に伴うソフトウェアの使用またはパフォーマンスの劣化、低下、または喪失のことです。

ソフトウェアのユーザーエクスペリエンスの観点から見ると、ハードウェアを含めた動作環境の進化です。ソフトウェアの実用化に対する客観的損失の第一の原因は、実用的な動作環境としてのホストシステムの喪失です。

ハッカーの伝承をまとめたJargon File では、「ビット腐敗」を「何も変更されていない」にもかかわらず、時間の経過とともにソフトウェアプログラムが劣化することに対する冗談めいた説明として定義しています。この背後にある考え方は、プログラムを構成するビットが放射性崩壊の影響を受けるかのようなものです。^[1]

ソフトウェアが劣化する原因としては、ソフトウェアが動作する環境の変化、ソフトウェア自体の部品間の互換性の低下、未使用またはほとんど使用されないコードでのバグの発生など、いくつかの要因が挙げられます。

プログラムの環境に変化が生じた場合、特にプログラムの設計者が予期していなかった変化があった場合、ソフトウェアは当初意図したとおりに動作しなくなる可能性があります。たとえば、初期のコンピュータゲームの設計者の多くは、 CPU クロック速度をゲームのタイマーとして使用していました。 ^[2]しかし、新しいCPUクロックはより高速になったため、ゲームプレイ速度もそれに応じて増加し、時間の経過とともにゲームは使いにくくなりました。

環境の変化は、プログラムの設計者ではなく、そのユーザーに関係します。当初、ユーザーはシステムを正常に動作させ、一定期間、完璧に動作させることができました。しかし、システムが正常に動作しなくなったり、ユーザーが構成コントロールにアクセスしたい場合、異なるコンテキストと利用できない情報 (パスワードの紛失、指示の欠落、または試行錯誤で最初に構成された管理が難しいユーザー インターフェイスなど) のため、最初の手順を繰り返すことはできません。情報アーキテクトの Jonas Söderström は、この概念をOnceabilityと名付け、^[3]「一度障害が発生すると、ユーザーがシステムを復元できないようにする技術システムの品質」と定義しています。

ドキュメント フィルターや他のプログラムで使用するために設計されたインターフェイスなど、あまり使用されないコード部分には、気付かれないバグが含まれている可能性があります。ユーザー要件やその他の外部要因の変更により、このコードが後で実行されると、バグが露呈し、ソフトウェアの機能が低下しているように見えることがあります。

ソフトウェアやシステムの通常のメンテナンスも、ソフトウェアの劣化を引き起こす可能性があります。特に、プログラムに互いに離れた場所で機能する複数の部分が含まれている場合、1 つの部分への変更が他の部分にどのように影響するかを考慮しないと、バグが発生する可能性があります。

場合によっては、ソフトウェアが使用するライブラリがソフトウェアに悪影響を与えるような方法で変更されるという形を取ることがあります。ソフトウェアで以前は動作していたライブラリの古いバージョンが、他のソフトウェアとの競合や古いバージョンで見つかったセキュリティ上の欠陥のために使用できなくなった場合、プログラムが使用するために必要なライブラリの実行可能なバージョンがなくなる可能性があります。

現代の商用ソフトウェアは、ライセンスの検証や情報へのアクセスのためにオンラインサーバーに接続することがよくあります。ソフトウェアを動かすオンラインサービスが停止すると、ソフトウェアが動作しなくなる可能性があります。^{[4] [5]}

2010年代後半以降、ほとんどのウェブサイトは安全なHTTPS接続を使用しています。しかし、これには有効期限のあるルート証明書と呼ばれる暗号化キーが必要です。証明書の有効期限が切れると、キーが継続的に更新されない限り、デバイスはほとんどのウェブサイトに接続できなくなります。^[6]

もう1つの問題は、2021年3月に古い暗号化規格TLS 1.0とTLS 1.1が廃止されたことです。^[7]つまり、少なくともTLS 1.2をサポートしていないオペレーティングシステム、ブラウザ、その他のオンラインソフトウェアは、パッチをダウンロードしたりブラウザを更新したりするためにも、ほとんどのWebサイトに接続できません（パッチが利用可能な場合）。これは「TLSアポカリプス」と呼ばれることもあります。

ほとんどのウェブサイトに接続できない製品には、PowerMac、古いUnixボックス、Server 2008/Windows 7より古いバージョンのMicrosoft Windows（少なくともサードパーティのブラウザを使用していない場合）などがあります。Server 2008/Windows 7のInternet Explorer 8ブラウザはTLS 1.2をサポートしていますが、デフォルトでは無効になっています。^[8]

ソフトウェアの腐敗は通常、「休眠中の腐敗」または「活発な腐敗」のいずれかに分類されます。

現在使用されていないソフトウェアは、アプリケーションの残りの部分が変更されるにつれて、徐々に使用できなくなります。ユーザー要件やソフトウェア環境の変化も劣化の一因となります。

継続的に変更されているソフトウェアは、適切な緩和プロセスが一貫して適用されない場合、時間の経過とともに整合性が失われる可能性があります。ただし、多くのソフトウェアでは、新しい要件を満たし、バグを修正するために継続的な変更が必要であり、変更が行われるたびにソフトウェアを再設計することはほとんど現実的ではありません。これにより、本質的にプログラムの進化プロセスが作成され、元のエンジニアリング設計から逸脱することになります。この結果と変化する環境により、元の設計者が行った仮定が無効になり、バグが発生する可能性があります。

実際には、新機能の追加はドキュメントの更新よりも優先されることがあります。ただし、ドキュメントがなければ、プログラムの一部に関する特定の知識が失われる可能性があります。コーディング規約の現在のベストプラクティスに従うことで、この問題をある程度軽減できます。

アプリケーションの商用寿命が終わりに近づき、それ以上の開発が停止すると、アクティブなソフトウェアの劣化は遅くなります。多くの場合、ユーザーは残っているソフトウェアのバグを回避する方法を学び、何も変更されないため、ソフトウェアの動作は一貫したものになります。

AI研究の初期のころから多くの重要なプログラムが、修復不可能なソフトウェアの劣化に悩まされています。たとえば、オリジナルのSHRDLUプログラム (初期の自然言語理解プログラム) は、LISP と PLANNER がまだ開発段階にあった時代に開発されたため、現在は存在しない非標準のマクロとソフトウェア ライブラリを使用しているため、現代のコンピューターやコンピューター シミュレーターでは実行できません。

管理者がオープンソースのフォーラム ソフトウェアを使用してフォーラムを作成し、新しい機能やオプションを追加して大幅に変更するとします。このプロセスでは、既存のコードに大幅な変更を加え、そのソフトウェアの元の機能から逸脱する必要があります。

ここから、ソフトウェアの腐敗がシステムに影響を及ぼす方法はいくつかあります。

• 管理者が誤って変更を加え、それが互いに、または元のソフトウェアと競合し、フォーラムが予期しない動作をしたり、完全に機能しなくなったりすることがあります。管理者は非常に悪い立場に立たされます。元のコードから大きく逸脱しているため、フォーラムを復活させるための技術サポートや支援を得るのが難しくなります。
• フォーラムの元のソース コードにセキュリティ ホールが見つかり、セキュリティ パッチが必要になる場合があります。ただし、管理者がコードを大幅に変更しているため、パッチをコードに直接適用できない場合があり、管理者が実質的に更新を書き直す必要があります。
• 変更を行った管理者が退任すると、新しい管理者は、ドキュメントが十分に整備されていない複雑で大幅に変更されたフォーラムをそのまま残すことになります。変更内容を完全に理解していないと、新しい管理者が競合やバグを生じさせずに変更を加えることは困難です。さらに、元のシステムのドキュメントが利用できなくなったり、機能要件の微妙な違いにより誤解を招く恐れがあります。

ウェブマスターが、Wikipedia などのウィキを動かすソフトウェアであるMediaWikiの最新バージョンをインストールし、その後更新を一切適用しないとします。時間が経つにつれて、ウェブホストはウェブマスターに相談することなく、プログラミング言語( PHPなど) やデータベース( MariaDBなど) のバージョンを更新する可能性があります。十分な時間が経つと、更新されていない複雑なウェブサイトは最終的に機能しなくなります。最新バージョンの PHP と MariaDB には、特定の組み込み関数を廃止するという重大な変更が含まれており、下位互換性が失われ、致命的なエラーが発生するためです。更新されていないウェブサイト ソフトウェアによって発生する可能性のあるその他の問題には、セキュリティの脆弱性やスパムなどがあります。

リファクタリングは、ソフトウェアの腐敗の問題に対処する手段です。これは、外部の動作に影響を与えずに既存のコードを書き直して構造を改善するプロセスとして説明されています。^[9]これには、デッドコードの削除や、大幅に変更されて効率的に動作しなくなったセクションの書き直しが含まれます。ソフトウェアの外部動作を変更しないように注意する必要があります。変更すると互換性がなくなり、ソフトウェアの腐敗につながる可能性があります。リファクタリングに関して考慮すべき設計原則には、コードの階層構造を維持し、抽象化を実装してコード構造を簡素化および一般化することなどがあります。^[10]

• コードの臭い
• 依存地獄
• 世代損失
• ソフトウェアの肥大化
• ソフトウェアの脆弱性
• SOLID  – オブジェクト指向プログラミング設計原則