ハードコアなもの: コア システム内の 30,000 行を超えるコードを再構築する旅

古典的な本「リファクタリング」には次の一節があります:

当初、私が行ったリファクタリングはすべて細部に関するものでした。コードが簡潔になるにつれて、以前は理解できなかった設計レベルのことがいくつか見えてくることに気づきましたが、リファクタリングがなければこのレベルに到達することはできなかったでしょう。

リファクタリングは、プログラマにとって非常に興味深いものです。

今年の初めに、私たちのチームは複雑なプロジェクトの再構築を完了しました。これは広告システムのコア エンジン部分であり、約 300 個以上のファイルがあります。 30,000 ファイル、コード行数。

技術ソリューションの設計から最終的な完全な打ち上げまでわずか 1 か月しかかかりませんでしたが、事故はありませんでした。

これは、私が 8 年間のプログラミング キャリアの中で経験した中で最大かつ最も成功したリファクタリング プロジェクトになるはずです。速度は十分に速く、計画は包括的で、品質はまずまずです。 。

01 まず、このシステムの歴史的な重荷について話しましょう

当社の広告エンジンは、この再構築までに約 1 年半かかりました。最初のイテレーションは、単一のビジネスと明確なプロセスを伴う検索シナリオに焦点を当てています。

2019 年初頭、同社の広告ビジネスは急速に拡大し始め、収益はほぼ指数関数的に増加しました。このプロセスで、当社の広告エンジンは 2 つの課題に直面しました:

#1. ビジネス シナリオが複雑になり始めました。検索広告に加えて、情報フローの推奨および同様の推奨シナリオをサポートする必要もあります。

2. 広告トラフィックが急速に増加し始めており、機能要件を満たすだけでなく、パフォーマンスも考慮する必要があります。

整理した結果、エンジン全体のロジックのほとんどが共有できるため、メインフレームワークを定義し、拡張可能にしました部分的に抽象化されています。このようにして、各シナリオは、自身のビジネスの特殊性に応じて特定のパブリック インターフェイスを実装できます。さらに、パフォーマンスの観点から、コードの可読性を一部犠牲にし、一部のロジックを並列化しました。

ビジネスの発展に伴い、検索シナリオは急速な反復期間に入り始め、新しい戦略がどんどん追加され、この時点で私たちの主要なフレームワークは徐々に柔軟性がなくなりました。

本体フレームを移動した場合、探索以外のシーンもそれに合わせて再構築する必要があります。 事業急成長期においては、工期が一切認められないため、既存の枠組みでパッチ開発を行うことしかできません。 これは 2 つの明らかな問題を引き起こします:

1. 特殊な検索ロジックと互換性を持たせるため、これらのロジックをバイパスするには、他のシナリオにさまざまな if 判定を追加する必要があります。

2. 広告戦略はますます多くなり、合計で数十になります。フレームワークが明確な構造を失うと、一部の戦略の実装はカスタマイズされ始め、階層的な分割がなくなります。抽象的なデザイン。

#この状況では、変更が累積するにつれて、コードは設計の本来の意図から逸脱し始め、技術的負債が増大し、より重い。しかし、リファクタリングを行う適切なタイミングを見つけることができませんでした。

転機は 2019 年末に訪れました。広告ビジネスの特殊性により、トラフィックは自然に減少し始めましたさらに、製品運用チームは 2 年目の作業計画に重点を置いているため、この再構築を開始するのに非常に良い期間が与えられます。

構築期間は 1 か月に設定しましたが、最終的には予定より 1 日遅れただけでした。オンラインでの問題が 2 つありましたが、グレースケールでしたそれらは時間内に発見されて修復され、オンライン事故は発生しませんでした。

全体として、これは非常に困難で比較的成功したリファクタリング プロジェクトですが、このプロジェクトから学んだ貴重な経験について詳しく話しましょう。

02 リファクタリングの前にどのような準備をしましたか?

今回リファクタリングしたコード量は3万行以上と非常に多く、広告システムの中核となるエンジン部分です。開始する前に、次のような困難が予想されます:

#1、ビジネス側の抵抗 : 広告は非常にビジネス指向です。この再構築は長期的な研究開発の効率を向上させることはできますが、直接的に事業収益を向上させることはできませんし、開発サイクルも短すぎるわけではありません。ビジネスクラスの友人からサポートを得るにはどうすればよいですか? ?

2. 技術面の懸念: リファクタリングによってオンライン事故が発生すると、会社にはペナルティ制度が設けられています。軽率に行動しますか?戦闘に参加しますか?同時に、再構築プロセス中に非常に多くのビジネスの反復が散在する場合、誰も納期を保証できず、品質の管理が困難になります。

#これら 2 つの当事者の懸念に応えて、私は次のタスクが重要な役割を果たすと考えています。

▍問題点を全員に理解してもらいましょう

前述したように、ビジネスの反復により、広告エンジンの主要なフレームワークがあいまいになり、数十の広告戦略がさまざまなビジネス シナリオに散らばり、構成が乱雑になりました。

これら 2 つの問題点を考慮して、私たちは 1 か月前から既存のビジネスの整理を開始し、古いコードを読み、以前の要件ドキュメントに目を通しました。さまざまなシナリオのプロセスと広告戦略を明確な表に分類します。

このテーブルにより、テクノロジーと製品が初めてエンジン部分の全体像を明確に把握し、ビジネスの複雑さと現在の技術的なボトルネックを理解できるようになります。

▍リファクタリングの目標と価値を明確にする

誰もが感じられるようにする問題点 最後に、この再構築の 2 つの中心的な目標を計画しました:

1. メイン フレームワークの再構築: メイン プロセスのモジュール化、上位プロセスの再定義明確なインターフェイスを確保するための下位層プロトコルも必要ですが、各層は抽象化され、優れたスケーラビリティを備えている必要もあります。

2. 柔軟で構成可能な戦略: 広告戦略はビジネスの意図に従って分類および抽象化され、戦略の実行条件は動的に構成可能であり、戦略はいつでもプラグインおよびプラグアウトできます。意思。

さらに、次の 2 つの中心的な目標を達成した後にもたらされる期待される利点を改良しました。

#1. 技術的利点: コード構造がより明確になり、理解と保守が容易になり、スケーラビリティが強化され、エンジンの開発効率がさらに向上します。

2. ビジネス上の利点: 戦略により、よりきめ細かい構成と拡張が実現でき、ビジネス サポートがより容易になります。R&D 効率の向上により、ビジネスの反復をさらにスピードアップできます。

復興の価値を全員に伝えることで、さらに全員の興奮が高まり、全員の参加意欲がさらに高まりました。

##▍全体のリズムのコントロール

全体のリズムのコントロールも非常に重要な部分であり、誰もがこの点についてタイムの予想を立てることができます。

まず、工期を1ヶ月と設定しましたが、事業側の許容限界期間を考慮する一方で、技術的に早期に解決したいという希望もありました。 ; 一方、春節が近づいているので、会社がネットワークをシャットダウンする前に急いでオンラインにし、予期せぬ事態を防ぐために 1 ～ 2 週間のバッファを確保する必要があります。

さらに、ビジネス側との合意に達しました: 再構築期間中は、エンジン部分に対する緊急でない要件は受け入れられません。これにより、並行開発とコードの競合を最小限に抑え、チームが次のことを行うことができます。もっと集中してください。

03 導入プロセス中にどのような経験を共有できますか?

今回のリファクタリングは非常にスムーズに実施できましたので、貴重な体験談を 4 つお伝えしたいと思います。

#1. 高品質の技術設計計画

これは日々の要件によるものであり、開発サイクルが 3 日を超えるプロジェクトの技術的ソリューションを設計しますが、この再構築ももちろん例外ではありません。

フレームワークの全体的なアーキテクチャ、モジュール間のプロトコル設計、および戦略のスケーラビリティ設計が、この技術ソリューションの焦点です。チームはそれについて少なくとも議論しました。 3回です。

大きな計画が完成した後、チームはデータベース、インターフェースフィールド、キャッシュ構造、ログ埋め込みポイントなどの公開部分をさらに洗練させました。複数人での共同開発が必要となるためです。 、チームは、コミュニケーションインターフェイスとしてドキュメントを使用すると、ドキュメントは常にコードと同期されることに同意しました。

