1C-Bitrixプラットフォームに基づいた高負荷のオンラインストアのアジャイルな設計、開発、立ち上げ-4ヶ月

こんにちは、同僚！
今日は、1C-Bitrixプラットフォーム上で、非標準機能を備えた非常に負荷の高いオンラインストアを非常に短時間で設計および起動する方法を説明します。

発行

将来のプロジェクトの1ミリごとを説明する大規模なオンラインストアを正式に開発するタスクに取り組むと、数千枚ではないにしても数百枚、数十枚の図表や画面フォームでTKが得られます。 そして、あなたはそれを書くでしょう、たぶん、少なくとも6ヶ月...私たちのうちの5人は、仕事で夜を過ごします。 しかし、最も「恐ろしい」ものが先にあります-最終的に厳addに追加し、膨らんだ目でそれを発表すると、プロジェクトの要件が変更される可能性が非常に高くなります。彼らとあなたなど そして、あなたは緊急に10人の筆記者を無限に雇わなければなりません:-)

一方、TKが週末に10ページの小さなページで書かれていて、誰もが同意すれば...読むことなく、あなたは開発チームに落ち着いて、驚くべき頭脳ブレーキの質問に対する要件と回答を指定する必要があります。マシンゼロのエラーを考慮に入れて、製品の代金を支払う場合。」 ほとんどの場合、1週間以上は続かず、プロジェクトは表示されません。
設計に1か月、プログラミングに3か月かかり、開発チームに落ち着きたくなく、誰かが既にプロジェクトの開始日を公表している場合はどうすればよいでしょうか？ :-)

マクロ言語で技術的なタスクを作成します

まず、プログラマーだけでなく、才能のあるシステムおよびビジネスアナリストも長年1C-Bitrixプラットフォームに取り組み、その経験を活用していることを理解してください！ 幸いなことに、電子商取引の最も複雑で理解しにくい問題は長い間かみ砕かれ、ロシアの現実に適応し、1C-Bitrixプラットフォームのモジュールに認識しやすいように簡単な概念に分解されました： 「オンラインストア」 、 「トレードカタログ」 「通貨」
それはあなたのために残っています：
1）これらのモジュールの内部ロジックと用語を理解するのは良いことです。 これが重要なポイントです。 週末を過ごすことができます、それは価値があります。
2）公に発表されたオンラインストアを取得するために追加する必要のある小さなブロックを確認します。
3）1C-Bitrixプラットフォームの用語で短いが容量のあるTKを記述します。プラットフォームの標準ドキュメントへのリンクと、高度/非標準機能の説明を含む詳細なブロックが含まれます。 ボリューム-まあ、最大20〜30ページおよび5〜10ページの図。
4）TKとその迅速な実装を理解するために開発チームを準備するには、このために、同僚は開発者向けの無料コースをすばやく「ポンプ」する必要があります。
5）プロジェクトサービスチーム（マネージャー、コンテンツエディター、管理者）を準備し、効果的な作業のためにそれらを「ポンプ」する。
はい、はい。 重要な問題が残っています-1C-Bitrixプラットフォームで開発を開始し、突然実装できず、別のプラットフォームですべてを書き直す必要がある複雑な機能が表示されたらどうなりますか？ 私を信じて、あなたはそのような恐怖を持っている最初の人ではありません-そして、同様のタスクは、以下の技術によって、長い間、非常にうまく解決されています：
1）プラットフォームアーキテクチャの簡素化とモジュール化のための絶え間ない闘争。 1C-Bitrixのアーキテクチャは非常にシンプルで直感的に論理的であるため、想像力とトップダウンのビジネス要件の創造的な飛行を妨げるものは何もありません-空気は移動を妨げますか？ 個人的には、プラットフォームコアの書き換えを必要とするオンラインストアのビジネス要件を満たしたことがありません。 信じられないかもしれません。
2）プラットフォームのビジネスロジックを拡張する標準メカニズムは、再定義されたイベントハンドラーとカスタムモジュールです。 多くのオブジェクトから3階建ての継承を行うよりも簡単だと信じています。
また、プロジェクトの開発とサポートを外部委託することもできます。たとえば、 認定アフィリエイトネットワークのサービスを使用すると、インターネットプロジェクトの開発/サポートプロセスの独立組織のリスクを大幅に削減できます。 要件を収集して、それらを開発者に届けるだけです。

ツール

TKはMicrosoft Wordなどで作成できますが、効果的なチームワークツール-wikiを使用して作成することをお勧めします 。 誰でもテキストを編集でき、誰がいついつ編集したかが明確です。 当社の企業ポータルを使用する場合、プロジェクト用に作成されたワーキンググループの wikiにTKを書くことができます。
また、便利なwikiがredmine 、 trac 、 confluence製品などで利用可能です。

