独自の宅配便プラットフォームを作成する方法と理由

みなさん、こんにちは。私の名前はAlexeyOstrikovです。Yandex.Marketで開発を担当しています。たくさんのコードを書いた後、1年半の間、マーケットサービスの1つのバックエンドグループを率い、現在はマーケット宅配便プラットフォームの開発を担当しています。



今日は、アウトソーシングによる配送が必ずしも良いとは限らない理由、プロセスの透明性が必要な理由、宅配業者が注文を配送するのに役立つプラットフォームを1年半でどのように作成したかについて説明します。また、開発の世界からの3つのストーリーを共有します。





写真は10ヶ月前の宅配便プラットフォームチームです。当時、彼女は1つの部屋に入れられていました。今では私たちの5倍がいます。

なぜ私たちはこれをすべてやったのですか

宅配便プラットフォームを開発するとき、私たちは3つの主要なものをアップグレードしたかった。



1つ目は品質です。外部配送サービスを利用する場合、品質を管理することはできません。請負業者は、そのような配達可能性があることを約束しますが、特定の数の注文が配達されない場合があります。また、遅延の割合を最小限に抑えて、ほぼすべての注文が時間どおりに配達されるようにしたいと考えました。



二つ目は透明性です..。何かがうまくいかないとき（転送、期限があります）、なぜそれらが起こったのかわかりません。 「みんな、こうやってやろう」と言うことはできません。私たち自身は見ていませんし、クライアントに追加のことを示すこともできません。たとえば、注文は8時ではなく、15分以内に到着します。これは、プロセスにそのようなレベルの透明性がないためです。



三つ目はお金です..。私たちが請負業者と仕事をするとき、金額を詳しく説明する契約があります。そして、契約の枠内でこれらの数値を変更することができます。また、aからzまでのプロセス全体を担当する場合、システムのどの部分が経済的に不採算であるかを確認できます。また、たとえば、SMSプロバイダーまたはドキュメントフロー形式を変更できます。または、宅配便の走行距離が長すぎることに気付くかもしれません。そして、ルートをより緊密に構築すると、最終的にはより多くの注文を配信できるようになります。これのおかげで、あなたはお金を節約することもできます-配達はより効率的になります。



これらは、私たちがすべての先頭に設定した3つの目標でした。

プラットフォームはどのように見えるか

私たちが得たものを見てみましょう。







画像はプロセスの図を示しています。数十万件の注文を処理する大規模な倉庫があります。注文でいっぱいになったトラックは、夕方に各倉庫を出発します。 5〜6千件の注文がある場合があります。これらのトラックは、仕分けセンターと呼ばれる小さな建物に移動します。それらの中で、数時間で、注文の大きな山は宅配便業者のための小さな山に変わります。そして、午前中に宅配便業者が車に到着すると、各宅配便業者は、このQRコードを使って束を受け取り、車に積み込んで配達に行く必要があることを知っています。



そして、この記事で話したいバックエンドは、注文が顧客に届くプロセスの最後の部分についてです。この前にあることはすべて、当分の間、私たちは脇に置きます。





宅配便業者がそれをどのように見ているか宅配便業者は、



ReactNativeで記述されたAndroidアプリを持っています。そして、このアプリケーションでは、彼らは一日中見ています。彼らはシーケンスを明確に理解しています：最初に行くアドレス、後で行くアドレス。いつ顧客に電話するか、いつどのように仕分けセンターに戻るか、どのように一日を始めるか、どのように終わらせるか。彼らはアプリケーションのすべてを見て、実際には不必要な質問をしません。私たちは彼らを大いに助けます。基本的に、彼らはただ割り当てをしているだけです。







さらに、プラットフォームにはコントロールがあります。これは、別のYandexサービスから再利用した多機能の管理パネルです。この管理領域では、システムの状態を構成できます。そこに新しい宅配便業者に関するデータをアップロードし、作業間隔を変更します。明日のタスクを作成するプロセスを調整できます。必要なほとんどすべてが規制されています。



ちなみに、バックエンドについて。私たち市場では、ほとんどがバージョン11のJavaが大好きです。また、これから説明するすべてのバックエンドサービスはJavaで記述されています。

建築

プラットフォームのアーキテクチャには、3つの主要なノードがあります。最初は外の世界とのコミュニケーションに責任があります。持ち出されたクーリエアプリケーションはバランサーを「ノック」し、標準のJSON HTTPAPIを使用してバランサーと通信します。実際、このノードは、宅配便業者が何かを転送したり、キャンセルしたり、注文を発行したり、新しいタスクを受け取ったりする、今日のすべてのロジックを担当します。



