SOA、またはMVCを超えた世界での生活（パート0）

みなさんこんにちは、由良です。
今日は、ソフトウェアの設計と開発の分野での私の経験とアイデアを共有し、偏見を払拭し、「 リアクティブ 」ではない世界のSOAソリューションの現状を明らかにしたいと思います。 より少ないコードの書き方、不満の少ない顧客、白髪、そしてより多くの利益を得る方法について。 副作用のない完全に実行可能なソリューションを実装し、誰もまだそれを行っていない理由。





（ง︡ '-'︠）งそして、ご挨拶。 あまり自由ではなく、あまり時間を与えないことを決めてくれてありがとう。
私はすべてを簡潔かつ明確に述べようとしますが、後者は通常私にとってくだらないことになります。

はじめに

数年前、バックエンドおよびフロントエンドのソリューション（Web、デスクトップ、モバイル）を実装するためのツールが不足しているという問題に出会いました。 その時以来、たくさんの液体が流れてきたので、私は多くの既存のアプローチに精通し、今よりも少しだけ良いことをする方法を考えました。 現在の市場の状況を研究した結果、既存のソリューションではアプリケーションを完全に制御することはできず、プロジェクトアーキテクチャ全体のごく一部に過ぎないダミーであることがわかりました。 彼らの目標は、クライアントや専門家の関心を維持することであり、これはオフィスのコストにプラスの影響を与えます。またはサポートドラッグ-スタッフのサポートとトレーニングをスムーズにする必要があるOASIS仕様のさまざまな変異体を持つ多層ホラーです。 後者の最も顕著な例は、 WSO2スタックです。 私はそれを、市場で最も完全なSOAソリューションであると考えています。 そのようなものをアジャイルの方法論と比較することは困難です。なぜならそれらはすべて、生きている人々のニーズではなく、紙とビジネスプロセスを中心に展開するからです（ アジャイルマニフェストの最初の段落）。 これらの記事では、SOA設計のビジョン、現代の市場とRADの要件に適応させる方法、およびそのようなアプローチの主な利点について説明します。

さまざまなジェット機のトレンドについて議論するのは非常に流行しています。

• レスポンシブ
• 耐障害性
• スケーラブル
• 管理されたイベント（メッセージ）フロー

写真はジェットマニフェストから盗まれます。 スケーラブルでフォールトトレラントがあまりにも人気のある概念であり、MongoDBの時代のようなマーケティング価値を表していないためと考えられます。 これは、いわゆる「関数型リアクティブプログラミング」（FRP）のコンテキストでは特に鮮明です。

実際には、これはすべて投資家の注意を引くための継続的なマーケティングのかすであり、一般に、開発者は既製のソリューションまたはなしでこの「反応性」をすべて独自に実装する必要があるため、ほとんどのソリューションは実用的な価値を表さないことが判明しました既存の要件のベストプラクティス。 完全なAAAでさえ、どこにも見つかりません。

もう1つはSOAです。SOAを使用すると、すぐに動作しますが、どのように動作するはずです。
各ベンダーはチェスと詩人を備えた独自のSOAを備えており、オープンソースソリューションではすべてがうまくいきますが、後で詳しく説明しますが、お互いに友達ではありません。 これはすぐに時代遅れになり、どういうわけか新しいコミュニティはまったく形成されず、プロジェクトは所有者の努力によってのみ開発されます。 これがSOAであり、任意のサービスがプロジェクト全体で少なくとも100500回使用できる場合、使用可能なサービスとドメインの標準化されたリポジトリがないのはなぜですか？ 既存のソリューションの所有者はこれに単純に興味がありません。結局、サポートからお金を浪費する必要があります。

昨年、マイクロサービスは議論するのが特に楽しいです。 これはかなり愚かな名前であり、いくつかのプロトコルの深いカプセル化を暗示しているため、「マイクロ」ではありません。 したがって、単一のサーバーまたは仮想マシン内で「マイクロサービス」を実行するには、遅延を増やしてバキュームを拡大するだけです。 一般に、古典的なSOAでは、サービスが単一のシステムプロセスの一部であるか、それとも異なるマシン上の独自のキューおよびプロトコルを備えた別個のプロセスセットとして起動する必要があるかどうかに違いはありません。これはすべて、サービスとその依存関係を登録するだけの問題です。 それで、私は「マイクロサービス」、また、マーケティング策略にすぎないことを考えます-より多くのお金を得るために明白な古いアイデアを「再考」する試み。