目次

TKのオンラインストアの主要な機能を、拡張可能な標準機能から収集して説明します。

製品カタログ構造と製品特性

あなたが持っているディレクトリを確実に決定する必要があります。 製品カタログには「リンゴのある木」が用意されていることもあれば、異なるパラメーター（生産者、新製品、販売）でフィルタリングできるフラットリストである場合もあります。情報の提示。 カタログのすべてのページのインターフェイスのプロトタイプをToRのこのセクションに挿入することをお勧めします。画面フォームの大まかなドラフトは、カタログのロジックを理解するのに役立ちます。
通常、1C-Bitrixプラットフォームでは、カタログは1つの情報ブロック全体に配置されるか、一般的な説明を含む商品のツリー構造が1つの情報ブロックに格納され、特定の価格オファー（多くの場合SCUによって識別されます）は別の（それらの）情報ブロックに格納されます。
あなたまたはあなたの同僚がUMLに精通している場合、ディレクトリの本質を適切な図に反映し、それらの間の論理的な関係を書き留めることはしばしば有用です。

プロジェクトの運用中の高いワークロードに関連するリスクを最小限に抑えるために、1C-Bitrixプラットフォームの開発者がドラフトレイアウト（労働：1日または2日）ですばやく作成できるプロトタイプのディレクトリ構造を試すことをお勧めします。 そして、予想される量のテストデータをカタログに入力してから（そして2回を超えることをお勧めします）、カタログアーキテクチャの最終決定を行い、それらに対する典型的なクエリの速度と性質を測定します。
多くの場合、ディレクトリを機能させるためには、メーカー、色、車両の種類などの追加の参考書が必要です。 -カタログ内の商品に関連付けられるすべて。 ここにリストします。
結果：
TORのこのセクションでは、以前にスクリーンフォームのスケッチを作成し、技術的なプロトタイプを作成し、実際に近いテストデータのボリュームでカタログアーキテクチャをテストしたことにより、プロジェクトのカタログ構造とプロジェクトの商品のプロパティを熟考して説明しました。 時間があります-そしてプロトタイプでYandex.Marketスタイルのカタログを作成してテストすることもできます-しかし、発売までに3ヶ月が残っています。

カタログ内の商品の価格設定、通貨

最も単純なことは、製品に1つの価格=数があることです。 バイヤーのタイプに応じて価格が変化すると、より困難になります。普通の人にとっては価格は1つであり、パートナーにとっては別です。 さらに興味深いのは、価格をカタログで異なる通貨で設定でき、購入者の出身地に応じてストアの通貨に変換する必要がある場合です。 また、製品の価格が購入数量に依存することもあります。 そして、すべてが一緒になったら...
幸いなことに、前述の機能は1C-Bitrixプラットフォームのトレーディングカタログ （およびその他の多くの便利な機能）で提供されています。 ただし、カタログでより複雑な価格設定ロジックが必要な場合、たとえば、価格が購入者の誕生日*注文金額までの日数に依存する場合、 イベントハンドラを再定義することでいつでも解決できます 。
TKのこのセクションに数式がよく表示されます。 これとTORの次のセクションを会計士と書くと便利です。
結果：
おそらく、ロシアの現実に適応した、必要な価格設定ロジックと通貨のほとんどは、すでに1C-Bitrixプラットフォームに実装されています。 ただし、開発者によく知られている標準のプラットフォーム拡張メカニズムを通じて、必要なものをいつでも追加したり、その動作を変更したりできます。

顧客の注文プロセス

画面フォームをレンダリングすることにより、顧客が製品を購入する方法を説明します。 疑わしい場合は、標準の1C-Bitrixプラットフォームのオンラインストアをインストールするか、 仮想ラボでプレイして、その操作のロジックを調べてください。 多くの場合、製品はバスケットに事前に追加され、注文ウィザードに従って実行されますが、注文の支払いを購入者の個人アカウントから行い、デフォルトで購入者のプロファイルのデータを代用するなど、「クイック」購入をワンステップで手配することもできます。
バイヤーは個人と法人に大まかに分けられますが、場合によってはより多くの種類が必要になることを忘れないでください。 バイヤーの各タイプは、注文時に通常異なるデータを入力します。たとえば、法人はTINなどを入力できます。 TORのこのセクションは、弁護士と連携するのに適しています。
注文が行われると、それについてクライアントに通知するだけでなく、繰り返し注文で将来使用するために入力したデータをプロファイルに保存する必要もあります。 また、クライアントは、個人セクションで生成された注文を表示し、それらを繰り返してキャンセルできる必要があります。
買い手が、たとえばスクラッチカードで補充された個人アカウントから注文の支払いを行える場合、しばしば便利です。