2番目のノードは、Yandex内部サービスと通信するサービスです。すべてのサービスは、標準的な通信を備えた従来のRESTfulサービスです。マーケットで注文すると、しばらくするとJSON形式のドキュメントが届き、そこにすべてが書き込まれます。いつ、誰に、どの間隔で配達するかです。そして、この状態をデータベースに保存します。それは簡単です。



さらに、2番目のノードは、MarketではなくYandexの他の内部サービスとも通信します。たとえば、地理座標を明確にするために、ジオサービスに移動します。プッシュ通知を送信するには、プッシュとSMSを送信するサービスに移動します。承認には別のサービスを使用します。明日のルーティングを計算するための別のサービス。したがって、内部サービスとのすべての通信が実行されます。



このノードはエントリポイントでもあり、管理パネルがノックオンするAPIがあります。これには、たとえば/パートナーと呼ばれる独自のエンドポイントがあります。また、システムの状態全体である管理パネルは、このサービスとの通信を通じて構成されます。



3番目のノードはバックグラウンドタスクベースです。ここではクォーツ2が使用されており、さまざまなポイント、さまざまなソートセンターに対して、さまざまな条件でクラウンで起動されるタスクがあります。日を更新するタスク、日を閉じるタスク、新しい日を開始するタスクがあります。



そして、すべての中心にあるのはデータベースであり、実際にはすべての状態が格納されています。すべてのサービスが1つのデータベースに含まれています。

フォールトトレランス

Yandexには複数のデータセンターがあり、当社のサービスは3つのデータセンターに地域的に分散しています。それはどのようなものか。



データベースは3つのホストで構成され、それぞれが独自のデータセンターにあります。 1つのホストはマスターで、他の2つはレプリカです。マスターに書き込み、行から読み取ります。他のすべてのJavaサービスも、複数のデータセンターで実行されるJavaプロセスです。



ノードの1つはAPIです。メッセージのフローは内部サービスからのフローよりも多いため、3つのデータセンターすべてで実行されます。さらに、このようなレイアウトを使用すると、水平方向に非常に簡単に拡大縮小できます。



たとえば、着信トラフィックが9倍に増加した場合、最適化できますが、着信トラフィックを処理するノードをさらに開くことで、このビジネスを鉄で「氾濫」させることもできます。



バランサーは、トラフィックを要求を満たす多数のポイントに分割するだけで済みます。そして今、たとえば、各データセンターに1つのノードではなく、2つのノードがあります。



私たちのアーキテクチャでは、データセンターの1つがシャットダウンした場合でも対処できます。たとえば、演習を実施してウラジミールのデータセンターをオフにすることにしましたが、サービスは継続しており、何も変わりません。そこにあるデータベースホストは消え、サービスは動作し続けます。



バランサーはしばらくすると理解します。ええ、このデータセンターにはライブホストが1つも残っておらず、トラフィックをリダイレクトしなくなりました。



Yandexのすべてのサービスは同様の方法で配置されており、データセンターの1つの障害を乗り切る方法を私たちは皆知っています。これがどのように実装されるか、グレースフルデグラデーションとは何か、Yandexサービスがデータセンターの1つのシャットダウンをどのように処理するか についてはすでに説明しました。



それが建築でした。そして今、物語が始まります。

最初の話-Yandex.Roverについて

最近、ローバーが大きな注目を集めたさらに別の会議がありました。トピックを続けます。



Yandex.Roverチームのメンバーが私たちのところに来て、人々がそのような並外れた方法で注文を受けたいという仮説をテストすることを申し出たことがあります。



Yandex.Roverは、平均的な犬のサイズの小さなロボットです。あなたはそこに食べ物を置くことができます、注文の箱のカップル-彼は街を一周し、人間の助けなしに注文をもたらします。 LIDARがあり、ロボットは空間内での位置を理解します。彼は小さな注文を届ける方法を知っています。



そして、私たちは考えました：なぜですか？実験の詳細を明らかにしました。当時、人々がそれを望んでいるという仮説を検証する必要がありました。そして、非常に軽いモードで1週間半に50件の注文を配信することにしました。







