01 まず、このシステムの歴史的な重荷について話しましょう
当社の広告エンジンは、この再構築までに約 1 年半かかりました。最初のイテレーションは、単一のビジネスと明確なプロセスを伴う検索シナリオに焦点を当てています。
#1. ビジネス シナリオが複雑になり始めました。検索広告に加えて、情報フローの推奨および同様の推奨シナリオをサポートする必要もあります。
2. 広告トラフィックが急速に増加し始めており、機能要件を満たすだけでなく、パフォーマンスも考慮する必要があります。
整理した結果、エンジン全体のロジックのほとんどが共有できるため、メインフレームワークを定義し、拡張可能にしました部分的に抽象化されています。このようにして、各シナリオは、自身のビジネスの特殊性に応じて特定のパブリック インターフェイスを実装できます。さらに、パフォーマンスの観点から、コードの可読性を一部犠牲にし、一部のロジックを並列化しました。
ビジネスの発展に伴い、検索シナリオは急速な反復期間に入り始め、新しい戦略がどんどん追加され、この時点で私たちの主要なフレームワークは徐々に柔軟性がなくなりました。
1. 特殊な検索ロジックと互換性を持たせるため、これらのロジックをバイパスするには、他のシナリオにさまざまな if 判定を追加する必要があります。
2. 広告戦略はますます多くなり、合計で数十になります。フレームワークが明確な構造を失うと、一部の戦略の実装はカスタマイズされ始め、階層的な分割がなくなります。抽象的なデザイン。
転機は 2019 年末に訪れました。広告ビジネスの特殊性により、トラフィックは自然に減少し始めましたさらに、製品運用チームは 2 年目の作業計画に重点を置いているため、この再構築を開始するのに非常に良い期間が与えられます。
構築期間は 1 か月に設定しましたが、最終的には予定より 1 日遅れただけでした。オンラインでの問題が 2 つありましたが、グレースケールでしたそれらは時間内に発見されて修復され、オンライン事故は発生しませんでした。 02 リファクタリングの前にどのような準備をしましたか? 今回リファクタリングしたコード量は3万行以上と非常に多く、広告システムの中核となるエンジン部分です。開始する前に、次のような困難が予想されます: #1、ビジネス側の抵抗 : 広告は非常にビジネス指向です。この再構築は長期的な研究開発の効率を向上させることはできますが、直接的に事業収益を向上させることはできませんし、開発サイクルも短すぎるわけではありません。ビジネスクラスの友人からサポートを得るにはどうすればよいですか? ? ▍問題点を全員に理解してもらいましょう 前述したように、ビジネスの反復により、広告エンジンの主要なフレームワークがあいまいになり、数十の広告戦略がさまざまなビジネス シナリオに散らばり、構成が乱雑になりました。 これら 2 つの問題点を考慮して、私たちは 1 か月前から既存のビジネスの整理を開始し、古いコードを読み、以前の要件ドキュメントに目を通しました。さまざまなシナリオのプロセスと広告戦略を明確な表に分類します。 このテーブルにより、テクノロジーと製品が初めてエンジン部分の全体像を明確に把握し、ビジネスの複雑さと現在の技術的なボトルネックを理解できるようになります。 ▍リファクタリングの目標と価値を明確にする 誰もが感じられるようにする問題点 最後に、この再構築の 2 つの中心的な目標を計画しました: 1. メイン フレームワークの再構築: メイン プロセスのモジュール化、上位プロセスの再定義明確なインターフェイスを確保するための下位層プロトコルも必要ですが、各層は抽象化され、優れたスケーラビリティを備えている必要もあります。 2. 柔軟で構成可能な戦略: 広告戦略はビジネスの意図に従って分類および抽象化され、戦略の実行条件は動的に構成可能であり、戦略はいつでもプラグインおよびプラグアウトできます。意思。 さらに、次の 2 つの中心的な目標を達成した後にもたらされる期待される利点を改良しました。 #1. 技術的利点: コード構造がより明確になり、理解と保守が容易になり、スケーラビリティが強化され、エンジンの開発効率がさらに向上します。 2. ビジネス上の利点: 戦略により、よりきめ細かい構成と拡張が実現でき、ビジネス サポートがより容易になります。R&D 効率の向上により、ビジネスの反復をさらにスピードアップできます。 ##▍全体のリズムのコントロール 全体のリズムのコントロールも非常に重要な部分であり、誰もがこの点についてタイムの予想を立てることができます。 まず、工期を1ヶ月と設定しましたが、事業側の許容限界期間を考慮する一方で、技術的に早期に解決したいという希望もありました。 ; 一方、春節が近づいているので、会社がネットワークをシャットダウンする前に急いでオンラインにし、予期せぬ事態を防ぐために 1 ～ 2 週間のバッファを確保する必要があります。 03 導入プロセス中にどのような経験を共有できますか? #1. 高品質の技術設計計画 これは日々の要件によるものであり、開発サイクルが 3 日を超えるプロジェクトの技術的ソリューションを設計しますが、この再構築ももちろん例外ではありません。 フレームワークの全体的なアーキテクチャ、モジュール間のプロトコル設計、および戦略のスケーラビリティ設計が、この技術ソリューションの焦点です。チームはそれについて少なくとも議論しました。 3回です。 大きな計画が完成した後、チームはデータベース、インターフェースフィールド、キャッシュ構造、ログ埋め込みポイントなどの公開部分をさらに洗練させました。複数人での共同開発が必要となるためです。 、チームは、コミュニケーションインターフェイスとしてドキュメントを使用すると、ドキュメントは常にコードと同期されることに同意しました。 2. フレームワーク コードの事前再構築 この PR は非常に重要であり、当社の技術的ソリューションです。コードに着地するための最も重要なステップ。最初に実装の詳細を無視して、再構築されたパッケージ構造、モジュール分割、各レイヤー間の API 定義、さまざまな広告戦略の抽象化を整理しました。 このようにして、基本的にコード本体が形成され、理想的なフレームワークが明確に表現されます。その後、複数の集中コードレビューを組織し、最終的に統一意見を形成しました。 このステップにより、実装の詳細に早すぎて主要なフレームワークや不安定なコードへの注意が不十分になり、後でやり直して効率が低下することを十分に回避できます。 3. 頻繁なコミュニケーションとペアのコード レビュー メカニズム 詳細な実装段階に入った後、非常に重要な点は次のとおりです。理解。エンジン コードは 1 年半にわたって繰り返され、歴史上多くの人々によって開発されてきましたが、今回復元に参加した学生はわずか 3 名でした。 #プロセス全体を通じて、コードロジックが不明瞭な場合は、主観的な推測をせず、コミュニケーションと検証を繰り返しましたが、この注意は実は非常に重要です。 また、コードレビューに関しては、この業務に精通した学生が各モジュールを担当し、二人一組で柔軟な仕組みになっています。 4. 効果的なテスト計画 リファクタリングは行われていません。まずテストを行ってください。この原則は、書籍『リファクタリング』で強調されており、この技術的ソリューションに関する議論の焦点でもあります。ここでは、それを取り上げて詳しく説明します。 まず、古いコードは残さず、完全に新しいパッケージを構築して再構築するということを初期段階で合意しました。これにより、再構成前後の結果を比較し、同時にオンラインでグレースケール実験を行うことが簡単になります。 テスト計画に関しては、次の 4 つのポイントを学ぶ価値があります。 1 . エンドツーエンドのテスト: この再構築には機能調整は含まれないため、外部 API の動作は変わりません。このエンドツーエンドのテスト方法が最も効果的です。これが最も重要な手段です。研究開発とQAテスト。 2. 発煙テスト: QA の学生が発煙ケースを提供し、研究開発の学生が発煙を実施します。研究開発テストの前に、すべての発煙ケースに合格する必要があります。 これはほとんどのインターネット企業では一般的ではありませんが、大規模なプロジェクトでは絶対に効果的です。 3. サンドボックス環境のデュアルプロセス検証: 前述したように、再構築の前後のコードが保持されるため、オンライン環境の入力パラメータをスクリプトを通じてキャプチャできます。自動化されたメソッドを使用して、API の返されたフィールドを 1 つずつ比較します。 4. オンライン環境のグレースケール実験: 再構成にはグレースケールが非常に重要です。既存の ABTest プラットフォームを使用して、グレースケール トラフィックを 5% から 10% まで段階的に自由化します。 30%、そして最終的には 100% まで、非常に慎重な量増加ペースが確立され、ログとビジネス指標の監視を通じて検証されました。 #最後に書きます 再構築プロセス全体を確認し、次のようにまとめます。次の 7 つの重要なポイント: 
以上がハードコアなもの: コア システム内の 30,000 行を超えるコードを再構築する旅の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。