コードアーキテクチャ

この記事では、コードの適切な編成（アーキテクチャー）に関連する個人的な経験を共有したいと思います。 適切なアーキテクチャにより、長期サポートが大幅に簡素化されます。

これは非常に哲学的なトピックなので、主観的な分析と経験しか提供できません。

問題、症状

プログラマーとしての私の最初の経験は非常にクラウドレスでした-私は問題なく名刺のウェブサイトをリベットしました。 彼がコードを書いたのは、私が今「インライン」または「キャンバス」と呼んでいるからです。 少量で簡単なタスクでは、すべてがうまくいきました。



しかし、私は仕事を変えて、4年間1つのWebサイトを開発しなければなりませんでした。 当然、このコードの複雑さは、私の以前の仕事からの名刺と比較できませんでした。 ある時点で、問題が私に降り注ぎました-回帰の量はスケールから外れました。 私はまるで歩いているような感覚がありました。「ここ」を修復しながら、「そこ」を壊しました。 そして、この「ここ」と「そこ」の角質が場所を変え、円が繰り返されました。



私は自分が状況をコントロールしているという自信を失いました-バグを防ぎたいというすべての願望で、彼らはスキップしました。 この4年間、プロジェクトは積極的に開発されました。既存の機能を改善し、拡張し、完成させました。 新しいリファクタリング/改良のそれぞれの単位コストがどのように増加しているかを見て、感じました-コードの総量が増加し、それに応じて編集のコストが増加しました。 さて、アーキテクチャを使用せずに、コードを「オンライン」で書き続けることはできなくなりました。 しかし、その瞬間、私はこれをまだ理解していませんでした。



他の重要な症状は、私がその時に読んだり見たりした本やビデオチュートリアルでした。 これらのソースからのコードは、「光沢のある」美しく、自然で、直感的なものに見えました。 教科書と実生活のこのような違いを見て、私の最初の反応はこれが正常であるという考えでした-人生は常に理論よりも複雑で、より日常的で、より具体的です。



それにもかかわらず、一般的には、作業中の製品を拡張、改善する必要がありました。 同時に、私は1つのオープンソースプロジェクトに積極的に参加し始めました。 そして全体として、これらの要因は私を建築的思考の道へと押し上げました。

アーキテクチャとは？

私の大学の講師の一人は、「オブジェクトの数を最大化し 、オブジェクト間の接続の数を最小 化するように設計する必要がある」というフレーズを使用しました。 私が長生きすればするほど、彼に同意します。 この引用をよく見ると、これら2つの条件はある程度相互に排他的であることは明らかです。システムをサブシステムに分割するほど、各サブシステムを他のアクターと「接続」するためにより多くの接続を入力する必要があります。 1つ目と2つ目のバランスをとることは、他の芸術と同様に、練習を通して習得できる芸術の一種です。



複雑なシステムは、インターフェースを介してサブシステムに分割されます。 複雑なシステムから一部のサブシステムを分離するには、最初と2番目の境界を宣言するインターフェイスを定義する必要があります。 想像してください。複雑なシステムがあり、一部のサブシステムは内部を認識しているように見えますが、メインシステムのさまざまな場所に「広がって」おり、相互作用のための明確な形式（インターフェイス）はありません。







事実上、1つのシステムと0の接続があります。 通信を最小限に抑えることですべてがうまくいきます:)しかし、システムの数は非常に少ないです。



そして今、誰かがコード分析を行い、2つのサブシステムを明確に識別し、通信が行われるインターフェースを定義しました。 これは、サブシステムの境界が定義され、スキームが次のとおりであることを意味します。







ここには、3つのシステムとそれらの間の2つの接続があります。 機能の量は同じままであることに注意してください-アーキテクチャは機能の増加も減少もせず、これは単なるコードの整理方法です。



2つの選択肢の違いは何ですか？ 最初のケースでリファクタリングするときは、コードの100％（緑色の四角全体）を「くし通し」して、リグレッションが発生しないようにする必要があります。 2番目のケースでも同じリファクタリングを使用して、最初にどのシステムに属しているかを判断する必要があります。 そして、すべてのリファクタリングは、3つのシステムのうちの1つだけを組み合わせることになります。 2番目のケースではタスクが簡素化されました！ アーキテクチャの断片化が成功したため、コードのすべてに集中するのではなく、コードの一部のみに集中すれば十分です。