私たちは、人が非標準の配送方法の提案を含むSMSを受信したときに、最も単純なフローを思いつきました-宅配便ではなく、ローバーがそれを持ってきます。実験全体はYandexの中庭で行われました。男はローバーが運転する入り口を選んでいました。ロボットが到着すると、蓋が開かれ、クライアントが注文を受け取り、蓋を閉じ、ローバーは新しい注文のために出発しました。それは簡単です。



次に、Roverのチームに行ってAPIを交渉しました。



Rover APIには、簡単な方法があります。ふたを開き、ふたを閉じ、特定のポイントに移動して、状態を取得します。クラシック。また、JSON。とてもシンプルです。



また、非常に重要なことは、そのような小さなストーリーと大きなストーリーの両方が、機能フラグを介して行うのが最適です。実際、本番環境でこのストーリーを有効にできるスイッチがあります。不要になったとき、実験が正常に完了したか失敗したとき、またはいくつかのバグに気付いたときは、それを切り詰めるだけです。また、本番用に新しいバージョンのコードを再度デプロイする必要はありません。このことは人生をずっと楽にしてくれます。



すべてが単純で、すべてが機能するはずです。 2週間は開発するものがなく、数日で開発できます。しかし、犬が埋葬されている場所を見てください。



すべてのプロセスはほとんど同期しています。男がボタンを押すと、ふたが開きます。男がボタンを押すと、ふたが閉まります。ただし、これらのプロセスの1つは非同期です。ローバーがあなたのところに行く瞬間に、ロボットがポイントに戻ったことを追跡する何らかのバックグラウンドプロセスが必要です。



そしてこの時点で、たとえばローバーがその場所で待機しているというSMSをその人に送信します。これは同期的に行うことはできず、何らかの方法でこの問題を解決する必要があります。



多くの異なるアプローチがあります。可能な限りシンプルにしました。



Executerで最も一般的なバックグラウンドJavaスレッドまたはタスクを実行できると判断しました。このバックグラウンドスレッドは、プロセスを追跡するためにすぐに起動されます。そして、プロセスが完了するとすぐに、通知を送信します。







たとえば、次のようになります。これは、削除されたコメントを除いて、実際には製品コードのコピーです。しかし、落とし穴があります。このように本格的なシステムを作ることはできません。新しいバージョンをバックエンドに展開しているとしましょう。ホストが再起動し、状態が失われます。それだけで、ローバーは無限大になり、他の誰も彼を見ることができません。



しかし、なぜ？ 1週間半で50件の注文を配信することが目標であることがわかっている場合は、バックエンドを監視する時間を選択します。何か問題が発生した場合は、手動で変更できます。このようなタスクには、このソリューションで十分です。そして、これが最初の話の教訓です。



機能の最小バージョンを作成する必要がある状況があります。庭やオーバーエンジニアを囲う必要はありません。できるだけ疎外することをお勧めします。内部オブジェクトのロジックをあまり変更しないように。そして、過度の複雑さ、不必要な技術的負債は蓄積されませんでした。

2番目の話-データベースについて

しかし、最初に、主要なエンティティがどのように配置されているかについてのいくつかの言葉。一日の終わりに宅配便のルートを構築するYandex.Routingサービスがあります。



各ルートは、マップ上のポイントで構成されています。そして、それぞれの時点で、宅配便業者には仕事があります。これは、注文を発行したり、クライアントに電話したり、朝の仕分けセンターで荷物を受け取ったりするタスクです。



さらに、クライアントは午前中に追跡リンクを受け取ります。彼らは地図を開いて、宅配便業者がどのように彼らに移動するかを見ることができます。クライアントは、前述したローバーによる配信を選択することもできます。



次に、これらのエンティティをデータベースに表示する方法を見てみましょう。これは、たとえば、このように行われます。







これは非常に優れたデータモデルです。私たちは単一の新しいエンティティを発明したわけではなく、既存のエンティティを強く崩壊させることもありませんでした。



この図は、下から上への矢印が宅配便のルートを示しており、ルートが誰であるかを知っていることを示しています。宅配便標識には、宅配便IDリンクが含まれています。そして、トッププレートはこれを知りません。最も単純な接続があり、エンティティの大きな共通部分はありません。誰もがすべてのことを知っていると、制御がより困難になり、おそらく冗長性が生じます。したがって、可能な限り単純なスキームがあります。



