単純なプログラムの予想外の複雑さ

プロジェクトの複雑さの評価が発表されたとき、何度も驚きました。「なぜそんなに長いのですか？」、「はい、その場で、1回、2回、完了です！」、「Xを取得してYに貼り付けるだけです。 ！」プログラマーは、コードの記述とデバッグに費やされた時間として期限を評価することに慣れていますが、大規模なタスクにはさらに多くの時間がかかります。





実際には、氷山はほとんどのストック画像のように垂直ではなく、水平に水中に配置されていることをご存知ですか？



ただし、分析、下位互換性のサポート、A / Bテストなどの従来のエンタープライズガジェットの束を忘れて、実装された機能に直接関連するコードだけに焦点を当てたとしても、その複雑さが制御不能になることがよくあります。



この記事では、問題の説明から実装の詳細まで、同僚と私がJoomでさまざまな時期に実装したいくつかの機能について説明し、一見単純に見えるものが、多くの開発を必要とする複雑なロジックのもつれに簡単に変わることを示します。反復。

ユーザーによる検索

Joomアプリの大きなセクションの1つは、内部のソーシャルネットワークです。ここでは、買い物客が商品のレビューを書いたり、評価したり、話し合ったり、お互いに登録したりできます。そして、ユーザー検索のないなんとソーシャルネットワーク！



もちろん、検索はそれほど簡単な作業ではありません（少なくとも私の前の記事の後 ）。しかし、私はすでに必要な知識をすべて持っていました。joom-mongo-connector



また、必要に応じて追加データを調整したり、その他の後処理を行ったりするために、コレクションからMongoDBにデータをElasticsearchインデックスに転送できる既製のコンポーネントもありました 。タスクは非常に単純に聞こえました。



仕事..。ソーシャルネットワークユーザーによる検索用のバックエンドを作成します。フィルタは必要ありません。サブスクライバーの数で並べ替えると、最初に実行できます。



さて、それは本当に簡単に聞こえます。socialUsers



YAMLで構成を作成することにより、コレクション からElasticsearchへのオーバーフローを構成します。バックエンドでは、商品検索APIと同様のAPIを使用して新しいエンドポイントを追加しますが、これまでのところ、フィルターと並べ替えはサポートされていません（リクエストテキストとページ付けのみが残ります）。ハンドラーで、Elasticsearchクラスターに簡単なリクエストを行います（主なことはクラスターを間違えないことです！）。その結果から、ユーザーに応じて、見つかったドキュメントのID（ユーザーID）を取得します。次に、クライアントJSONに変換し、個人情報を詮索好きな目から隠して準備を整えます。か否か？



私たちが最初に遭遇した問題は音訳でした。ユーザー名はソーシャルネットワークから取得され、ロシアのユーザー（当時は大多数でした）がラテン語で書くことがよくありました。あなたはマッドを見つけようとします、そして彼はマッドのフェイスブックにいます、そしてそれはそれです-彼は結果にありません。同様に、IvanはIvanを見つけることができませんが、私は非常に見つけたいと思います。



これが最初の問題です。インデックスを作成するときに、音訳のためにMicrosoft Translator APIにアクセスし、姓名の2つのバージョンを保存し始めました。一般的なインデックス作成コンポーネントは、音訳クライアントに依存し始めました（現在も依存しています）。



さて、あなたの母国語がロシア語であるかどうかを予測するのは簡単ですが、他のヨーロッパの言語にも存在する2番目の問題-小さな形と名前の略語。 IvanがFacebookで自分自身をVanyaと名付けることにした場合、Ivanの要求は、あなたがどれだけ音訳しても、彼を見つけることができなくなります。



したがって、次の厄介な問題は、Gramota.ru（Nikandr Aleksandrovich Petrovskyのロシア名の一意の辞書から）で小さな名前のインデックスを見つけ、それをハードコードされたプレート（約2000行）としてコードベースに追加し、インデックスになっただけではないことでした名前とその音訳だけでなく、すべての小さな形が見つかりました（面白い事実：英語ではそれらに人名の短縮形という用語があります）。ユーザー名のすべての単語を取得し、控えめなスプレッドシートで検索しました。