この例は、最大数のオブジェクトに分割することが有益である理由を示しています。 しかし、引用の2番目の部分もあります-それらの間の接続を最小化します。 しかし、当局から私たちに届いた新しい改訂がインターフェース自体（2つのシステム間の赤い橋）に影響を与えるとしたらどうでしょうか？ その後、物事は悪いです-インターフェイスの変更には、このブリッジの両端での変更が含まれます。 また、システム間の接続が少ないほど、リファクタリングがインターフェイスに影響を与える可能性が低くなります。 また、各インターフェイスが単純であればあるほど、インターフェイスの両側で必要な変更を行うのが簡単になります。

最も広い意味でのインターフェース

アーキテクチャを正しく適用するための鍵は、インタラクションフォーマットであり、それに応じて各システムの境界を決定するため、インターフェースだと思います。 つまり、サブシステムの数とその接続性（接続の数）は、選択したインターフェースに依存します。 よく見てみましょう。



まず第一に、彼は正直でなければなりません。 インターフェース外のシステム間で通信が行われてはなりません。 それ以外の場合は、元のバージョンに戻ります-拡散（はい、プログラミングにもあります！）2つのシステムを1つの共通システムに結合します。

インターフェイスは完全なはずです。 インターフェースの片側のアクターは、ブリッジの反対側のアクターの内部構造について何も知らないはずです-インターフェースが相互作用する意味、つまり インターフェイスは「ブリッジの反対側」のパートナーを完全に（必要に応じて）記述する必要があります。 インターフェースを最初に完全にすることで、将来インターフェースを編集する必要性を大幅に減らします。インターフェースに変更を加えることは最も費用のかかる操作であることに注意してください。 複数のサブシステムの変更を意味します。



インターフェイスは、OOPからインターフェイスとして宣言する必要はありません。 私は、誠実さ、インターフェイスの充実度、このインターフェイスの明確な理解で十分だと思います。 さらに、この記事のフレームワーク内で私が意味するようなインターフェースは、OOPのインターフェースよりも広いものです。 重要なのは形ではなく、本質です。



ここでは、マイクロサービスのアーキテクチャに言及するのが適切です。 各サービス間の境界はインターフェースに他なりません。これについては、この記事で説明します。

例として、iノードのファイル使用カウンタを* nix（ファイル参照カウント）に移動します。インターフェイスがあります。ファイルを使用する場合は、カウンタを1増やします。使用が終了したら、カウンタを1減らします。 、誰もこのファイルを使用していないため、削除する必要があります。 そのようなインターフェースは、なんとも言えない柔軟性です。 彼は、それを使用できるアクターの内部構造にまったく制限を課していません。 ファイルシステム内のファイルの使用および実行可能プログラムからのファイル記述子は、このインターフェイスに有機的に適合します。

特定のレベルではなく抽象的に問題を解決する

明らかに、適切なインターフェイスを選択する能力は非常に重要なスキルです。 私の経験では、問題を現在の（特定の）表現ではなく、抽象（一般）レベルで解決しようとすると、成功したインターフェイスが思い浮かぶことが非常に多いことがわかります。 アルバート・アインシュタインはかつて、問題の正しい定式化はその解決よりも重要であると言っていました。 この観点から、私は彼に完全に同意します。



「正面玄関を開く」タスクのどのソリューションがより適切だと思いますか？

1. ドアに行きます。
2. ポケットからたくさんの鍵を取り出してください。
3. 目的のキーを選択します。
4. 彼らのためにドアを開けてください。

または：

1. ドアに行きます。
2. サブシステム「キーストア」を呼び出し、そこからアクセス可能なキーチェーンを取得します。
3. サブシステムを「正しいキーの検索」と呼び、そこから利用可能なキーリングから現在のドアへの最適なキーを要求します。
4. 正しいキーを探すために検索サブシステムによって提案されたキーでドアを開きます。

2番目のアルゴリズムの抽象性は最初のアルゴリズムの何倍も高く、その結果、その完全性も高くなります。 2番目のアルゴリズムは、「キー」と「ドア」の概念が今日とは異なる50年後でも関連性が高い可能性があります。