プラットフォームの作成当初に私たちが行った唯一の「やり過ぎ」はこれです。 1つのタイプの配信割り当てがありました。しかし、将来的には他のタスクがあることに気づきました。そして、アーキテクチャに少し柔軟性を持たせました。タスクがあり、タスクのタイプの1つは注文の配送です。



次に、トラッキングとローバーを追加しました。たった2錠。追跡では、宅配便業者が座標を送信し、別のプレートに記録します。また、独自の状態モデルによる注文追跡があり、「SMSが残った/消えなかった」などの追加事項があります。これをタスクに直接追加しないでください。この追跡はすべてのタイプのタスクに必要なわけではないため、別のプレートに配置することをお勧めします。







ローバーで-彼のコーディネートと配達。ローバーによる配達は、ローバーの追跡のようなものです。追跡順序に追加できますが、なぜですか？結局のところ、この実験を取り除くとき、それがオフにされるとき、これらのオプションは永遠に追跡の本質に残ります。 nullフィールドがあります。



疑問が生じるかもしれません：なぜ座標でプレートを作るのですか？ 1つのローバーが1日に5つの注文を配信します。データベースに座標を保存する必要はありません。RoverAPIにアクセスして、実行時に座標を取得するだけです。



肝心なのは、これが最初に行われたということです。このサインはそこにありませんでした、私たちはすぐにサービスに行き、それをすべて取りました。しかし、テスト中に、多くの人がローリングローバーで地図を開くことがわかりました。このサービスの負荷は何度も増加します。 7人が開いたとしましょう。そして、ページ上で2秒ごとにJavaScriptが座標を要求します。そして同僚はチャットで私たちに次のように書いています。スケートをする人が一人います。」



その後、サインを追加しました。そこに座標、つまりそれらが受信された時刻を追加し始めました。そして今、人々がコーディネートのために私たちに頻繁に来て、最後のレシートから2秒が経過していない場合、私たちは彼らをプレートから取り出します。データベースレベルでそのようなキャッシュが見つかります。



この話は20のテーブルで行うことができます。宅配便と注文の2つのテーブルを使用できます。しかし、前者の場合、それは過剰設計であり、後者の場合、維持するのは非常に困難です。複雑なロジック、テストが難しい。



そしてさらに。 1年半前に作成したデータベースの構造は、これらのエンティティのコアは今日まで変わっていません。そして、ベースをやり直す必要のないエンティティを選択できたのは非常に幸運でした。データベースを大幅に再描画し、複雑な移行を行ってから、このリリースをロールバックし、非常に長い時間テストしてから、ルート構造を変更する必要はありませんでした。



話のポイントは、特別な注意を払うほうがよい側面があるということです。最初は APIとデータベースの構造に特に注意してください。あなたが実生活でどんな種類の実体を持っているかに気付くようにしてください。この構造をほぼ同じ方法でデジタル化してみてください。短くしすぎたり、大きくしすぎたりしないようにしてください。



第二に、 修正するのに費用がかかる間違いがあります。APIを使用しているクライアントは通常多くあるため、APIレベルのエラーは、データベースレベルのエラーよりも修正が困難です。また、APIを大幅に変更する場合は、次のことを行う必要があります。

1. すべてのクライアントに到達し、下位互換性を確保します。
2. 新しいAPIを展開し、すべてのクライアントを新しいAPIに切り替えます。
3. クライアントに関する古いコードを切り取り、バックエンドで古いコードを切り取ります。

これは非常に高価です。



コードのエラーは、これと比較して一般的に意味がありません。コードを書き直して、テストを実行しただけです。テストは緑色です-マスターにプッシュしました。データベースAPIに特に注意してください。



そして、データベースを追跡しようとしても、時間の経過とともに、管理できないものになります。スクリーンショットでは、現在存在しているデータベースの10分の1を確認できます。







アドバイスが1つあります。何かを非常に迅速に開発すると、データベースに不正確さが生じたり、外部キーが欠落したり、重複するフィールドが表示されたりすることがあります。したがって、2、3か月に1回、ベースだけを見ることがあります。同じIntellijIDEAでクールな回路を生成できます。そして、そこにすべてを見ることができます。



データベースは適切でなければなりません。1時間に6つのチケットのリストを作成するのは非常に簡単です。ここに外部キーを追加し、そこにインデックスを追加します。どんなに頑張っても、必然的に破片がたまります。

3番目の話は品質についてです

最初からうまくやるのが一番いいことがあります。 「普通にやれば大丈夫」という原則に従って行動することが重要です。