「わかりました、MVCの何が問題なのでしょうか？」-あなたはおそらくそれについて考えるでしょう...しかし、それは単純なグラフィカルインターフェイス用であり、フリルがなく、手に負えないため、平凡なCRUDでも大量のコピーペーストです。 MVCはサブジェクト領域を適切に制御せず、状態の保存とコードの複製を促進し、ロジック（コマンドとリクエストの分離）の役割を十分に分割せず、モデルの非正規化を推奨します。 自転車は別の問題です： ADR 、あらゆる種類のECB 、 クリーンアーキテクチャを備えたEBI 、および六角形アーキテクチャテーマのその他のバリエーション-もちろん、個々の欠陥がないわけではなく、もちろん、誰もがそのようなことを実装する経験とスキルを持っているわけではありませんが、彼らはMVCに固有のかなりの数の問題を解決しました。 このすべては、ほとんどの場合、PHPの専門家によって過去3年間にわたって作成されたものであり、それに応じて何らかの形でこのプラットフォームの機能を反映しています。 PHPが本当に嫌いなわけではありませんが、PythonとRubyのヒープにおける最新のバリエーションは、現代の市場の要件を完全には満たしていません。

ゴールデンハンマーカルトの信奉者の感情を傷つけることはできると理解していますが、なぜすべてがそれほど楽観的ではないのかが明らかになり、このテーマで私が思いついたことを示します。

Fluxもありますが、これもまた別のマーケティング策です。
一般の人々のフラックスは、より複雑な頭字語CQRS-ESに過ぎません。Facebookがそれを単純化したかったからです。そうすることで、ファンのハムスターの注意を引き、繁殖させ、平凡なコミュニティを発展させることができます。これはPRに過ぎません。 Facebookの目標：プロジェクトを実装するための質の高いツールを提供するのではなく、ユーザーのコミュニティにアイデアを伝えて、GitHubでできるだけ多くの松葉杖を彫ること。

すべての「リアクティブ」の基礎であり、「リアクティブ」アプリケーションの実装に最も適しているのはCQRS - ESパターンですが、純粋な形では役に立たないのです。 CQRS-ESの使用上の問題と利点は、SOA設計のコンテキストで最もよく開示されると思います。

現代のSOA、そして実際に既存のすべてのアーキテクチャの主な問題は、ドメインとドメインモデルの定義のかなり貧弱な抽象化です。 同期されたディスクリートFSMステートマシンの観点からこの問題を検討し、アプリケーションの最新の要件を考慮して、ドメインの決定を（冗長性なしで）できるだけ正確に示します。

エヴァンスが言ったように：

問題は、これらのフレームワーク、データベース、キューなど、エンジニアが非常に引き付けるものすべてではなく、主題領域の記述とモデリング（ドメインの作成）に困難が常に隠されていることではありません。

アプリケーションアーキテクチャに関するアイデアを急に変えたいわけではありませんが、〜80％が松葉杖、磨き上げられた象牙、象眼細工で構成されているため、予算が許されるため、これが必要です。そしていいえ：彼らは私たちにお金を払って、それはうまくいきます-なぜ新しいことを学ぶのですか？

「わかりました、読書にうんざりしています。あなたの考えは何ですか？」

最後に、バックエンドとフロントエンドの開発ライフサイクルは次のようになります。


残っているのは、システムにサービスとドメインを追加することによる、設計（オプション）と欠落している機能の実装です。

独自のPocket Firebaseを所有しているかのように、すべての変更と移行をデータベースに自動的に追加するだけでなく、モバイル、デスクトップ、およびWebアプリケーションのスキャフォールディングも生成します。すべてのビュー、テンプレート、検証、プッシュ通知と非同期UIを使用したAPIのクライアント。

現代の機能のほとんどは非常にステレオタイプ化されているため、プロジェクトごとにすべてをゼロから書き直すことは意味がありません。 人々がベストプラクティスを共有し、品質管理と相互作用を標準化できるプラットフォームが必要です。 したがって、製品の品質とそのメンバーの資格を改善するために暗黙的に動機付けられたユーザーコミュニティを取得し、ここに、より高いレベル、実績、および漫画の統計でゲーミフィケーションを追加することができます...まあ、ファンタジーの余地があることを理解しています。