Joomコードベースの公証されたスクリーンショット。 2018年頃。



しかし、その後、ロシア語を話さない世界全体に不均一な層で分散しているユーザーの残りの半分を怒らせないために、私たちはJoomの国のマネージャーに叫び声を上げ、国の略語の参考書を見つけるように依頼しました彼らの国の名前。学術的でない場合は、少なくともいくつか。また、一部の言語では、複合名を持つ伝統（Juan Carlos、Maria Aurora）に加えて、2、3、または4つの単語が1つに短縮されていることが判明しました（MaríadelasNieves→Marinieves）。



この新しい状況により、一度に1単語ずつ検索する機会が失われました。次に、単語のシーケンスを任意の長さのフラグメントに分割する必要があります。さらに、パーティションが異なれば、略語も異なる可能性があります。私たちは言語学の奥深くに飛び込み、生きているスペイン人がそれを省略したようにスペイン語の名前を省略した人工知能を書きたくなかったので、私たちはスケッチし、クヌートを許し、組み合わせのやり過ぎを許しました。



また、組み合わせ検索では常にそうであるように、ユーザーの1人にバーストが発生し、生成されるスペルの最大数の制限を早急に削減する必要がありました。これによりコードがさらに複雑になり、このタスクでは予想外に困難になりました。

商品の機械翻訳

タスク。販売者から提供された商品の名前と説明を英語でユーザーの言語に翻訳する必要があります。



おそらく誰もが中国の商品の名前の曲がった翻訳についてのミームを見たことがあるでしょう。私たちはそれらも見ましたが、市場投入までの希望の時間では、翻訳に既存のAPIを使用するよりも優れたものを思いつくことができませんでした。



HTTPクライアントの作成、アカウントの作成は簡単で、商品がユーザーに発行されるときに、デバイスの言語に簡単に翻訳できます。しかし、翻訳は安くはなく、同じ人気のある製品を数万回の視聴ごとにロシア語に翻訳するのは無駄です。そのため、キャッシュをオンにしました。製品ごとに、翻訳をデータベースに保存し、そこに翻訳がある場合は、翻訳者に移動しなくなりました。



しかし、節約の可能性はまだありました。翻訳の品質と価格の間の合理的な妥協点は、文章の説明を打ち負かしてキャッシュすることであると判断しました。結局のところ、同じテンプレートフレーズが製品によく見られ、毎回翻訳するのは無駄です。これが、トランスレータに別の抽象化レイヤーが表示された方法です。HTTPクライアントと、商品全体をさまざまな言語で保存するキャッシュの間のレイヤーであり、テキストをフラグメントに分割します。



もちろん、リリース後、翻訳の品質に悩まされ、より高価な翻訳者を使用するとどうなるでしょうか。しかし、それは私たちの特定の歌詞に良いでしょうか？目で比較することはできません。A/ Bテストを行う必要があります。そのため、翻訳キャッシュには、製品IDに加えて、翻訳者IDが表示され、ユーザーが所属するA / Bテストグループに応じて、翻訳者IDからの翻訳をリクエストし始めました。



親愛なる翻訳者はうまく機能しましたが、それでもすべての製品で実行するには無駄が多すぎました。しかし、私たちは、主要な翻訳者の対応が非常に悪かったため、立ち上げを成功させるために分岐する準備ができている国に行きました。そのため、翻訳者を選択するロジックはより複雑になりました。



次に、プラットフォーム上の一部の店舗が非常に優れており、プラットフォームが成功を応援しているため、より高価な翻訳者で商品を翻訳する準備ができていると判断しました。そのため、翻訳者を選択するロジックは、ユーザー、国、およびストアIDに依存し始めました。



