成功するモバイルアプリケーションアーキテクチャの側面

非常に頻繁に、アプリケーションの開発を開始し、マネージャーからの圧力を受けて、一般的な開発パターンの1つを採用し、すぐにコーディングして、1〜2日でライブプロトタイプを取得します。 すべてが機能し、製品に行き、誰もが幸せであるようです。



そうして初めて、サポート、リファクタリング、新機能の導入に関して疑問が生じると、コントローラーに大量のコードがあり、ボイラープレートの数が4Kスクリーンをカバーし、すべてを書き直すよりも新しいチップをまとめるのが難しいことがわかります。 そして、ここであなたは再び* uyak- * uyakのスタイルで、そして生産ですべてを見ています...



または、時間をかけてファッショナブルなだけでなく、自分のタスクに合ったアーキテクチャを選択する必要がありますか？





一般的な質問に対する回答と、高品質の製品を作成するためのヒントについて説明します。



会いましょう！



ユージーンマシューク 。 カスペルスキーの主任開発者。 彼は、新しいアプローチとツールの導入において豊富な経験を持っています。

















アレクサンダー・ブリノフ 。 REDMADROBOTで、彼はAndroidアーキテクチャ、チームテクノロジーの問題、アプリケーション開発自体に携わっています。

















アントン・ルテビッチ 。 Yandexで働いている間、彼はアプリケーションを開発し、それらのアセンブリと継続的な統合プロセスの重要なケースに対処しました。 Junoは現在、KotlinでAndroidアプリを開発しています。

アーキテクチャ、計画、チームについて

-成功したアーキテクチャと失敗したアーキテクチャの違いは何ですか？



Evgeniy Matsyuk：成功したアーキテクチャにより、開発者はアプリケーション全体のグローバルなリファクタリングを行うことはできません。 最大は、出現したバグを長時間修復せずに、一部のモジュールを分離してやり直すことです。



実際、継続的に「新しい機能を登録」することなく、できる限り多くの価値があります。 アプリケーションは成長し、機能の範囲は拡大しますが、「すべて、それはいまいましい、論理的でシンプルな」という事実から喜びを感じることができます。



アレクサンダー・ブリノフ：建築上の誤りは非常に潜んでいます。 開発の最初の数ヶ月間、彼らはあなたの背中に隠れ、時には松葉杖と疑わしいコードで自分自身を思い出させます。 コードベースの成長に伴い、コードベースはより頻繁に出現し始め、コードのエントロピーが増加します。 時間が経つにつれて、新機能の導入により、プログラムの最も予想外の場所に変化がもたらされます。 このような状況は、チームの雰囲気に悪影響を及ぼし、ビジネスに大きな打撃を与えます。



-あなたの意見では、アプリケーションを開発するための最適なチーム構成は何ですか？ アーキテクチャの開発に関与できるデザイナーは何人ですか？ 最大の効果を達成するために相互作用を構築する方法は？



Evgeni Matsyuk：特定のプラットフォーム用のアプリケーションの開発について話している場合、通常は次のスキームになります。 チームはさまざまなレベルの3〜5人の開発者とチームリーダーで構成され、計画と外部世界全体とのやり取りのタスクがかかっています。 ティムリッド自身と、たとえばチームの最も強力な開発者は、アーキテクチャのタスクに直接対処できます。 つまり、最大2人の1人がアーキテクチャを担当します。 プロジェクトに関するすべての重要な決定-それらを通してのみ。 もちろん、誰もチーム内のホリバロフをキャンセルしませんが、常に誰かが責任を負うべきです。



Alexander Blinov：より大きな数のチームは、アプリケーションのさまざまな部分で作業する部門に分割する必要があります。 パーツへの分割は、水平方向と垂直方向の両方にすることができます。 アプリケーションの論理ユニットの相互作用の順序は、設計者が決定する必要があります。 彼の責任には、システム全体の設計も含まれます。 これらの慣行の遵守は、各部門のリーダーによって監視されています。