そのようなソリューションを開発するとき、2つの問題のある状況の発生を防ぐ必要があります。これは、「委員会による開発」と「仕様による開発」であり、実際にJ2EEスタックの恐ろしい肥大化につながりました。

現在、開発者の作業を自動化することに興味がある人はほとんどいませんが、既存のアプリケーションのコードのほとんどは、動的プログラミングによって自動的に生成または抽象化できます。

はい...非常に簡潔かつ簡潔に言えば、データベーススキームによれば、お気に入りのAngular'e / React'e / Ember'eなどのフロント用のRESTエンドポイント、クライアントAPI、テンプレートをすぐに生成できます。 最新のブラウザフレームワークのアプローチを実際に消化するわけではありませんが、それについては後で詳しく説明します。 ユーザーグループとその権利を登録し、既存の設計を引き出すことは残っています。 これが神秘主義だと思うなら、 TastypieはモデルからRESTエンドポイントを生成する方法をすでに知っていますが、十分な機能がなく、パフォーマンスが悪いためにPythonでもかなり平凡ですが、例として使用できます。

サービス指向アーキテクチャとは何ですか？

これはアイデアです。 それは、アプリケーションが交換可能な「ブラックボックス」で構成されるべきであるという事実にあります-標準化されたプロトコルとインターフェースに従って互いに通信するサービス。

いくつかの重要な条件、サービスがあります。

• あらゆる条件で実行し、オンデマンドでスケーリングする必要があります
• 直交（疎結合）でフォールトトレラントでなければなりません
• 再利用可能でなければならない
• 状態を保存しない
• できるだけ抽象的であるべき
• 副作用なしに、同時に複数のビジネスプロセスで使用できる必要があります。
• 「オンザフライ」で動的に登録および実装できる必要があります

原則として、最初の3つの条件は多かれ少なかれ明確でなければなりません。 サービスは互いに独立しており、共通のリソースを共有せず、ローカルマシンとリモートマシンの両方のプロセス間で移行できます。 それらは複数のプロジェクトで再利用および同時に使用できます。

状態に関しては、すべてが単純です。サーバーはユーザーセッションに関するデータを保存する必要はありません。これは、実行中のサービスのインスタンス（通常は特定の時間に最小の負荷）で要求を処理できるようにするためです。 これは、ユーザーリクエストに暗号化された「塩漬け」セッション情報を埋め込むことで実行されます。 各リクエストでこのペイロードを送信しないために、通常、ユーザーセッションの短期登録用に別のサービスを作成し、一時的にそれらをキャッシュします。 ユーザーセッションを保存するためのグローバルサービスを作成すると、 コンセンサス問題を解決する必要がある「ボトルネック」が発生します。これは、リクエストの処理速度に非常に悪影響を及ぼします。

抽象化により、すべてが非常にタイトになります。特定のドメイン（基本スキームとロジック）は、依存するサービスとドメインの特定のニーズに応じて動的に拡張可能でなければなりません。 アカウンティングサービスがあり、さまざまなサービスが登録されているとします。一部では、料金の支払いが後払いのみである場合と、前払いが必要な場合があります。 これらのコンポーネントのロジック全体が絶えず変化しているため、ここにさらにさまざまな割引および節約システムを追加し、数か月間品質の頭痛の種になります。 ここでは、リレーショナルモデルの正規化が大きな役割を果たします。長い間、 6つの正規形があったことに注意してください。 サブジェクト領域の適切な抽象化と詳細化により、新しいロジックを導入したり、既存のロジックを変更したりする複雑さが軽減されますが、次のパートではさらに詳しく説明します。

いくつかの「部下」と「マネージャー」間でサービスへのアクセスを共有する可能性は、接続性の悪さや共有状態の欠如の要件に基づいています。 すべては、マルチスレッドプログラミングや「競合」状態を防ぐ方法と同じです。 また、ドメイン拡張の場合にも言及する必要があります。拡張ドメインを複数のサービスと共有する場合、互換性の問題があります。 一般に、大まかに言って、あるサービスが1つの数のフィールドと状態（列挙の値）を持つプレートを必要とし、別のサービスが完全に異なるものを持つ場合、およびこのプレートを共有するときに問題が発生しないように「友達を作る」方法、または他のリソース。

