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

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

技術的負債の蓄積

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

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

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

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

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

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

構造上の制限

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

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

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

開発管理と戦略的連攜

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

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

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

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

基本コストの影響

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

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

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

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

転換點: 新たな課題と戦略的決定

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

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

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

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

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

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

結論と次のステップ

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

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

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