このような高い要件の下、チームは 5,000 ワードを超える合計 36 ページの技術ソリューション ドキュメントを作成し、全体的な品質保証の優れた基盤を築きました。

2. フレームワーク コードの事前再構築

この PR は非常に重要であり、当社の技術的ソリューションです。コードに着地するための最も重要なステップ。最初に実装の詳細を無視して、再構築されたパッケージ構造、モジュール分割、各レイヤー間の API 定義、さまざまな広告戦略の抽象化を整理しました。

このようにして、基本的にコード本体が形成され、理想的なフレームワークが明確に表現されます。その後、複数の集中コードレビューを組織し、最終的に統一意見を形成しました。

このステップにより、実装の詳細に早すぎて主要なフレームワークや不安定なコードへの注意が不十分になり、後でやり直して効率が低下することを十分に回避できます。

3. 頻繁なコミュニケーションとペアのコード レビュー メカニズム

詳細な実装段階に入った後、非常に重要な点は次のとおりです。理解。エンジン コードは 1 年半にわたって繰り返され、歴史上多くの人々によって開発されてきましたが、今回復元に参加した学生はわずか 3 名でした。

#プロセス全体を通じて、コードロジックが不明瞭な場合は、主観的な推測をせず、コミュニケーションと検証を繰り返しましたが、この注意は実は非常に重要です。

また、コードレビューに関しては、この業務に精通した学生が各モジュールを担当し、二人一組で柔軟な仕組みになっています。

4. 効果的なテスト計画

リファクタリングは行われていません。まずテストを行ってください。この原則は、書籍『リファクタリング』で強調されており、この技術的ソリューションに関する議論の焦点でもあります。ここでは、それを取り上げて詳しく説明します。

まず、古いコードは残さず、完全に新しいパッケージを構築して再構築するということを初期段階で合意しました。これにより、再構成前後の結果を比較し、同時にオンラインでグレースケール実験を行うことが簡単になります。

テスト計画に関しては、次の 4 つのポイントを学ぶ価値があります。

1 . エンドツーエンドのテスト: この再構築には機能調整は含まれないため、外部 API の動作は変わりません。このエンドツーエンドのテスト方法が最も効果的です。これが最も重要な手段です。研究開発とQAテスト。

2. 発煙テスト: QA の学生が発煙ケースを提供し、研究開発の学生が発煙を実施します。研究開発テストの前に、すべての発煙ケースに合格する必要があります。 これはほとんどのインターネット企業では一般的ではありませんが、大規模なプロジェクトでは絶対に効果的です。

3. サンドボックス環境のデュアルプロセス検証: 前述したように、再構築の前後のコードが保持されるため、オンライン環境の入力パラメータをスクリプトを通じてキャプチャできます。自動化されたメソッドを使用して、API の返されたフィールドを 1 つずつ比較します。

4. オンライン環境のグレースケール実験: 再構成にはグレースケールが非常に重要です。既存の ABTest プラットフォームを使用して、グレースケール トラフィックを 5% から 10% まで段階的に自由化します。 30%、そして最終的には 100% まで、非常に慎重な量増加ペースが確立され、ログとビジネス指標の監視を通じて検証されました。

#最後に書きます

再構築プロセス全体を確認し、次のようにまとめます。次の 7 つの重要なポイント:

1. リファクタリングの機会を活かす

2. 早期の並べ替えが非常に重要です。最初に問題点を見つけます

3. 明確にする みんなをワクワクさせる目標や価値観を考える

#4. 長期的な運営には向いていない、ビジネスとの並行運営には向いていない

#5. 高品質の技術が必要計画

#6. リファクタリングは完了していないため、最初にテスト

7. 慎重に検証し、コードのすべての行に責任を持ちます

もちろん、最も重要な要素は人材であり、大規模なプロジェクトのリファクタリングでは、チームのコラボレーション能力が非常にテストされます。全員が信頼できる場合、リファクタリングはすでに半分成功しています。

以上がハードコアなもの: コア システム内の 30,000 行を超えるコードを再構築する旅の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。