たとえば、プラットフォームにとって重要なプロセスが1つあります。終日、明日の注文を収集していますが、夕方には、22：00以降は注文を収集していませんが、01：00までに明日の準備をしているというメモがトリガーされます。次に、仕分けセンターへの注文の配布が開始されます。 Yandex.Routingに移動し、ルートを作成します。



そして、この準備作業が失敗した場合、明日全体が問題になります。明日、宅配便業者は行くところがなくなります。彼らは状態を作成していません。これは、当社のプラットフォームで最も重要なプロセスです。そして、そのような重要なプロセスは、最小限のリソースで、残り物ベースで実行することはできません。



このプロセスが失敗したときがあったことを覚えています。数週間、チャットのチームのほぼ半数がこれらの問題を解決し、全員が1日を節約し、何かをやり直し、再起動していました。



夕方の10時から朝の1時まで処理が完了しないと、仕分けセンターは、ヒープのある注文を仕分けする方法すらわからないことを理解しました。そこではすべてがアイドル状態になります。宅配便は後で出てきて、品質に問題が発生します。



何かがうまくいかない可能性のあるすべてのステップを考えて、できるだけすぐにそのようなプロセスを実行することをお勧めします。そして、どこにでも最大量のわらを置きます。



このようなプロセスを設定する方法のオプションの1つについて説明します。



このプロセスはマルチコンポーネントです。ルートの計算とその公開は、部分に分割でき、たとえば、キュ​​ーを作成できます。次に、完了した作業セクションを担当するいくつかのキューがあります。そして、これらのキューには、メッセージを待って座っているコンシューマーがいます。







たとえば、1日が終わったら、明日のルートを計算します。まず、リクエストを送信します。タスクを作成して計算を開始します。消費者は最初のメッセージを受け取り、ルーティングサービスに行きます。これは非同期APIです。コンシューマーは、タスクが実行されたという応答を受け取ります。



彼はこのIDをベースに配置し、処理中のタスクを含む新しいジョブをキューに配置します。そしてそれがすべてです。メッセージは最初のキューから消え、2番目のコンシューマーは「ウェイクアップ」します。彼は処理のために2番目のタスクを実行します。彼のタスクは、定期的にルーティングに移動し、このタスクがまだ計算のために完了していないかどうかを確認することです。



「モスクワで数千の注文を配達する200人の宅配便業者のルートを作成する」レベルのタスクには、30分から1時間かかります。これは確かに非常に難しい作業です。そして、このサービスの人たちはとてもクールで、多くの時間を要する最も複雑なアルゴリズムの問​​題を解決します。



その結果、2番目のキューのコンシューマーは、単にチェック、チェック、チェックします。しばらくすると、タスクが完了します。タスクが完了すると、明日のルートと宅配便のシフトの必要な構造の形で回答を受け取ります。



計算したものを3番目に優先します。メッセージは2番目のキューから消えます。そして、3番目の消費者は「目覚め」、Yandex.Routingサービスからこのコンテキストを取得し、それに基づいて明日の状態を作成します。彼は宅配便の注文を作成し、注文を作成し、シフトを作成します。これも大変な作業です。彼はこれにしばらく時間を費やしています。そして、すべてが作成されると、このトランザクションは終了し、ジョブはキューから削除されます。



このプロセスのどこかで問題が発生した場合、サーバーは再起動します。その後の復元では、終了した時点が表示されます。最初のフェーズと2番目のフェーズが経過したとしましょう。そして、3番目に移りましょう。



このアーキテクチャでは、ここ数か月、すべてが非常にスムーズに進んでおり、問題はありません。しかし、確実なトライキャッチが行われる前に。プロセスがどこで失敗したか、データベース内でどのステータスが変更されたかなどは明確ではありません。



軽蔑してはいけないことがあります。あなたがすぐにすべてをうまくやればあなたがあなた自身にたくさんの神経細胞を救うであろうものがあります。

オフラインで何をしましたか

私たちのプラットフォームで起こっていることのほとんどを説明しました。しかし、何かが舞台裏に残っていました。



宅配便業者が1日以内に注文を配達するのに役立つソフトウェアについて学びました。しかし、誰かが宅配便業者のためにこれらのヒープを作成する必要があります。仕分けセンターでは、注文の大きな機械を小さな山に仕分けする必要があります。それはどのように行われますか？