他のすべての人の作業、およびエラー発生時の動作を担当する多くのシステム「ルート」サービスがあります。 それらの1つは、 キャップを登録してサービスの新しいインスタンスを起動し、実装と正確性のテストを実行し、エラーが発生した場合に以前のバージョンにロールバックできるレジストラーです。 Erlang 'eと同様に：3一般に、SOAは多くの点でOTPモデルに非常に似ていますが、多くの点で欠けています。

このメモで、SOAの目的と要件のレビューを完了することができると思います。
必要に応じて、ここに何か他のものを追加します。

これは、サービス指向アーキテクチャの構造を一般的にどのように表現するかを示した図です。


ルートサービスの目的を見てみましょう。

• レジストラ-上記のように、登録とサービスの開始/停止に従事しています。 また、接続用のプロトコルのアドレスと説明を保存し、更新後にサービスの正しい動作を確認し、作業を停止することなく、以前の作業バージョンに自動的にロールバックできます。
• リソースマネージャは最も重要なサービスの1つであり、既存のリソースの使用を調整します。サービスへの物理リソースの割り当て、負荷の分散のための監視を行います。 OpenStackのようなプロビジョニングおよびDevOpsソリューションに基づいて実装できます。 リソースマネージャは、 SOIと呼ばれることがよくあります。
• アーキビスト-イベントを記録し、統計を収集し、レポートを準備するサービス。
• Courier-メッセージの配信とルーティングに従事します。
• 監視者-既存のすべてのサービスのパフォーマンスを監視し、オンデマンドで再起動し、不親切なユーザーをブロックします。
• AAA-これらは3つのサービスを担当します
  
  • 認証-ユーザーの身元の確認。
    これらは、ログイン/パスワード、生体認証、OAuth、ログイン用のSMSメッセージの送信などです。
  • 承認（承認）-ユーザー権利の分離。
    通常、これらは異なるアクションが利用可能な異なる名前のグループです。
  • 会計-支払サービス、当座預金の履歴、割引および貯蓄システムを介したさまざまなサービスの購入/販売。 多くの場合、保管中のさまざまな商品、それらの予約および利用可能性を会計処理するための方法を実装しています。

これらの各サービスには独自の設計（ソフトウェア）機能があり、以下の記事ですべての詳細を説明しようとします。何も見逃さないことを望みます。

すべてのプロジェクトには少なくともRegistrar 、 Archivist 、 Resource Manager 、およびAAAが含まれている必要がありますが、おそらくより良い名前を思い付くことができます。 最後の2つは、拡張可能ドメインの実装の複雑さに関連するいくつかの理由で見落とされています（hi cocaine ）。

既存のソリューションの長所と短所は何ですか？

現在、本格的なSOAはありません。どこかで何かが欠けています。
ハイパーメディアタイプによるコード生成については、一般に歴史は静かです。

私が働いた

• コカイン
• Bluemix
• ボス
• Oracle SOAスイート
• Wso2

もちろん、J2EEスタックの場合、ひどい冗長性が観察され、WSOもJBossも高負荷には適していません。 また、一般に、「弱いバインディング」 は 、最新のパフ化されたj2ee EJBパンにはあまり適していません 。

私は個人的に、CocaineとBluemixは部分的にのみSOAソリューションに関連しています。DIYに満ちた既存のサーバーの相互作用を実装および標準化する既製のシステムはありません。 コカインの場合、 ロケーターがありますが、かなり初歩的なものですが、少なくとも何かがあればいいのです。 Bluemixでは、適切なSOIを実装できますが、少しプレイする必要もあります。 SOIの観点から見ると、Amazonのサービスは最も柔軟です。

すべてのベンダーは、PaaSにのみインフラストラクチャを展開することを提案しています。これは、OracleおよびそのIntegration Cloud Serviceの場合に特に顕著です。 SOAソリューションのほとんどのユーザーはすべてのサーバーが同じデータセンター内にある必要があり、通信の遅延は最小限であることを理解する必要があります-多くの場合、CDNやその他の分散ジャンクを自分で整理する必要があり、追加のベンダーロックインはデータセンターを選択するときに手を縛るだけです。 すでに、AmazonとAzureは落ちました-真面目で責任のある顧客は自分でリスクを管理する方が良いですが、普通の人にとっては十分であり、「彼らは働き始め、 飲んで休んで休みを取り、落ち着くまで待ちます、呼び出しは午前4時に始まります...」、通常95％それが起こる方法をケース。 そして、デジタルオーシャン、リノード、online.net、またはovhで自家製のSOIを使って12枚のはげたデディックを撮影し、必要に応じてそれらをジャグリングする方が安価です。