問題を抽象的な観点から見ると、自然に完全なインターフェースを思いつくことができます。 結局のところ、問題の特定の兆候を解決するとき、インターフェイスの観点から考えることができる最大のものは、特定の問題への特定の投影です。 抽象的問題を見ると、いくつかの仕様の表示よりも、 完全なインターフェイスが表示される可能性が高くなります。



ある時点で、特定のマニフェスト（実装）の背後にあるこれらの抽象的な操作が見え始めます。 これはすでに素晴らしいです！ ただし、接続数を最小限に抑える必要があることを忘れないでください。これは、抽象化の世界に行き過ぎてしまうリスクがあることを意味します。 分析に見られるすべての抽象化をアーキテクチャに含める必要はまったくありません。 柔軟性を追加するか、過度に複雑なシステムをサブシステムに分割することにより、存在を正当化するもののみを含めます。

物理学

そのような科学があり、プログラミングとともにそれが大好きです。 物理学では、さまざまな抽象化レベルで多くの現象を考慮することができます。 2つのオブジェクトの衝突は、ニュートン力学と見なすことができますが、量子力学と見なすこともできます。 バルーン内の空気圧は、ミクロおよびマクロ熱力学と見なすことができます。 物理学者は正当な理由でそのようなモデルに来たに違いない。



実際、コードアーキテクチャでさまざまな詳細レベルを使用することも非常に有益です。 任意のサブシステムをさらにサブサブシステムに再帰的に分割できます。 サブシステムはシステムとして機能し、その中のサブシステムを探します。 これは、分割統治アプローチです。 このように、どんな複雑なプログラムでも、プログラマーの友人や企業の会議で技術者ではない上司にビールを飲みながら5分間で対話者にとって便利な詳細レベルで説明できます。



例として、映画をオンにするとラップトップで何が起こりますか？ メディアプレーヤーレベルですべてを考慮することができます（フィルムのコンテンツを読み取り、ビデオでデコードし、モニターで表示します）。 オペレーティングシステムレベル（ブロックデバイスから読み取り、目的のメモリページにコピーし、プレーヤーのプロセスを「起動」してコアの1つで実行する）で表示できます。また、ディスクドライバーレベルで実行することもできます（デバイスのI / Oキューを最適化し、スクロールします目的のセクターに、データを読み取ります）。 ちなみに、SSDの場合、最後のステップのリストは異なります。それがすべての魅力です。 オペレーティングシステムには、ブロックストレージデバイスのインターフェイスがあり、磁気ディスクを突き出したり、USBフラッシュドライブを突き刺したりすることができ、あまり違いはありません。 さらに、ブロックデバイスのインターフェイスは、CD、フラッシュドライブ、その他多くの最新のストレージメディアが登場するずっと前に発明されました。これは、1世代以上のデバイスに関連して生き続けた成功した抽象インターフェイスの例でないとしたらどうでしょうか？ もちろん、誰かがプロセスは反対だと主張するかもしれません-新しいデバイスは既存のインターフェースに適応することを余儀なくされました。 しかし、ブロックデバイスのインターフェースが率直に悪くて不便だった場合、市場から生き残れず、他の代替手段に吸収されていただろう。



人間の脳は、物理学やプログラミング、または他の何かについて話しているかどうかに関係なく、同時に多くの概念/オブジェクトを頭の中に保持することはできません。 したがって、アーキテクチャの垂直階層を整理して、抽象化のどのレベルでもアクターが12人以下になるようにしてください。 同じシステムの2つの説明を比較します。

ここでは、受注を処理します。 最初に検証プロセスがあります-倉庫で注文された商品の在庫を確認し、配送先住所を確認し、支払いが成功します。 次に、通知プロセスが開始されます。新しい注文に関する情報を含むSMSがオペレーターに届きます。 部門長は、概要情報が記載されたメールを受け取ります。

または：

ここでは、受注を処理します。 まず、検証システムが機能します。すべてのデータの正確性と正確性をチェックします。 まあ、原則として、興味があるなら、内部検証（在庫の入手可能性など）と外部（注文で指定された正しい情報）があります。 検証が正常に完了すると、通知システムが起動します。ここでは、このリンクから通知に関する完全な情報を見つけることができます。

最初の説明と比較して、2番目の説明の垂直方向を感じますか？ さらに、2番目の説明では、最初の概念よりも「検証」および「通知」の抽象化を強調しています。