これは、プラットフォームの2番目の部分です。私たちはすべてのソフトウェアを自分たちで書いた。これで、ストアキーパーがボックスからコードを読み取り、適切なセルに配置するための端末ができました。かなり複雑なロジックがあります。このバックエンドは、私がすでに説明したものよりもそれほど単純ではありません。



パズルのこの2番目のピースは、最初のピースと一緒に、プロセスを他の都市に拡張できるようにするために必要でした。そうでなければ、いくつかのExcelの郵送による交換を手配したり、APIと統合したりできる、新しい各都市の請負業者を探す必要があります。そして、それは非常に長い時間になるでしょう。



パズルの最初と2番目のピースができたら、建物を借りたり、車で宅配便を借りたりするだけです。押す方法、押すもの、選ぶ方法、どの箱をどこに置くかを教えてください。それだけです。このおかげで、私たちはすでに7つの都市で立ち上げ、10を超える仕分けセンターがあります。



そして、新しい都市で私たちのプラットフォームを開くのにかかる時間はごくわずかです。さらに、特定の人に注文を届けるだけではないことも学びました。私たちは、宅配便業者の助けを借りて、ピックアップポイントに注文を届ける方法を知っています。また、彼らのためにソフトウェアを作成しました。そして、これらの時点で、私たちは人々にも注文を出します。

結果

最初に、なぜ私たちが独自の宅配便プラットフォームを作り始めたのかを述べました。今、私たちが達成したことをお話しします。信じられないほどですが、私たちのプラットフォームを使用して、ほぼ100％の間隔を達成することができました。たとえば、先週のモスクワでの配達の質は約95〜98％でした。これは、95〜98％のケースで遅れていないことを意味します。クライアントが選択した間隔に合わせます。そして、外部の配送サービスだけに頼っていたとき、私たちはそのような精度を夢見ることさえできませんでした。そのため、現在、プラットフォームをすべての地域に徐々に拡大しています。そして、配信可能性を向上させます。



非現実的な透明性が得られました。この透明性も必要です。すべてが私たちと一緒に記録されます：すべてのアクション、注文を発行するプロセス全体。 5か月間の履歴に戻り、いくつかのメトリックを現在のメトリックと比較する機会があります。



しかし、私たちはクライアントにもこの透明性を与えました。彼らは宅配便が彼らに来るのを見ます。彼らは彼と対話することができます。彼らはサポートサービスに電話する必要はありません、「私の宅配便はどこにありますか？」と言います。



さらに、チェーンのすべての要素にアクセスできるため、コストを最適化することが判明しました。その結果、外部サービスを利用していたときよりも、1つの注文を配信するのにかかるコストが4分の1になりました。はい、注文配送のコストは25％削減されました。



そして、議論されたすべてのアイデアを要約すると、次のことが区別できます。



現在のサービスが開発のどの段階にあるか、現在のプロジェクトを明確に理解する必要があります。そして、これが何百万人もの人々によって使用され、おそらくいくつかの国で使用されている確立されたビジネスである場合、ローバーと同じレベルですべてを行うことはできません。



しかし、もしあなたが実験をしているのなら...実験はいつでも違うという点で、約束された結果を示さなければ、私たちは閉鎖することができます。離陸しませんでした。そしてそれは大丈夫です。



そして、私たちはこの体制に約10か月間いました。報告間隔があり、2か月ごとに結果を表示する必要がありました。そして、私たちはそれをしました。



このモードでは、長期的に投資し、短期的には何も得られないことによって何かをする権利がないように私には思えます。未来が来ないかもしれないので、この形式の仕事で未来のためのそのような強力な基盤を築くことは不可能です。



そして、有能な開発者である技術リーダーは、松葉杖で行うか、すぐに宇宙船を建造するかを常に選択する必要があります。



つまり、拡張の余地を残しながら、できるだけシンプルに保つようにしてください。



あなたがそれを非常に簡単に行う必要があるとき、最初のレベルがあります。また、シンプルに保つと、アスタリスクが付いた最初のレベルがありますが、拡張できるように、少なくとも少し操作の余地を残してください。この考え方で、結果ははるかに良くなるように私には思えます。



そして最後に。私はローバーについて、フィーチャーフラグを使用してそのようなプロセスを実行するのが良いと話しました。JavaミートアップのMariaKuznetsovaによる講演を聞くことをお勧めします 。彼女は、機能フラグがシステムと監視でどのように配置されているかを説明しました。