BPEL / BPMNは別のトピックです：彼らは秘書のビジネスプロセスを記述するための言語を書き込もうとしましたが、標準では提供されていない多くの側面の理解できないものを得ました。言語仕様自体を編集せずに実装することはほとんど不可能です これを行うには、OASISに連絡し、コンソーシアムに参加し、RFCを発行する必要があります...まあ、タスクの解決策と直接関係することはありませんが、許容できる時間枠内で現代の市場の要件に適応できない多面的なモノリシック標準の存在に対する料金のみです。 好きな言語で、すべてを手で取り、書くのが簡単です。 有限状態マシン（FSM）の観点から考えると、ビジネスプロセスの説明を大幅に簡略化できます。

既存のソリューションの主な利点は、蜂蜜で使用するのに十分なベンダーからの保証です。 セクターおよび部分的に外国の状態で。 自動車業界-このような厳しい市場要件はなく、「最新のファッショントレンド」に従う必要もありません。 そのため、新しいプロジェクトの実装、さらにはスタートアップという言葉を恐れず、これらのソリューションとプラットフォームは適切ではありません。

また、本格的なSOAとして、古き良きSAPを検討することもできます。
しかし、サポートポリシー、コスト、継続的な陳腐化、パフォーマンスの低下、セキュリティに対する平凡な態度を考えると、この解決策を検討することすらありません。

現代市場の要件は何ですか？

基本的に、彼らは：

• アプリケーションは非常に大きな負荷サージに耐えることができます
• コンテンツはリアルタイムで更新され、さまざまなデバイスで使用されました
• 長期的なサポートを気にする必要はありません
• 頻繁に新しい機器を購入する必要はありませんでした
• BusFactorは30％を超えていました

原則として、この場合のSOAはほぼ理想的なソリューションであり、遅かれ早かれ、人気のあるMVCフレームワークから開発を開始し、さまざまなメッセージとタスクキューを追加し、プロセス間通信を実装し、開発者はCQRS-ESでバイクからSOAにスライドします ' , .

, , . « » — . SOA «» « » - , «».

?

難しいからです
これをすべて入力するには、DDDおよびエンタープライズアプリケーションテンプレートに関する書籍を数冊読むだけでは十分ではありません。すべてを実践し、たくさんのバンプを埋める必要があります。 »ほとんどの既存のOpenSourceプロジェクトでは実装されていないため、独自の基盤とすることはできません。

SOA IPC , Discovery (). « » Symfony2 Meteor.js — , , - scaffolding, . - Gearmand / Beanstalk / RabbitMQ etc - - SOA. , , AMQP — OASIS'a . protobuf'a, .

App Data over Avian Carriers with Quality of Service
XMPP , BOSH « ejabberd! erlang! !». - , 20% . IP UNIX - IP , .

Scaling /dev/null
" , Go ". «And we've never had another colossal clusterf**k since». , : 100% — . C#/Java . — bytecode enhancing . , DataNucleus - Hibernate . — , , , — , -, . Rust'e — , Go ( «duck typing»).

, , .

, MV--- ?

私が対処しなければならなかったプロジェクトの80％には、通常の正規化されたリレーショナルモデルがありません。最初のステップは、モデルを6番目のフォームまで正規化し、タブレットと列に名前を付けるための読み取り可能なルールを受け入れることです。

なぜなら

• ほとんどのリクエストを高速化できます
• 冗長性を防ぎ、ベースのサイズを削減する
• ソリューションのサポートとドキュメントを簡素化します。
• 既存のCRUDロジックの実装を簡素化

複雑で大規模なクエリの場合、実体化された表現を使用する価値があります。これにより、プロファイラの時間を少し節約できます。モデルの非正規化について考える前に、一時的な表現に中間結果を保存することを考えてください。

正規化されたデータベースを使用すると、CRUDに対してこのようなルーターを発行できます。

