レガシー ソフトウェアのリファクタリング: 課題からチャンスへ

この記事では、物流管理システム (OMS) の國際化と新しい電子商取引プラットフォームとの統(tǒng)合の課題に當(dāng)社がどのように対処するかについて説明します。このシステムは、急成長を遂げている電子商取引企業(yè)の注文準(zhǔn)備プロセスを最適化し、さまざまな物流事業(yè)者と効率的に統(tǒng)合するために 2018 年に開発されました。 PHP (Symfony)、MySQL、Socket.io、および jQuery を使用して構(gòu)築されており、注文追跡、宅配便接続、ラベル生成、注文準(zhǔn)備パフォーマンス メトリクスなどの機(jī)能を含む、梱包から出荷までのプロセス全體をカバーしています。

技術(shù)的負(fù)債の蓄積

このシステムは長年にわたってうまく機(jī)能していましたが、ビジネスが成長するにつれて、その限界がますます明らかになりました。技術(shù)的負(fù)債は特に憂慮すべきものであり、プロジェクトの複數(shù)のレベルに影響を及ぼします。技術(shù)インフラストラクチャの観點(diǎn)から見ると、アプリケーションは古いフレームワークと基本言語バージョンで実行されます:

• Symfony バージョン (4.0) は長期サポート (LTS) バージョンではないため、2019 年 1 月からセキュリティ更新プログラムの受信を停止します。
• PHP 7.1 もライフサイクルを終了しており、システムには重要なセキュリティ アップデートがありません。

バージョンが古いことに加えて、このプロジェクトにはソフトウェア開発の基礎(chǔ)にも重大な欠陥があります:

• テストの欠如または不十分: 自動テスト (単體テスト、統(tǒng)合テスト、エンドツーエンドのテスト) が不足していると、バグの早期検出が妨げられるだけでなく、変更が行われると安定性が損なわれる可能性があります。システムの。
• コーディング標(biāo)準(zhǔn)の欠如: コードベースは文書化されたパターンや標(biāo)準(zhǔn)に従っておらず、たとえ存在していたとしても、業(yè)界のベスト プラクティスと一致していません。これにより、メンテナンスとプロジェクトへの新しい開発者のオンボーディングの両方が困難になります。
• 不十分なドキュメント: 既存のドキュメントは希薄で、多くの場合不完全です。これは技術(shù)開発だけでなく、コードに実裝されたビジネス プロセスの理解にも影響します。
• 不完全なバージョン管理: Git 履歴には説明が不足しており、コミットの粒度は粗く、メッセージは規(guī)則に従っておらず、加えられた変更に関する背景情報が不足しています。このため、時間の経過とともに行われるコードの進(jìn)化と決定を理解することが困難になります。

技術(shù)的負(fù)債の蓄積は、システムの安定性とセキュリティに脅威をもたらすだけでなく、次のような脅威にもなります。

• 新機(jī)能の開発速度を低下させました
• バグが侵入するリスクの増加
• 新しいメンバーがチームに參加するのが難しくなりました
• メンテナンスコストの増加
• 問題の診斷と解決が複雑になります

構(gòu)造上の制限

元のアーキテクチャには、柔軟性とスケーラビリティに深刻な影響を與える結(jié)合問題がありました。

• メインの電子商取引プラットフォームに完全に依存: アプリケーションは獨(dú)立して実行できず、すべての物流業(yè)務(wù)は電子商取引プラットフォームのデータとプロセスに直接依存します。これは、メイン プラットフォームに変更を加えると、システムの機(jī)能が損なわれる可能性があることを意味します。
• パフォーマンスの問題を引き起こす共有データベース: 物流アプリケーションと電子商取引プラットフォームは同じデータベースを使用するため、特にどちらかのアプリケーションの負(fù)荷のピーク時にパフォーマンスの問題が発生します。さらに、データベースへのアクセスにより他のシステムからの重要なデータが侵害される可能性があるため、この構(gòu)成では権限管理が複雑になります。
• スタンドアロンでは実行できません: このアプリは、e コマース プラットフォームでのみ実行されるように設(shè)計(jì)されています。これにより、移植性が制限されるだけでなく、隔離された環(huán)境でのテストや他のプラットフォームへの移行も妨げられます。その依存関係は適切にカプセル化されておらず、分離しようとするとシステム全體に大規(guī)模でコストのかかる変更が必要となり、メイン クラスでは単一責(zé)任原則 (SRP) が遵守されていません。
• 新機(jī)能の実裝の難しさ: オープン/クローズ原則 (OCP) とリスコフ置換原則 (LSP) への準(zhǔn)拠の欠如は、システムの進(jìn)化を大きく妨げます。新しい機(jī)能を使用するには既存のコードを変更する必要があり、リグレッションが発生するリスクが高まります。さらに、モジュール間の直接の依存関係により、依存関係反転原則 (DIP) に従うことがほぼ不可能になります。

これらの構(gòu)造上の制限により、システムの保守性と拡張性が低下するだけでなく、変更や進(jìn)化に伴うリスクも増大し、アプリケーションが技術(shù)的に脆弱で戦略的に脆弱な狀態(tài)になります。

開発管理と戦略的連攜

最も重要な課題の 1 つは、技術(shù)的なものだけでなく、戦略的なものでもあります。外部開発は機(jī)能的には正しいですが、組織上の重大な制限があります。