Anton Rutkevich：私の意見では、これはバランスの取れたチームであり、異なる役割を持つ人々がいます。 もちろん、誰もが言語、プラットフォーム、アーキテクチャに精通している必要がありますが、開発で特に専門分野や「専門化」などを熟知している人がいると、優れたチームが得られます。チームで（もちろん、いくつかは持っていますが）。 専門分野は、たとえば、高レベルのアーキテクチャ、UIまたは他のプラットフォームフレームワークとの連携、CI、テスト、設計などです。 これは、「専門家」だけがこれらの分野に従事しているという意味ではありませんが、通常、彼らは前進し、改善されたアプローチをもたらし、分野を発展させます。 したがって、より多くの領域がカバーされると、順序はプロジェクトの大部分になります。 チーム全体がアーキテクチャのファンであり、UIフレームワークを詳しく調べたくない場合は、頻繁にアーキテクチャの変更やUIレイヤーを「何らかの形で」作成する大きなチャンスがあります。



また、外界との統合に関与している人が1人、またはそれ以上いることが非常に重要です。 そして、彼らもそれを好むべきです。 APIを近隣のチームと調整し、技術的な観点からビジネス要件を確認し、必然的に生じる対応を行います。



その他。 チームに開発者がいない場合、休暇を取り、必要に応じて休みを取ることが非常に簡単です。 同僚が必要に応じて仕事を引き受けることを常に知っているチームで働くことがどれほど楽しいかはわかりませんが、これは問題にはなりません。



-開発の他の段階と比較して、アプリケーションの計画とアーキテクチャにどのくらいの時間を割り当てる必要がありますか？



Alexander Blinov：主なことは、それを強調することを決して忘れないことです。 多くの場合、マネージャーは顧客/株主の忠誠心を獲得し、その後の再設計を約束するために、できるだけ早く最初のリリースをリリースするようにチームをプッシュします。 しかし、あなたがボートと呼ぶものは何でも、それは浮かびます：アーキテクチャが考えられないアプリケーションは、開発を遅くし、その後、会社に大きな損害を引き起こします。



すべての新しいアプリケーションが開始されるという後援の下で、会社全体の一般的な柔軟なアーキテクチャを検討することは十分に重要です。 コードへの単一のアプローチにより、新しいプロジェクトを迅速に立ち上げることができます。また、構成を簡単に増やしたり、チームを交代させたりすることができます。



Evgeni Matsyuk：プロトタイプや実験的なアプリケーションを開発している場合、アーキテクチャに費やす時間はゼロでなければならないことに注意することも重要です。 ただし、この場合、この製品は単なるプロトタイプであり、拡張できないことをマネージャーに伝える必要があります。

サーバーの役割

-低品質のサーバーAPIを使用してモバイルアプリケーションのアーキテクチャの問題を説明することは可能ですか？ または、これらの独立したものですか？



Eugene Matsyuk：適切なアーキテクチャを使用すると、低品質のAPIサーバーをカプセル化できます。



私の練習では、そのようなケースがありました。 銀行のアプリケーションにチャットモジュールを実装していました。 チャット作業は、サードパーティのサービスを介して行われました。 「クリーンアーキテクチャ」の概念に従ってモジュールを実装し、すべてを単体テストでカバーしました。 作られ忘れられた。



そして9か月後に、Basurmサービスを使用することは何もないという紹介文が到着し、親relativeを使用します。 少し生のAPIと概念がまったく異なる新しいサービスを取得しました。 そして、今すぐこのサービスに切り替える必要があります。 はい。以前のサービスの作業をサポートする必要があったため、その場合はチャットをそれに切り替えることができました。



そして、組み込みアーキテクチャが「ドラッグする」だけで、その貴重な感覚を体験しました。 これは非常に貴重な瞬間です。 皆さんにこれを体験してほしいです。 最初のキスよりも急。

リポジトリレベルでは、新しいサービスの概念がまったく異なるため、置換は機能しませんでした。 したがって、代替はインターアクターのレベルで実行されました。 はい。新しいリポジトリとInteractorの新しい実装を実装する必要がありました。 しかし、視聴者とプレゼンターにはまったく触れず、そこにも多くのコードがありました。 チャットサービスの変更は、Daggerモジュールを使用して簡単に実行されました（Interactorの目的の実装を単純に置き換えました）。



