この記事では、物流管理システム (OMS) の国際化と新しい電子商取引プラットフォームとの統合の課題に当社がどのように対処するかについて説明します。このシステムは、急成長を遂げている電子商取引企業の注文準備プロセスを最適化し、さまざまな物流事業者と効率的に統合するために 2018 年に開発されました。 PHP (Symfony)、MySQL、Socket.io、および jQuery を使用して構築されており、注文追跡、宅配便接続、ラベル生成、注文準備パフォーマンス メトリクスなどの機能を含む、梱包から出荷までのプロセス全体をカバーしています。
このシステムは長年にわたってうまく機能していましたが、ビジネスが成長するにつれて、その限界がますます明らかになりました。技術的負債は特に憂慮すべきものであり、プロジェクトの複数のレベルに影響を及ぼします。技術インフラストラクチャの観点から見ると、アプリケーションは古いフレームワークと基本言語バージョンで実行されます:
バージョンが古いことに加えて、このプロジェクトにはソフトウェア開発の基礎にも重大な欠陥があります:
技術的負債の蓄積は、システムの安定性とセキュリティに脅威をもたらすだけでなく、次のような脅威にもなります。
元のアーキテクチャには、柔軟性とスケーラビリティに深刻な影響を与える結合問題がありました。
これらの構造上の制限により、システムの保守性と拡張性が低下するだけでなく、変更や進化に伴うリスクも増大し、アプリケーションが技術的に脆弱で戦略的に脆弱な状態になります。
最も重要な課題の 1 つは、技術的なものだけでなく、戦略的なものでもあります。外部開発は機能的には正しいですが、組織上の重大な制限があります。
この状況は次の理由から長期的には持続不可能です。
このプロジェクトで見落とされがちですが、特に重要な側面は基本コストです。これはソフトウェア開発における重要な概念であり、新機能の追加や必要な最小限の改善を行わなくてもシステムを稼働し続けるためのコストを指します。
私たちの場合、基本コストには、古いフレームワークと言語バージョンの維持、技術的負債の蓄積による緊急事態の解決、他のシステムとの依存関係の管理、結合されたアーキテクチャへの適応、理解が不十分なために発生したドメイン知識コストに関連するすべてのコストが含まれます。 。これらすべては利用可能なリソースを大量に消費し、イノベーションと継続的な改善への投資能力に直接影響を与えます。
この要因は、開発を社内化するという決定の決定的な要因ではありませんでしたが、プロジェクトの初期診断には非常に影響を与えました。システムの持続可能性を評価する際、基本コストは無視されることがよくありますが、この場合、現在の戦略が長期的には持続不可能であることが明確に示されています。さらに、今後の記事で説明するように、既存の構造を維持しようとすると、基本コストは時間の経過とともに指数関数的に増加します。
基本的なコストの概念とその重要性の詳細については、Eduardo Ferro の元の記事を参照することをお勧めします。
どのようなリファクタリング プロジェクトでも、採用できる戦略は複数あり、絞殺図かビッグバン書き換えかのジレンマによく遭遇します。
最初の技術的な決定は、ストラングラー パターン を使用して同じレガシー プロジェクト内で作業することでした。これは、古いシステムの一部を徐々に置き換える新しいモジュールまたはシステムを開発することを含むアプローチです。この戦略により、変更を並行して行い、リスクを軽減し、現在の機能を維持しながら、将来の機能をサポートするためのより強力な基盤を構築することができます。
しかし、ビジネスの観点から見ると、このオプションは既存のシステム (すでに稼働しており、その機能を実行している) に過度のリスクをもたらします。私たちは既存のプロジェクトには触れず、代わりに新しいニーズを満たすスタンドアロン アプリケーションを開発することにしました。
この変更により、既存のコードベースをフォークすることになりました。これは技術的には可能ですが、いくつかの欠点がありました。
このアプローチにより、新しい戦略目標に沿ったプロジェクトを開発しながら、既存のシステムの安定性を確保しながら、独立したソリューションに移行することができます。ただし、自信を持ってこの課題に計画を立てて対処するには、長所と短所を詳細に分析する必要があります。さらに、新しい電子商取引プラットフォームへの移行が完了するまでは機能を拡張せず、プロジェクトのバックログを厳密に管理するというビジネス レベルの合意に達しました。
优点 | 缺点 |
---|---|
在非生产环境中工作,降低生产环境的风险 | 需要暂时维护多个项目 |
自由地从零开始实施新技术和模式 | 在维护方面的努力暂时重复 |
不必担心旧系统的技术限制或依赖关系 | 由于需要在系统之间同步更改,功能的重复可能会长期减缓开发速度 |
能够专注于必要的特性 | 截止日期的风险,因为有两个代码库 |
有机会从一开始就实施最佳实践 | 项目管理的复杂性 |
更容易从一开始就实施测试 | 需要与历史数据保持兼容性 |
灵活地适应新的业务需求 | 初始时间和资源成本更高 |
更好地与公司的整体战略相一致 | 可能暂时丢失非必要的特性 |
レガシー ソフトウェアを内部化して書き直すという決定は、特にソフトウェアがその機能を実行できる場合には、決して簡単ではありません。 「うまくいくなら触るな」という格言は常に存在します。しかし、時には二歩前進するためには一歩後退することもあります。
このシリーズの後続の記事では、これらの課題にどのように対応したか、技術的および戦略的決定を下したのか、そしてこれらの課題を改善とチーム開発の機会にどのように変えたかを探っていきます。
以上がソフトウェアの遺産から戦略的機会へ: 出発点 (I)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。