• グローバル戦略から切り離されている: 開発は、企業(yè)の內(nèi)部目標(biāo)とプロセスを完全に理解することなくサイロで行われます。その結(jié)果、技術(shù)的には正しくても、ビジネスの実際のニーズを必ずしも満たさない機(jī)能が生成されます。
• 戦略的な優(yōu)先順位付けの欠如: 新機(jī)能の実裝には、明確な評価と優(yōu)先順位付けのプロセスが欠如しています。機(jī)能が本當(dāng)に必要かどうか、それを?qū)g裝する最善の方法かどうか、より効率的な代替手段が存在するかどうかについては、疑問の余地はありません。
• 事後開発とプロアクティブ開発: 開発は主に事後モデルに従い、長期的な影響や社內(nèi)の他のプロセスとの潛在的な相乗効果を考慮せずに當(dāng)面のニーズに対応します。
• 検証プロセスの欠如: 構(gòu)造化されたレビューと検証プロセスが欠如しているため、機(jī)能は機(jī)能していても、エンド ユーザーや會社の全體的な目標(biāo)にとって必ずしも最適なソリューションを提供するとは限りません。

この狀況は次の理由から長期的には持続不可能です。

• 実際のニーズからますます逸脫する製品が生成される
• 他の會社のシステムやプロセスとの統(tǒng)合を妨げる
• 製品に関する戦略的意思決定が複雑になる
• チームの革新と継続的な改善の能力が制限される

基本コストの影響

このプロジェクトで見落とされがちですが、特に重要な側(cè)面は基本コストです。これはソフトウェア開発における重要な概念であり、新機(jī)能の追加や必要な最小限の改善を行わなくてもシステムを稼働し続けるためのコストを指します。

私たちの場合、基本コストには、古いフレームワークと言語バージョンの維持、技術(shù)的負(fù)債の蓄積による緊急事態(tài)の解決、他のシステムとの依存関係の管理、結(jié)合されたアーキテクチャへの適応、理解が不十分なために発生したドメイン知識コストに関連するすべてのコストが含まれます。 。これらすべては利用可能なリソースを大量に消費(fèi)し、イノベーションと継続的な改善への投資能力に直接影響を與えます。

この要因は、開発を社內(nèi)化するという決定の決定的な要因ではありませんでしたが、プロジェクトの初期診斷には非常に影響を與えました。システムの持続可能性を評価する際、基本コストは無視されることがよくありますが、この場合、現(xiàn)在の戦略が長期的には持続不可能であることが明確に示されています。さらに、今後の記事で説明するように、既存の構(gòu)造を維持しようとすると、基本コストは時間の経過とともに指數(shù)関數(shù)的に増加します。

基本的なコストの概念とその重要性の詳細(xì)については、Eduardo Ferro の元の記事を參照することをお勧めします。

転換點(diǎn): 新たな課題と戦略的決定

どのようなリファクタリング プロジェクトでも、採用できる戦略は複數(shù)あり、絞殺図かビッグバン書き換えかのジレンマによく遭遇します。

最初の技術(shù)的な決定は、ストラングラー パターン を使用して同じレガシー プロジェクト內(nèi)で作業(yè)することでした。これは、古いシステムの一部を徐々に置き換える新しいモジュールまたはシステムを開発することを含むアプローチです。この戦略により、変更を並行して行い、リスクを軽減し、現(xiàn)在の機(jī)能を維持しながら、將來の機(jī)能をサポートするためのより強(qiáng)力な基盤を構(gòu)築することができます。

しかし、ビジネスの観點(diǎn)から見ると、このオプションは既存のシステム (すでに稼働しており、その機(jī)能を?qū)g行している) に過度のリスクをもたらします。私たちは既存のプロジェクトには觸れず、代わりに新しいニーズを満たすスタンドアロン アプリケーションを開発することにしました。

この変更により、既存のコードベースをフォークすることになりました。これは技術(shù)的には可能ですが、いくつかの欠點(diǎn)がありました。

• コード ベースの重複: 2 つの別個のコード ベースを維持する必要があります。
• データベースの分離: データ構(gòu)造をコピーし、各システムに適合させる必要があります。
• インフラストラクチャのレプリケーション: 獨(dú)立したサーバーを展開し、各システムの適切な可観測性を確保する必要があります。
• チームの認(rèn)知的負(fù)荷の増加: この重複により、2 つのシステム間の一貫性を維持するために余分な労力が必要となり、その結(jié)果、チームの複雑さとエラーのリスクが増大します。

このアプローチにより、新しい戦略目標(biāo)に沿ったプロジェクトを開発しながら、既存のシステムの安定性を確保しながら、獨(dú)立したソリューションに移行することができます。ただし、自信を持ってこの課題に計(jì)畫を立てて対処するには、長所と短所を詳細(xì)に分析する必要があります。さらに、新しい電子商取引プラットフォームへの移行が完了するまでは機(jī)能を拡張せず、プロジェクトのバックログを厳密に管理するというビジネス レベルの合意に達(dá)しました。

結(jié)論と次のステップ

レガシー ソフトウェアを內(nèi)部化して書き直すという決定は、特にソフトウェアがその機(jī)能を?qū)g行できる場合には、決して簡単ではありません。 「うまくいくなら觸るな」という格言は常に存在します。しかし、時には二歩前進(jìn)するためには一歩後退することもあります。

このシリーズの後続の記事では、これらの課題にどのように対応したか、技術(shù)的および戦略的決定を下したのか、そしてこれらの課題を改善とチーム開発の機(jī)會にどのように変えたかを探っていきます。

以上がソフトウェアの遺産から戦略的機(jī)會へ: 出発點(diǎn) (I)の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。