そして最後に、Joomが存在してから数年の間に、メインの翻訳者が改善できると判断しました。おそらく、翻訳キャッシュを一定の間隔で更新することは理にかなっています。しかし、A / Bテストなしではどうでしょうか？そのため、鮮度フィールドがキャッシュに表示され、事態は再び複雑になりました。その結果、私たちの翻訳コンポーネントは非常に複雑であり、これは、自家製の計算言語学をまだねじ込んでいないにもかかわらずです。今のところ。

服のサイズの変換

おそらく、オンラインで洋服や靴を購入する際の最も苦痛な問題の1つは、適切なサイズを選択することです。そして、地元の倉庫から配達されたときに、ラモダのようなプレーヤーが一度に複数のサイズを持ち込み、同じように簡単に不適切なものを取り戻すことができる場合、これは国境を越えて機能しません。小包は時間がかかり、1キログラム余分にかかるコストが高く、送信者は大量の受信メールを期待していません。



さらに、問題は、異なる国の売り手がサイズについて完全に異なる考えを持っているかもしれないという事実によって悪化します。中国のMは簡単にロシアのXSであることがわかり、恐ろしい9XLはXXLとそれほど変わらないかもしれません。ステッチされたユーザーは測定値に依存する必要がありますが、それでも常に正しいとは限りません。たとえば、ユーザーは人の胸の周囲が示されることを期待し、売り手は服自体の測定値を示します-それらは5〜10パーセント異なります。ユーザーがJoomで買い物をするのにそれほど煩わされることを望まないのです！



タスク。売り手から提供されたサイズの代わりに、胴回りに基づいていくつかの単一のテーブルから計算したサイズをユーザーに表示します。



はい。製品の説明から解析したサイズのテーブルを取得し（これは5kラインの別の宇宙船によって行われます）、別のフィールドに格納され、その中のサイズを計算されたものに置き換えます。インターネットで見つけた、胴回りをサイズに変換するためのテーブルをハードコーディングして、人生を楽しんでください。



ただし、テーブルがないか、テーブルに十分な行がない場合、これは機能しません。この機能は、製品で暗黙的に無効になっている回数です。



うーん、表では人体の胴回り、そしてほとんどの売り手は物自体を測定することによってそれらを示しています。差分係数の縫製。完璧なM-kiの幸せな所有者であるプロダクトマネージャーのロディオンは、モールに行き、自分でさまざまなものを測定し、係数を付けます-それらは似ていますが、商品のカテゴリごとに大きく異なります。ラップアラウンドタートルネックの場合、差はほぼ0％で、セーターの場合はすべて10％です。また、アウターウェアのフィット感はさまざまです。スリムフィット、ノーマルフィット、ルーズフィットで、±5％のスイングが得られます。現在、私たちの係数（Rodionの係数としてコードで不滅化されています ）は2つの要素で構成されています。



着陸を決定するために、製品の名前または説明から着陸を抽出しようとする別のパーサーを作成します。製品がRodionによってチェックされたカテゴリのいずれにも該当しない場合、機能は暗黙的に無効になります。



最後の仕上げ：多くの製品が脇の下から脇の下までバストをリストしています。つまり、胴回りの半分しかなく、途方もなく小さいサイズになります。胴回りがX未満の場合、これは不可能であり、これは明らかに胴回りの半分であるというロジックを追加し、2を掛けます。大人は通常、胸囲の2倍の差がないのが良いでしょう。



現在、すべてが非常に複雑であるため、管理パネルで製品の種類ごとに機能をテストするときに、機能がオンにならない、または何らかの方法で機能しない理由を理解することは不可能です。コードにロジックの大きなレイヤーを追加し、変換をオフにする理由を詳細に記録します。特定の製品のシャットダウンの原因を完全に追跡できるようにするには、エラーメッセージを上向きに転送し、詳細を数回増やす必要があります。コードは恐ろしいものになります。



もちろん、A / Bテストのグループによって動作が異なります。

結論

締め切りについて楽観的な寄付開発者であるDanaansに注意してください 。どんなに簡単に聞こえても、開発時間を見積もるのは非常に難しく、あらゆる段階で驚きが待っています！