結果：
注文プロセスを描いて説明しました。 これにはUMLアクティビティ図を使用すると便利です。 このプロセスを実装するために必要なものの多くは、1C-Bitrixプラットフォームですでに利用可能です。 注文プロセスのビジネスロジックを拡張する必要がある場合は、標準のプラットフォーム拡張メカニズムを使用していつでもこれを行うことができます。

マネージャーの注文プロセス

このプラットフォームには、カタログ、顧客の注文、個人アカウント、割引、税金などを操作するための標準的な管理インターフェースがあります。 -大半のインターネットプロジェクトに適しています。 注文を処理するだけでなく、各従業員が注文に対して特定の操作を実行し、1人がクライアントにダイヤルして注文を確認し、もう1人が注文の支払いステータスを設定し、支払いの詳細を入力する、企業に合わせたビジネスプロセスに従って「実行」することもできますドキュメント、3番目は宅配便サービスなどとやり取りします。
多くの場合、店舗注文の処理に関連するバックオフィスビジネスプロセスは、状態図に反映されます。 これにより、企業の複雑なプロセスをより明確かつ正式に反映し、知識を開発者に大々的に伝えることができます。

結果：
可能性のあるステータス、従業員の権利、およびステータス間の切り替えの可能性を判断するために、注文の「ドキュメント管理」技術の機能を使用して、オンラインストアのバックオフィスのビジネスプロセスを設定します。 また、標準の管理者を通じて、他の多くのディレクトリおよびストアエンティティを管理します。

決済システムと配送サービス

原則として、オンラインストアは限られた支払いシステムと配送サービスで起動され、必要に応じて追加されます。 1C-Bitrixにはこのカテゴリの多くの組み込みオブジェクトがあり、 非標準の支払いシステムと配信サービスをいつでもすばやく追加できます 。

専門の管理セクション

注文管理パネルなど、プラットフォームに組み込まれた管理セクションが、特定のタスクを解決するのに完全に適していない場合があります。 この場合、追加のプログラミングコストのため、必要な機能を備えた独自の管理セクションを作成できます。 ひそかに-3か月以内に開始する必要がある場合は、カスタム管理パネルを作成しないようにしてください-訪問者がアクセスできるサイトの部分の使いやすさをよりよく考慮してください:-)
結果：
プロジェクト固有の管理者は、任意の数量で追加できます。 しかし、多くの場合、「with the head」には標準の管理領域がありません。

役割と権利

このセクションでは、TKはストア内で誰がどのような権限を持ち、どの操作を実行できるかについて説明します。 たとえば、コンテンツエディターはニュースを追加してページを編集し、会計士は注文などの支払いステータスを記録します。 他のシステムからの情報がカタログに自動的に入力される可能性があります-この操作のみの権限を持つ特別なアカウント/グループを作成します。 この情報をUseCasesチャートの形式にフォーマットすると便利です。

負荷に対するシステム抵抗

このセクションでは、TKはオンラインストアのストレステストを実施するための方法論について説明します。これに時間がある場合は、ターゲットについて説明します。 例：
1）テストデータは、予想に近い量でシステムに注入されます。 たとえば、1,000,000件の注文、200,000件のカタログアイテム、2,000,000件のユーザー。
2）インターネットプロジェクトの負荷は、たとえばjmeterなどを使用してエミュレートされます。
3）ロードツールは各ヒットの情報を記録します。
システムは1日あたり1,000,000回のヒットに耐え、平均ページ取得時間は0.5秒で、エラーの割合（50 *）は1％未満である必要があります（システム管理者はエラーの数を0に減らすよう努める必要があります）。

その結果、短くて効果的なToRが得られます。ToRでは、一方で、1C-Bitrixプラットフォームの詳細なオンラインドキュメントへの多くのリンクがあり、他方で、インターネットプロジェクトに固有の詳細なタスクがあります。 さらに、機器の選択と構成、コードの最適化、およびキャッシングにより、実装中に達成する必要があるソリューションターゲットをすぐに決定します。 TKには、プロジェクトの詳細のみが含まれており、プラットフォームの膨大な技術文書に依存しています。

評価と開発