GET /plural($tableName) //     GET /plural($tableName)/page/$pageNumber //     GET /plural($tableName)/page/$pageNumber/size/$pageSize //       GET /plural($tableName)/where/$fieldName/$value //         GET /$tableName/$id //    $id GET /$tableName/$id/plural($referencedTableName) //         $id POST /$tableName/$id //    ID PUT /$tableName //    PUT /$tableName/$id/$referencedTableName/$referenced_id //      ManyToMany  DELETE /$tableName/$id //    $id DELETE /$tableName/$id/$referencedTableName/$referenced_id //      ManyToMany  

折り畳まれたキーの場合、$ id1_id2_id3（任意）のようなものを考えることができます。たとえば、アルファベット順でキー列を取得します。 もちろん、最初にデータベーススキーマを読み取り、それを使用してルーターを検証する必要があります。そうしないと、ブラインドSQLインジェクションが大量に発生します。

さて、テスト、テスト、プロファイリング、テスト実行時間の短縮、リファクタリング、再度テストを行います。

前述のTastyPieは同じ原理で動作します。

OK、JSフロントエンドはどうですか？

JSフロントエンドでは、私はまだ何をどこで理解していないのですか。
一方で、あらゆる種類の標準、プリプロセッサ、ポストプロセッサが非常に多くありますが、一方で、それらは開発をまったく単純化しません。 既存のソリューションのほとんどは、テンプレートを複製してブラウザに転送する必要があります。その後、手でEventSourcingを整理し、JSでモデルを部分的に複製し、検証を実行する必要があります。

多くの場合、既存のツールの開発を外部から観察すると、遠くに行くほど難しくなり、実際の問題の解決にますます集中していないという印象を受けます。 同時に、既存のすべてのフロントエンドプロジェクトは非常に多くの投資を集めており、数千万のU. Dmurdish e-cuについて話し、自分自身に注目を集めようとしています。

これまでのところ、ノードに「同形」レンダラーを使用してReact.jsを停止していますが、かなり気分が悪くなります。 ここでの問題は、通常のUXの場合はサーバーとクライアントの両方でレンダリングする必要があり、 prerender.ioのようなさまざまなWebキットのサロゲートには正常なパフォーマンスがないことです。

私は、最近のJSフロントエンドが他の環境で特にレンダリングされないという理由だけで、node.jsをスカルプトしない理由を本当に理解していない人の1人です。 ここでは、原則として、jsonでhtmlを追い抜くことを妨げるものはありません。Webソケットとロングポーリングを介して、リンクをクリックするときに、テンプレートと変更をページに転送します。 次に、「パッチ」を現在のDOMツリーに適用します。ページ上のルーティングやモデルを気にする必要はありません。フォームを検証するためのルールは、data- *属性と正規表現で記述できます。 コレクションとテンプレートのすべての変更はサーバー側で既に追跡され、レンダリングされたパッチを送信できるため、VirtualDOMはすぐに必要ありません。

まあ、一般的には、おなじみのjinja / twig'ahや他のctppでテンプレートを作成し、ページごとに1つのJSとコレクションを管理するための専用コントローラーを追加しました。 確かに、そのようなことは、EventSourcingが利用可能な場合にのみ（プッシュ通知で）完全に機能します。 したがって、ブラウザの側からモデルとビューを複製する必要はありませんが、これは非常に大きな作業です。 アイデアが明確であることを願っています。

テンプレートエンジンからHTMLページを同様のJSONとして転送できます

 { "action": "append|remove|replace", "selector": "#HaveANiceDay", "tagName": { // optional "attrs": [ { "name": "value" }, "name", ], "content": { {"otherTagName": { ... }}, }, }, } 

この方法でブラウザベースのテンプレートおよびコレクション管理を実行する最新のMVCフレームワークの一部として、JSフロントエンド用の既存のツールを知りません。 コレクション管理とESはすでにMeteor.jsにありますが、例外である可能性が高く、Yandexはどこかに似たようなものを持っていました...

わかった これは紹介には十分です。

私はそれがあまりにも退屈ではないことを願っています、私は何か新しいことを話し、あなた自身のために考えるように促すことができました。
楽しい時間をお過ごしください。

必要に応じて、ここに何かを追加し、エラーを修正して明確にします。
すべてのコメントは午後に送信されますが、コメントを散らかさないでください。