ソフトウェアの遺産から戦略的機会へ: 出発点 (I)

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

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

技術的負債の蓄積

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

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

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

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

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

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

構造上の制限

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

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

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

開発管理と戦略的連携

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

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

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

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

基本コストの影響

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

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

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

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

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

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

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

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

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

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

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

优点	缺点
在非生产环境中工作，降低生产环境的风险	需要暂时维护多个项目
自由地从零开始实施新技术和模式	在维护方面的努力暂时重复
不必担心旧系统的技术限制或依赖关系	由于需要在系统之间同步更改，功能的重复可能会长期减缓开发速度
能够专注于必要的特性	截止日期的风险，因为有两个代码库
有机会从一开始就实施最佳实践	项目管理的复杂性
更容易从一开始就实施测试	需要与历史数据保持兼容性
灵活地适应新的业务需求	初始时间和资源成本更高
更好地与公司的整体战略相一致	可能暂时丢失非必要的特性

結論と次のステップ

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

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

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