1C-Bitrixでのプロジェクトの実装は通常、次のシナリオに従います。
1）プラットフォームのインストール-分
2）テンプレートの統合、マルチサイト構成-通常、レイアウトがある場合は、日
3）標準要素の統合-ニュース、サイトマップ、メニュー、サイト検索など-通常1〜2日で完了
上記で準備したTKは、できれば開発者または専門家のチーム（ PlanningPokerを試してみてください）の関与により、 コンポーネントに分割されます 。 典型的なプロジェクトは数十個のコンポーネントです。 多くの場合、プロジェクト用にコンポーネントを作成するのではなく、標準コンポーネントを変更する方が高速です（プラットフォームディストリビューションには何百もの既製のコンポーネントがあります）。

コンポーネントを機能させるには、情報ブロックを構成する必要があります-これは、データベース上の1C-Bitrixプラットフォームの抽象化です。 通常、約1日かかります。
4）コンポーネントが評価されます。 プログラマを集めて、1〜2日かけて評価し、議論することをお勧めします。 この段階で、受け取りたいものをどれだけ理解しているかを確認します-開発者のすべての質問に自信を持って答えて発言できる適切な見積もりを取得するか、特にタスクを理解していない開発者（自分で理解していない場合）が見積もりを提供します（おそらく圧力の下で:-)）「懐中電灯から」そしておそらくあなたは時間通りに始まらない。
5）コンポーネント開発。 これは通常、プロジェクトの最初のリリースのライフサイクルで最も長いフェーズです。 中程度の複雑さのコンポーネントは、ほぼ1人の開発者によって実行されます。 通常、コンポーネントは複数の開発者が並行して作成できます。

6）権利の設定。 ユーザーとロールが作成され、システムとプロジェクトでの権限がチェックされます。
7）機能テストと受け入れテスト。 テスターとユーザーは、プロジェクトを「呼び出す」ことで機能をテストします。 バグが修正されました。 単体テストが必要な場合-書きますが、ほとんどの場合、残り時間はありません。
8）負荷テストの準備と実施。 プロジェクトの負荷が高い場合は、Webクラスターを構成することをお勧めします 。 経験から、最も弱いハードウェアで開発およびテストすることをお勧めします。強力なハードウェアでは、開発の質の低さをすぐに評価できないかもしれません。

コンテンツ充填

なぜなら 前の段階で、役割と権限が構成されたため、コンテンツエディターはシステムに情報を入力し始めることができます。 ディレクトリとカタログもインポートされます。 最初に上記のコースにコンテンツ充填に関与する従業員を送るのが最善です。さもないと、彼らはせいぜい質問であなたを攻撃し、最悪の場合、彼らはプラットフォームがバグだと言うでしょう。 彼らは成功しません。

ホスティング、プロジェクト展開の選択

条項8の負荷テスト中に取得した要件を考慮して、 認定ホスティングを選択することをお勧めします。 Webクラスターで作成された負荷の高いプロジェクトの場合、クラウドプロバイダーの人気の高まりに注意する必要があります。 強力な管理者がいる場合-専用サーバーを使用し、そうでない場合は、外部管理を注文します。

プロジェクトサービス

プロジェクトを運用した後、システムのカーネルが定期的に更新されていることを確認してください（開発中に品質統合の要件に違反し、カーネルが変更されることがあります-これは更新後にプロジェクトの中断につながるため、アドバイス-プロジェクトを毎日更新することを強制します）、およびプロジェクト自体監視され 、システム管理者はサイトを訪れる前に起こりうる問題を発見しました:-)

おわりに

数か月間、負荷の高いオンラインストアを実装するために、数百の図を含む1000ページの巨大なToRを記述する必要はまったくありません。 多くの場合、プロジェクトマネージャーは、1C-Bitrixプラットフォームのインターネットショップおよびトレードカタログモジュールの機能を調査し、TORの特定の非標準タスクのみを反映し、「標準1C-Bitrixドキュメントを参照」の精神で残りのセクションに記入するだけで十分です。 原則として、ほとんどの場合、プラットフォームのオンラインストアの標準機能を変更するには、イベントハンドラーを再定義する技術を使用すれば十分であり、独自のモジュールを作成することはほとんどありませんが、これは簡単です。 負荷がかかった状態でプロジェクトのパフォーマンスが低下するリスクを減らすために、「戦闘」に近いデータ量で事前に負荷テストを実施することをお勧めします。

「1C-Bitrixプラットフォームで開発を開始し、突然、実装が不可能で、すべてを別のプラットフォームで書き直す必要がある複雑な機能が表示されたらどうなるでしょうか」という質問に最初に悩まされることはありませんか？ この記事で説明しようとしたように、このクラスのタスクは長く、正常に解決されました - 恐れる必要はありません 。

頑張って

統合および実装品質管理1C-Bitrixの責任者-Alexander Serbul