人々は通常どのように月に飛ぶのですか？

そう！ 彼らは最初にロケット（全体としてのロケット、およびその各コンポーネントを別々に）を設計します。 次に、各コンポーネントの生産プラントと、生産されたコンポーネントからロケットを最終的に組み立てるためのプラントを建設します。 そして、彼らは組み立てられたロケットで月に飛びます。 並行性はありますか？



出力は、他の関連する目的に再利用できる膨大な数のコンポーネントです。 そして、これらの部品を大量生産する工場があります。 そして、企業全体の最大の成功は、成功した設計（プロジェクトに酸素回収モジュールを追加するのを忘れ、ロケットがすでに発射台にある場合、物事は悪いです）に依存し、建設されたプラントの品質には少し劣ります（プラントはまだ何らかの方法で較正およびテストできます） ）そして少なくとも何よりも、ロケットの特定のインスタンスからであり、それはランチャー上にあります-何かが起こった場合、既存のインフラストラクチャに基づいて簡単に再作成できます。 すぐに私たちは人々をクローンすることを学びます、そして、失敗した打ち上げでさえ、人的損失の話はありません:)



プログラミングでは、すべてがまったく同じです。 工場の役割は鉄の肩にかかっています-コードを実行するために。 しかしここでは、設計（アーキテクチャの作成）と特定の実装（工場の建設）の役割はプログラマーにかかっています。 ごくまれに、これらの2つの段階が何らかの形で一般的なもつれから明らかに際立っています。 また、これらの2つの段階を別々に考えることは非常に便利です。さらに、他の分野では非論理的に見えます。 結局のところ、このプラントが何を生産するかを最初に決定することなく、誰がすぐにプラントを建設しますか？

アーキテクチャの利点

上記で説明しようとした概念のみを要約しています。 アーキテクチャの使用が成功すると、次のことができます。

• 各システムの分離テストの単純さ。 各システムは厳密なインターフェースを介して外部と通信するため、個別にテストするのは非常に簡単です
• コードサポートの簡素化：サブシステムに分割することにより、既存のコードの変更が簡素化されます。
• システムの拡張性は インターフェイスのおかげで、多くの場所でいくつかの新しい機能を簡単に接続できます（または既存の機能を別の実装に置き換えます）
• コードの再利用が増えています。インターフェイスはコードに弱いバインディングを導入します。 これは、どのシステムも他のタスクに単純に適用されることを意味します。 ここでも、インターフェイスの完全性が重要な役割を果たします。 インターフェイスが本当に完成した場合、新しいタスクに十分です。 Unixのパラダイム「1つのことを行うが、それをうまくやる」を思い出してください。完全なインターフェースを備えた適切に作成されたプログラムを再利用するのは楽しいことです。

成功したアーキテクチャの兆候

アーキテクチャの成功は、「はい」または「いいえ」と明確に評価することはできません。 さらに、1つのプロジェクト（仕様）のフレームワーク内では同じアーキテクチャが成功し、別のプロジェクトでは失敗します（両方のプロジェクトが同じサブジェクトエリアで名目上動作する場合でも）。 設計時には、コードを使用して自動化/モデル化するプロセスを深くかつ包括的に理解する必要があります。



それでも、成功したアーキテクチャの一般的な機能をいくつか紹介します。