TDDを使用してリポジトリとインタラクターを実装しました。 ところで、複雑なビジネスロジックを実装する場合、TDDは非常に優れています。 実際、すべての準備が整ったときに、すべてが機能することを確認するために、最後に検証用のアプリケーションを起動しました。 追加のバグやその他のものは現れませんでした。 すべての悪はカプセル化されています。 まあ、素晴らしい？



-TDD方法論についてどう思いますか？ 最も頻繁に使用する開発アプローチとその理由は何ですか？



Anton Rutkevich： TDDは優れた方法論です。 それに従うと、テストでコードをカバーする問題がクラスとして消えます。 コードテストなしでは、まったくありません。



一方、大量の新しいコードを書く必要がある膨大なタスクを解決する場合、最初に正しいアーキテクチャの概要を説明すること、さらにモジュール間の相互作用のAPIを正確に考えることは困難です。 この場合も、私の意見では、TDDアプローチは不必要に開発時間を増加させます。 コードを書き換える前に、テストを書き換える必要もあります。



したがって、主に既存の機能を拡張する必要があり、インターフェイスが明確でない場合にTDDを使用します。



-アプリケーションからサーバーへの実行ロジックの転送はいつ正当化されますか？



Alexander Blinov：モバイルアプリケーションはシンクライアントであり、深刻なロジックを実行するためのものではありません。 顧客がこのアプローチに対応するAPIをモバイルクライアントに提供する準備ができていない場合、ミドルウェアをクライアント/サーバー相互作用チェーンに統合します。 ミドルウェアはプロキシバックエンドであり、複雑な顧客サービスとの統合を行い、クライアントアプリケーションのAPIを便利な形式にします。 原則として、複雑なロジックはAndroidとiOSで2回ではなく中央で1回書き込まれるため、これにより開発が高速化されます。 場合によっては、ミドルウェアチェーンへの統合が不可能な場合があります。たとえば、モバイルバンクはセキュリティ要件を高めており、潜在的な攻撃対象領域を最小限に抑えたいと考えています。 これらの場合、ミドルウェアを顧客のサーバーに統合します。



-モバイルアプリケーションのアーキテクチャにおけるMVP、MVC、MVVMの位置は何ですか？



Eugene Matsyuk： MVCという用語は、Android開発者の間ですでに流行していないようです。 アクティビティを含む連想シリーズはすぐにトリガーされますが、これは以前はコントローラーと見なされ、非現実的なサイズと複雑さに達しました。 覚えてますか？ 恐怖に歪んでいますか？ この略語を再び大声で発音しないでください。さもなければ、あなたは分析されます。



MVP、MVVMはプレゼンテーション層についての詳細です。 さらに、最近人気を集めているのはMVVMですが、DataBindingを介してではなく、RxJavaを介して「手作業で」実装されています。 その結果、MVPよりも定型コードが少なくなります。 このアプローチに関するデニス・ネクリドウフとステパン・ゴンチャロフのレポートを聞いてうれしいです。



「クリーンアーキテクチャ」とは、アプリケーション全体のことです。

Androidアプリケーションの構造について

-Android用アプリケーションのアーキテクチャを開発することの特性は何ですか？



Evgeni Matsyuk：永遠に語ることのできる質問です。 私にとって最も重要な機能は、最初はアーキテクチャについてまったく考えなかったことです。 GoogleはかつてSDKを提供し、開発者に次のように語っていました。 そして、彼らは行きましたが、順調ではありませんでした。 その結果、メンテナンスとやり直しが必要な多数のアプリケーションが登場しました。 しかし、退屈することはありません。



Alexander Blinov： Android開発者は、ライフサイクル、許可を提供する方法など、多くの奇妙な決定を下しました。 システムの最初のバージョンでは、そのような決定は鉄の低電力によって決定されました。 現在、スマートフォンははるかに強力になりましたが、私たちはスローガンの人質になりました：「彼らは一度書いた-私たちは常に苦しむ！」 これにより、 Senneco Moxyのシステムなど、システムとの闘いをカプセル化するフレームワークが作成されます。 モビウスの裏でモクシーがどのように機能するかについてのユラの話を聞くことをお勧めします