• アーキテクチャコードと実装コードの分離。 誰かが抽象的なレベルで問題を解決し（「次の四半期に売り上げを伸ばす必要がある」と言う上司のように）、誰かが全体的な結果の要素の1つを達成するために必要な特定の手順を実行します（PR部門の従業員が新聞で広告を開始します）
• プログラムのどこで停止しても、ここで実行していることの抽象的な説明が常にあるはずです。 ボスのレベルでは、これは「売り上げを増やします。なぜなら、 前四半期は特定の従業員のレベルでは不採算でした」と新聞に発表しました。 これは私の仕事の責任（インターフェイス）の一部であり、これを行うために上から命令を受けました。」 そのような説明は論理的であり、分析された主題/俳優の知識/視野のレベルと一致している必要があります。
• ほとんどのコードは、サービスプロバイダーとコンシューマー間の対話のように見えます。 ユーザー通知システムは「イベントXのユーザーへの通知」サービスを提供し、このサービスの実装の一環として、「SMSメッセージの送信」および「電子メールの送信」サービスを消費します。
• すべての重要なコンポーネントは、代替の実装に簡単に置き換えることができます。 古いコンポーネントを切断して、同じインターフェイスに別の実装でコンポーネントを接続します。 ところで、あなたのネテックのボスは、ある重要な瞬間にそのような機会に非常に喜んでいるでしょう！
• 言葉でアーキテクチャを説明するのは簡単です（追加のドキュメント）。また、コードを調べるときに「意味を理解する」ことは比較的困難です。 つまり、アーキテクチャを構成するインターフェイスのセマンティックロードを説明する方が簡単です。 インターフェイスの抽象化レベルが高いため、この非常にセマンティックな負荷はコードからそれほど明白ではありません。 さらに、使用されるプログラミング言語のフレームワーク内で公式に宣言されていないインターフェイスの中には、プログラマが見慣れないコードを見たときに目を逸らしてしまうものがあります。
• アーキテクチャを使用すると、ほとんどの機能が開発サイクルの終わり近くで利用可能になります。 初期段階では、プログラマはアーキテクチャコードを記述し、個々のサブシステムを実装します。 最終的にのみ、最終的な（ビジネス）結果を達成するために正しい順序でそれらを接続します。 そして、アーキテクチャがない場合や十分でない場合、機能はほぼ直線的に提供されます-コードを書くのに10日かかることは一般的であり、毎日、コードキャンバス全体の10％を書き込みます。 以下は、この項目のグラフィカルな説明です。タスクの完成度と開発時間の分布のグラフです。

成功するアーキテクチャを構築するためのヒント

アーキテクチャの問題を分析するときは、次の3つの質問をしてください。 なぜこれを行うのですか？ これをどうやってやるの？ インターフェースは、「何を？」に責任があります。たとえば、「ユーザーにイベントを通知します」。 消費者は「理由」-サブシステムを呼び出すコード、およびインターフェイスの特定の実装（サービスプロバイダー）が「方法」という質問に答える責任があります。



サブプログラムの形式で自給自足の操作を実行してみてください（使用可能なツールに応じて、関数、メソッド、または他の何か）。 これが1行のコードであり、プログラムで1回使用される場合でも。 そのため、アーキテクチャコード（抽象アクションのリスト）を実装から分離します。 このコンテキストでは、この関数はインターフェイスとして機能し、コンシューマ（関数を呼び出す）とプロバイダー（関数の実装）を取得します。 例：