-書きすぎないことは可能ですか？ 優れたアーキテクチャを備えたアプリケーションにはカーネルのどのレイヤーが必要であり、場合によってはどのレイヤーを除外できますか？



アレクサンダー・ブリノフ ：これはかなり全体的な質問です。 Clean Architectureで特定した5つの論理層には、それぞれ固有の責任範囲があります。 私たちはアーキテクチャの一貫性を守り、ある機能に論理層が必要なくても、プロキシとして機能します。 これにより、コードを予測可能かつ容易に拡張できます。



-Android向けアプリケーションの設計に通常使用されるテクノロジースタックは何ですか？



Evgeni Matsyuk：前回の講演で、RxJava、Dagger、Unit testsのスタックについてお話しました。 次に、ライフサイクル処理用のMoxy、ナビゲーション用のCiceroneを追加します。 一般に、Kotlinで引き続き作成を開始できます。



Alexander Blinov： REDMADROBOTにも同様のテクノロジースタックがあります。 Kotlinは1年以上にわたって生産を行っています。 新しいコードはすべてKotlinでのみ記述されています。



-アーキテクチャの構築に関する開発者への主なアドバイスは何ですか？



Anton Rutkevich ：ソリッドを覚えて、クリーンアーキテクチャアプローチを意識的に適用する必要があると思います。 これは、どこでも偏執的に従う必要があるという意味ではありませんが、一部の場所でのクリーンアーキテクチャからの離脱は、常に意識的でバランスのとれた決定である必要があります。



ユージン・マトシュク：考えてみてください。 試してみてください。 そして考え直してください。 もう一度やり直してください。

基本的な設計パターンを研究し、それらが本当に必要な理由と状況を感じてください。



成功するアーキテクチャを作成することは、最も困難で責任のあるタスクです。 しかし、ここでは格言は本当に適切です-「忍耐と仕事-すべてがこするでしょう」。



Alexander Blinov：建築に時間を割くことを忘れないでください。 プロジェクトの評価に自由に配置し、適切に構築されたアーキテクチャの欠如がその後ビジネスに打撃を与えることをマネージャーに知らせてください。



-あなたはメビウスで何について話しますか？



Evgeniy Matsyuk： 「クリーンアーキテクチャ」に没頭したいと考えています。 開発者が尋ねる基本的な質問を考慮し、私たちの生活でよく見られるケースを考慮し、「クリーンアーキテクチャ」でそれらを解決する方法を示します。



残念ながら、私たちはわずか50分しかありません。そして、私たちが興味を集めたもののほんの一部を教えません。 しかし、基本的な理論的なポイントから最も洗練された実用的な状況まで「クリーンアーキテクチャ」を明らかにしようとするドキュメント（一連の記事またはCookBook）に取り組んでいます。 したがって、私たちは助け、アドバイス、興味深い仕事を喜んでいたします。 1月から、Androidのアーキテクチャ専用のTelegramでチャットを開始しました 。 すでに500人以上です。 参加して質問してください！



Anton Rutkevich： Mobiusで、意識的にコードを書く方法についてお話します。そうすれば、コードを書いた後、テストでカバーされることが保証されます。 レポートにはKotlin（コードがスライドに収まるように）とAndroidの例が含まれるという事実にもかかわらず、プラットフォームと言語の外側にあるアイデア、およびそれらをあらゆるコンテキストで適用する実用的な能力に重点が置かれます。 したがって、私は皆を招待します。



Alexander Blinov：多くのテクノロジーはHellowordで正常に動作しますが、実際のコードに直面すると失敗します。 このレポートでは、「クリーンアーキテクチャ」の価値が証明された最も複雑なケースを分析します。



そのため、 Mobius 2017の枠組みで Eugene とのレポートに皆さんを招待したいと思います。 クリーンアーキテクチャに没頭し、仲間の労働者とともに輝かしいホリバーを約束します！ また、皆さんが、燃えるような目とクールなアイデアで、会議からインスピレーションを得ることを願っています！



フォーラムでお会いしましょう！