function process_object($object) { $object->data['special'] = TRUE; $object->save(); send_notifications($object); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または

 function process_object($object) { $object->markAsSpecial(); $object->save(); send_notifications($object); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アーキテクチャでより詳細なレベルを使用します。 集中的な「垂直」破砕により、さまざまな口径のコンポーネントを幅広く選択できます。 そのようなプロジェクトのフレームワーク内で次のタスクの解決を開始するとき、何らかの高レベルシステムを使用するか（迅速に、場合によってはソリューションの柔軟性を損なう）、またはビジネスニーズにより正確に適合する低レベルコンポーネントからソリューションを「追加」するかを選択できます。 当然、可能であれば、高レベルのコンポーネントを好むでしょうが、低レベルのコンポーネントからいくつかの重要なセクションをいつでも自由に組み立てることができます。 たとえば、高レベルの「イベントのユーザーへの通知」コンポーネントがあるとします。 ユーザーのプロファイルの設定に基づいて、通知の長いバージョンまたは短いバージョンを選択し、SMSまたはメールで送信します。 このような高レベルのコンポーネントは、2つの低レベルコンポーネントを使用します。「SMSをコンテンツXで番号Xに送信」および「メールをアドレスXでコンテンツYに送信」です。 次回ユーザーにイベントを通知する必要がある場合、ほとんどの場合、高レベルのコンポーネントを使用します。 ただし、低レベルレイヤーを直接使用して、高レベルコンポーネントをバイパスしてsmsおよびレターを送信するオプションがあります-たとえば、これは重要な通知に役立ちます-重要な状況のため、ユーザー設定をバイパスしてsms電話に直接送信する方が良いでしょう 選択する詳細レベルが高いほど、自由度が高くなります。 それは原子爆弾とポイント空爆のようなものです-時には戦場から地獄を爆破するのがより便利であり、時には戦略的目標に対して10ポイントのストライクを行うのがより便利です。 爆弾では簡単です（抽象度が高い-本土に指を突くだけ）、空爆ではより多くのトラブルが発生します（これらの10個の戦略オブジェクトを選択する必要があります）。



あなたの想像力は指よりも何倍も高速に動作します。コードで実装を開始する前に、紙の上でアーキテクチャを検証して「試してください」。 5時間のコーディングの後、発明したインターフェースが対象分野のニーズをカバーしていないことを理解するのは残念です。20分かけてアーキテクチャを分析し、紙の上でアーキテクチャを「チェック」することで、この問題を予見できました。 ある時点で、私は丸一日座って空を眺め、紙の上で建築物を発明し、転がします。



インターフェイスをオーバーロードしないでください。 インターフェースの完全性を追求するために、冗長な要素を含めることができますが、ここではうっかり油でポリッジを損なう可能性があります。 インターフェースに含まれる要素が多いほど、インターフェースを実装する人に与える自由が少なくなります。 また、それが可能であることを忘れないでください。いくつかの新しいビジネスタスクを考慮して、ある時点でこのインターフェイスを変更する必要があります。 インターフェースが単純であるほど、インターフェースとこのインターフェースの両側のアクターを変更するのが簡単になります。



逆説的に聞こえるかもしれませんが、過負荷のインターフェイスは、完全に負荷分散されたインターフェイスよりも完全ではありません。 詳細が多すぎるとインターフェースが狭くなりますが、拡大しないでください。 一部の詳細は、他のコンテキストでは物理的な意味を失います。 たとえば、イベントをユーザーに通知するシステムのインターフェイスに「やり直し」、タイムゾーンの概念を導入することができます。「ユーザーのタイムゾーンを考慮（またはなし）してイベントについてユーザーに通知」。 あるコンテキストでは、これは正しいインターフェースになりますが、間違ったインターフェースになります。 私たちのシステムのユーザーが月に住み始め、地球人がそれに慣れているという意味で「タイムゾーン」の概念がないと仮定します。 この場合、インターフェイスのこの追加の負荷は冗長になり、アーキテクチャ全体に悪影響を及ぼします。



アーキテクチャを設計するときは、パフォーマンスとスケーラビリティの問題を忘れないでください。 理想的には、インターフェースはできる限りシンプルである必要があります。たとえば、リポジトリからエンティティを変更および削除できるいくつかの機能を考えてみましょう。 インターフェイスに関数を2つだけパックすると、高度な抽象化が得られます。物理データストレージにはリレーショナルデータベースとNoSQLを使用できます。 しかし、そのようなエンティティが数千ある場合、アプリケーションではなくDBMSレベルで操作する必要があることが明らかになります。 次に、これらのエンティティが格納されているインターフェイスにデータベース構造を意識的に含める必要があります。 それ以外の場合、インターフェイスは美しくなりますが、パフォーマンスの要件を考慮して、完全なインターフェイスはエンティティとの大量のやり取りのための高速で効率的なツールを提供する必要があるため、 不完全です。

アーキテクチャの作成

主題分野を正しく理解し、成功したインターフェイスを特定する能力は、芸術に関連しています。 私の場合、私は他の著者の建築の実践と熟考を通じてこの技術を研究し、常に自分の批判的思考のプリズムを通して研究中の建築を通過させました。



比較的大きなタスクを次に解決する必要がある場合は、コンピューターから離れて、1枚の紙で1時間座ってください。 最初は、頭の中に考えが入らないかもしれませんが、問題と、この問題の中に隠れている可能性のある抽象化/インターフェースについて、正直に振り返ります。 気を散らさないでください-没入感と集中力は非常に重要であり、すべての俳優とその関係を想像して、できるだけ詳細に考えて構成することができます。



他の誰かのアーキテクチャ（または自分の、しかし以前は実装されていたもの）のアーキテクチャを見て、コードを変更する必要がある場合、現在のアーキテクチャでこれらの変更を行うのが便利かどうかを分析してみてください。 それで何を改善できますか？



Upd。：ある会議で講演する準備をしていたときにこの記事を書きました。 ここでビデオを見ることができます-meduza.carnet.hr/index.php/media/watch/12326