Mosby Androidフレームワークの作成者であるHannes Dorfmanとの素晴らしいインタビュー

Android向けのコーディングを始めたきっかけは何ですか？



私はいつもモバイルアプリの開発に魅了されていました。 私は高校でqtとC ++を使用してSymbianで最初の「アプリ」を開発し、少しj2meも実行しました。 また、Windows CEを実行しているポケットPCでハックすることもできました。 したがって、最初のスマートフォンとiPhoneが登場したときは興奮していましたが、アンドロイドと私が一目firstれしたとは本当に言えません。 2009年夏に大学にいたときに初めてAndroid（Android 1.5-カップケーキ）用にプログラムしたのは初めてでしたが、「main（）」メソッドはどこにあるのか、XMLの内容は何なのか、これは一体何なのかfindViewById（）こと。 だから、2009年後半にNokia N95が動作しなくなり、スマートフォンを購入する時が来るまで、Androidを半年近くドロップしました。 iPhoneは決して私のお茶ではなく、デバイスにハードウェアキーボードを搭載したかったのです。 画面に長いテキストを入力することは想像できませんでした。 2つのオプションがありました。Android2.0を実行する元のMotorola Droid（Milestone）またはMaemoを実行するNokia N900です。 MaemoはC ++とqtも使用したため、N900を選択するのに非常に近かったのですが、主にMaemo OSがMMSをサポートしていないため、Motorola Droidを選択しました。これは明らかに地球上で最も重要なことです:) Motorola Droidを手に持っていたので、Android 2.0用に開発を始めました（個人用のみ）。



JSのアーキテクチャソリューションを採用することについてのあなたの意見は何ですか？



JavaScript開発者には、Android開発者と共通点があります。ソフトウェアアーキテクチャの観点からは、基本的にガイドラインのないプラットフォーム/ SDKがあります。 グリーンフィールド。 JavaScriptの世界では、ソフトウェアアーキテクチャの聖杯を探し続けています。そのため、ほぼ3か月ごとに新しいJSフレームワークとパターンが出現および消滅しています。 しかし、Model-View-Intent（cycle.js）、Redux、Fluxのようないくつかのデザインパターンは、いくつかの本当に素晴らしいアイデアを紹介しました。これらはチェックアウトする価値があり、他のプラットフォームのパターンやフレームワークの背後にあるアイデアを採用することは理にかなっていますAndroidも好きです。 Androidでは、常により良い方法であるとは限らず、何度も何度も車輪を再発明する傾向があります。 一般に、開発者はボックスの外側を考えて、他のプラットフォームがそれらから学ぶために何をするかを見て、彼らが犯した間違いから学ぶことがさらに重要です。



React Nativeまたは別のクロスプラットフォームアプローチには、将来の展望がありますか？



いい質問です。 正直に言うと、私にはわかりません。 一般に、Webアプリを作成するためのRxJS（JavaScriptのRxJavaの同等物）のようなより良い方法とツールがあると思うので、React on the webにあまり興奮していません。 React Nativeについては、FacebookがReact Nativeを実装するのに素晴らしい仕事をしたにもかかわらず、AndroidとiOSのUIコードをネイティブに記述する必要があると思います。 また、kotlinやswiftなどでモバイルアプリを作成できる場合、JSでモバイルアプリを開発したいかどうかもわかりません。 ただし、特にAndroidとiOSの間で、ビジネスロジックの共通のコードベースを共有するモバイルアプリがますます増えると考えています。 Xamarinのようなツールが役立つかもしれません。 私が働いている会社では、gwt、アノテーション処理、j2objcに基づいたソリューションを見つけました。Javaでコードを1回記述し、それを翻訳することで、Android、iOS、バックエンド（JRuby）、Webフロントエンド（JavaScript）でビジネスロジックを共有します特定のプラットフォームで実行されるネイティブobject-cおよびjavascriptコード。



本番環境でのKotlinに対する見解は何ですか？ アンドロイド開発のための将来の主要言語についてのあなたの考えは何ですかKotlin、Java8、Swift？



Kotlinは非常に優れた言語であり、最新のアップデート1.0.2は大きな前進でした。 残念ながら、私が働いている会社では、まだプロダクションでkotlinを使用していません（一部のユニットテストを除く）が、個人的なサイドプロジェクトではkotlinを集中的に使用しています。 Swiftも素晴らしい言語ですが、Webからの他の噂とは対照的に、Androidアプリを開発するためのプログラミング言語としてSwiftを見るとは思いません。 JNI経由で使用されるC / C ++の代替として見るかもしれませんが、SwiftがJavaに代わってAndroid API / SDKにすぐにアクセスするとは思わないでしょう。 Java 8には、待望の機能がいくつかあります。 Lambdasは最も人気のあるものの1つですが、私のお気に入りは、ミックスインを使用できるようにするインターフェイスの既定のメソッド実装です。 残念ながら、これはAPI 23以降でのみ利用可能です。



新しいAndroid Jack＆Jillツールチェーンに関して何か期待はありますか？ 本番ではどのアーキテクチャパターンを使用していますか？ MVVMについてのあなたの考えは、Googleが将来の標準として賭けているように思われますか？



Jack＆Jillは、今後Android開発に従来のJavaやJava 9を使用しないという方向に進化すると信じています。 Jack＆Jillを使用すると、Android開発用のJavaプログラミング言語の何らかの分岐が見られると思います。



基本的にはMVPを使用しますが、単方向のデータフロー、不変性、純粋な関数など、他のアイデアもあります。 また、MVP、MVVMなどと言っても価値があります。 はアーキテクチャではなく、ビューを基礎となるレイヤーから分離するアーキテクチャパターンです。 多くの人がこの文脈でロバートC.マーティンのクリーンアーキテクチャを参照しています。これは素晴らしいアーキテクチャです。 Clean Architectureに従ってアプリを実装します。 いつものように、私は本の近くにいようとしていますが、盲目的に本を正確にたどっていません。



Googleはデータバインディングエンジンを提供します。 これは、MVVMを実装する必要があることを自動的に意味するものではありません。 データバインディングは、MVVMなしでも使用できます。たとえば、RecyclerViewでViewHolderをバインドするだけです。 一般に、データバインディングは、私が強く信じる重要な原則の1つである不変性を破るので、Googleのデータバインディングと組み合わせてMVVMよりもMVPを好みます。 したがって、MVVMを実装する場合は、RxJavaを使用することをお勧めします。

全体的に、Googleは過去に特定のパターンを強制しませんでしたが、MVVMとデータバインディングを使用して将来的にGoogleがそれを行うことはないと確信しています。 実際、ソフトウェアアーキテクチャの観点からAndroidアプリを構築する方法について、Googleから公式の声明を聞きたいと考えている多くの開発者を知っています。 しかし、Googleはそのような公式な声明を発表したことはありません。 彼らは、MVVMがMVCやMVPよりも優れているとは言いたくありません。 開発者はそのためにGoogleを嫌っています。 しかし、ソフトウェアアーキテクチャは時間とともに進化するトピックであるため、Googleはそのような発言を行わない100％正しいと思います。 1つのアーキテクチャパターンが最適であるとは言えません。すべての種類のアプリケーションに対して、誰もがその方法でアプリを実装する必要があります。 1つのパターンを最良の解決策として宣言することは、停滞を意味することがよくあります。



単体テストの作成にどれくらいの時間を費やしていますか？ 十分なカバレッジをどのように確保しますか？



彼らが取る限り多くの時間。 量産コードを書く前に単体テストを書くというTDDを実践しています。 通常、私はこの規則に固執します。 ただし、アプリのUIは非常に単純なので、UIの機能テストを書くことはほとんどありません。 ビジネスロジックはなく、要素などを並べ替える複雑なアルゴリズムもありません。 UIレイヤーで。 大した間違いはありません。 機能的なUIテスト（エスプレッソ）に伴うもう1つの問題は、実行に数分かかることです。 それはTDDを破壊します。 作成したコードのユニットテストをTDDで効率的に実行することはできません。 TDDフィードバックループが約2〜3秒長いバックエンド開発と比較すると、TDDの実践には10秒は許容されません。 だから、個人的には、機能的なUIテストを作成しないことにしました。 既に述べたように、私のUIレイヤーは非常に単純です。 したがって、ボタンをクリックして正しいアクションがトリガーされるかどうかをテストすることは、私の意見ではそれほど重要ではありません。 実際には、特に多くのxmlレイアウトを持つチームで作業しているときに、「視覚的なバグ」がより頻繁に発生することがわかりました。 UIが期待どおりに見えるかどうかをテストするほうが、ボタンが正しく動作するかどうかをチェックするよりも価値があります。 そのため、視覚的なリグレッションを防ぐためにスクリーンショットテストを行うことにしましたfacebook.github.io/screenshot-tests-for-android 。



最後になりましたが、十分なカバレッジを確保するにはどうすればよいですか？ 開発者は数学と統計が得意です。 多くの開発者は、JaCoCoのようなコードカバレッジツールを使用します。 しかし、すでに述べたように、私はUIをテストしておらず、POJOのゲッターとセッターもテストしていません。 そのようなコードカバレッジツールが80％のカバレッジを持っていることを教えてくれたらどうでしょう。 この文脈で実際に80％とはどういう意味ですか？ 理解を深めるために、パッケージごとのコードカバレッジを詳しく見ることができますが、このような数値では、単体テストをもっと書く必要があるかどうかを判断できないという結論に達しました。 コードレビューで十分なカバレッジを確保します。 通常、同僚の1人は、コードレビュー中に単体テストが意味をなさないか、コードの特定の部分もテストする必要がある場合、または1つの単体テストが値を追加しないか親切であるためにまったく意味がない場合を検出しますの複製。



画面構築のためにフラグメントベースまたはビューベースのアプローチを好みますか、mosby-conductor / mosby-flowに関する考えはありますか？



通常、私はフラグメントを使用し、フラグメントに大きな問題はありませんが、フラグメントについて不満を言う人々を理解しています。 フラグメントのアイデアは素晴らしいですが、現在の実装は完全にはほど遠いです。 これがConductorの出番です。 コンダクターは基本的にフラグメントのより良い実装です。 一方、フローはナビゲーションスタックに置き換わるものです。 コントローラー（フラグメント）の概念を完全に失い、プレーンなandroid.view.Viewを使用します。 これはライフサイクル管理に関する非常に単純な概念であり、拡張可能ですが、大量のコードを手動で記述する必要がある場合とそうでない場合があります。 コントローラーが欠落しているため、Flowは、フロー内のビューが特定のビューの対応するコンポーネントにアクセスできるようにするServiceFactoryを提供しています。 これは、mosby-flowが行うことです。 このプラグインは、ビューのライフサイクルに合わせてビューのプレゼンターを提供するServiceFactoryを提供します。 最後に、Mosbyの便利なAPI（Fragments and Activitiesと同じ）を使用して、FlowでMVPパターンを実装できます。 mosby-conductorはConductorにも同じ機能を提供します。 現時点では、FlowよりもConductorを好む傾向があります。 この2つのプラグインとフラグメントとアクティビティのMosbyの組み込みサポートにより、モデルとプレゼンターは独立して使用できるため、ビューレイヤーのみをタッチすることで、アプリ、つまりフラグメントからコンダクターにリファクタリングする自由があります優先されるビューレイヤーコンテナ（アクティビティ、フラグメント、コンダクター、フロー）。



Androidライブラリの注釈処理でJVMバイトコードパッチを使用することについてどう思いますか？ Cleanアーキテクチャは現時点でAndroid開発に最適なアーキテクチャですか、それとも他に評価されていないオプションがありますか？



JVMバイトコードパッチの問題は、バイトコードを簡単にデバッグできないことです。 したがって、IDEのデバッガーで生成コードをデバッグできるため、注釈処理が好まれます。 正直なところ、すべてのソフトウェアにバグがあるため、バイトコードを操作するライブラリと注釈処理ライブラリがあります。 主な質問は、そのようなライブラリにバグがある場合、そのようなバグが私の日々の開発にどの程度影響するかということです。 あなたがアプリで作業しているのに、そのようなライブラリのバグのために何かが期待通りに動作しないと想像してください。 原因となるライブラリがバイトコードパッチライブラリである場合、バグがライブラリによって引き起こされていることを発見するのが難しく、修正プログラムを適用するのが難しくなります。 対照的に、注釈処理ベースのライブラリがアプリのバグの原因である場合は、単にIDEのデバッガーをアタッチできます。 全体的には、それはすべて信頼に関するものだと思います：開発者、つまり、バイトコードを操作するライブラリのSquareを信頼するのであれば、そのライブラリを使用しても構いません。



クリーンなアーキテクチャは事実上の標準であり、十分な理由があるようです。 最近、kotlingやSwiftなどのプログラミング言語が、関数型プログラミング言語の概念を採用するのを見てきました。 Clean Architectureは時代を超越した概念ですが、将来、境界やユースケースなどの概念が理論上まだ存在し、純粋な関数の背後に隠れてしまうような、より多くの関数型プログラミングパラダイムを使用すると考えています。 それは私が以前「本に近づきなさい、しかし本に正確に従うことはない」ということでした。



Mosbyライブラリは、フラグメント/アクティビティで1つのプレゼンターと1つのビューを使用することを意味します。 それは良い解決策だと思いますか？ 大きなプロジェクトでは、多くの場合、複合ビューを使用する必要があります。複数のプレゼンター、1つのフラグメント内の複数のビューが相互作用します。 あなたの意見ではどのソリューションが最適ですか？



はい、すべてのビューには1人のプレゼンターがいるはずです。 すべての複雑なビューは複数のサブビューに分割でき、各サブビューには独自のプレゼンターがいます。 ビューとプレゼンターは互いに対話することはありません（実際に必要でない場合、つまりアプリ内のナビゲーション）。アプリは、サブビューがモデルを更新する（彼自身のプレゼンターを介して）一方向のデータフローを確立する必要があります。別のサブビューのプレゼンターは、他のサブビューを更新します。 最初のサブビューが他のサブビューと直接対話する必要はありません。



Mosbyはアクティビティ/フラグメントをビューとして扱い、この実現では、これらのコンポーネントはライフサイクル、ルーティング、および依存関係の実装に対応します。 このような構成はSRPと矛盾すると思いますか？ あなたの意見では、Androidクラスの抽象化はどの程度正当化されていますか？



それは良い点です。 Infact Activity / Fragmentは、SRPと大きく矛盾しています。 一種のコントローラーであり、ライフサイクルを管理し、UIウィジェットと対話します。 モスビーでは、アクティビティ/フラグメントを扱うことにしました。 ただし、Mosbyでは、MvpActivity / MvpFragmentにgetMvpView（）というメソッドをオーバーライドできるため、必ずしもそうする必要はありません。 このメソッドは、プレゼンターが対話するMVPビューを返します。 デフォルトでは、これはアクティビティ/フラグメント自体ですが、MVPビュー専用に別のレイヤーを導入し、そのメソッドでそのレイヤーを返すことができます。 そうすることで、専用の「MVPビュー」レイヤーを1つ作成し、アクティビティをライフサイクル管理コンポーネントとしてのみ扱うことができます。 理にかなっているように思えるので、なぜデフォルトごとにそれをしないのですか？ その場合、さらに別のレイヤーを追加することになり、それがさらに別のレイヤーを追加することがオーバーエンジニアリングの始まりであるためです。 アクティビティ/フラグメントが多すぎてSRPと矛盾していると思われる場合は、先に進んでMVPビューレイヤーなどのレイヤーを追加します（ヒント：データバインディングエンジンを使用できます）が、平均的なアクティビティ/ Mosbyを搭載したフラグメントは通常、MVPビューインターフェイスのみを実装しています。 その場合、完全なSRPがなくても、Activity / FragmentにMVPビューインターフェースを直接実装しても問題ありません。 オーバーエンジニアリングは、悪いコードを書くのと同じくらい悪いです。



Mosbyの3番目のバージョンにはどのような変更が予定されていますか？



「フードの下」での内部クリーンアップとは別に、子のフラグメントとViewGroupsのサポートを、プレゼンターの保持と組み合わせて追加します。これは、Flow統合の向上にも役立ちます。 よく聞かれるもう1つの機能は、RecyclerView / ViewHoldersのMVPです。 職場のアプリの1つにこのようなものを実装しましたが、追加することを検討するかもしれません。 しかし、RecyclerViewには注意が必要です（ViewHoldersはリサイクルされています。Adapterのデータセットはいつでも変更できます。画面の向きの変更など）。 これを本当に追加したいかどうかを評価する必要があります。 このようなソリューションを公開すると、物事がすぐに手に負えなくなり、誤用されるのではないかと心配しています。 Pandoraのボックスを開きたくありません。



Mosbyの現在の開発段階は何ですか？ いくつかの新しい機能を追加するのですか、それともバグを修正し続けるのですか？ Mosby-Conductorプラグインがあることを考慮して、MVPおよびView vs Fragmentsでのライフサイクル処理についてどう思いますか？ Mosbyの欠陥のためにMoxyが作成されたと思われるMPVライブラリがあります。 あなたはそれを知っていて、比較をしましたか？



私はMosby 3.0に取り組んでいます（スナップショットはすでに利用可能です）。 残念ながら、現時点ではMosbyに取り組む時間はあまりありませんが、6月末に仕事を続けたいと思っています。 MVPの独自の解釈と実装に十分なスペースを確保することで、Mosbyの上にアプリケーションを構築するためのベースとして使用できる基礎として、Mosbyを構築するために最善を尽くしました。 たとえば、Presenterにはライフサイクルコールバックメソッドは必要ないと思うので、MosbyのデフォルトのPresenterにはそのメソッドがありません。 しかし、アプリがこのようなライフサイクルを意識したPresenterを持っていることが理にかなっていると思う場合は、ライフサイクルメソッドで基本プレゼンタークラスを作成するだけです。 Mosbyにはプラグインメカニズムがあるため、アプリ全体でライフサイクルを意識した基本Presenterクラスを簡単に使用できます。 Moxyは素晴らしいアプローチだと思いますが、これは以前に「ソフトウェアアーキテクチャが進化する」という意味の良い例です。 Mosbyには同意しておらず、解決していない実装の詳細がいくつかありますが、それは私のやり方が正しい方法であるという意味ではありません。 他の人の仕事について誰を判断するのですか？ したがって、MosbyとMoxyを比較しません。 両方を見て、あなた自身の心を作ることをお勧めします。 重要な点は、ニーズに合ったライブラリを選択する必要があることです。つまり、Moxy、Mosby、Nucleus、まったく異なるライブラリなどがあります。



Mosbyライブラリは生産に適したソリューションであると考えますか、それとも概念のですか？ Mosbyは、数百万人のユーザーが使用するアプリケーションで長年にわたってプロダクションで使用されています。 私たちにとっては、うまく機能し、生産準備が整っています。 フロントエンドの開発者に基本的な再帰アルゴリズム（深さ優先検索など）、データ構造（「逆リンクリスト」）などについて質問したため、最近大企業がインタビューを過度に複雑にすることについて多くの話がありました。 人を雇うにはどのようなアプローチが必要ですか？ 面接はどのように行いますか？ たとえば、中級レベルのAndroid開発者にとって何が必要だと思いますか？



私は、当社の採用プロセスにはそれほど関与していません。 CTO / CEOがいない場合にのみインタビューを行います。 通常、候補者は自宅で作業するための問題を取得します。 基本的に、彼は非常にシンプルなAndroidアプリを構築する必要があります。 通常、彼は1週間で解決策を送信します。 次に、コードを見て、彼を個人的なインタビューに招待します。 私があなたのインタビュアーである場合、データ構造に特定の質問をしたり、ホワイトボードでクイズを解いたりすることはありません。 候補者にリラックスした雰囲気を作りたいです。 それから、彼の背景について基本的な質問をします。 候補者の背景は非常に重要だと思います。 候補者が大学から来て、彼の最初の仕事を得ようとすると（インタビュー中にいくつかの理論的な質問をするかもしれません）、候補者がすでに実務経験がある場合（より実践的な質問）は大きな違いになります。 理想的には、候補者はすでにオープンソースプロジェクトに取り組んでいることです。 私は彼にコンピューターを渡します（または、彼がインタビューに自分のマシンを持ち込むことをお勧めします）。私たちは彼のコードをステップスルーし、その特定の方法で特定のことを実装した理由、彼がそれを選んだ理由などの特定のことを説明してほしい特定の問題のデータ構造など。 したがって、間接的にデータ構造について説明します。 データ構造は、フロントエンド開発者にとっても重要です。 しかし、候補者が赤黒木を回転させる方法を知っているとは思わない。 しかし彼は、セットやマップ、ツリーではなくリストを使用することにした理由について、適切な議論が必要です。 その後、彼が自宅で開発したデモアプリでもライブリファクタリングで同じことを行います。 私にとっては、Javaプログラミング言語、データ構造、スレッド化、同期、およびガベージコレクションの基本的な知識がある、優れたJava開発者を雇うことが重要です。 Android SDKをすばやく習得できると思うので、これは非常に経験豊富なAndroid開発者よりも重要ですが、優れたJava開発者になるには何年もかかります。 WeakReferenceとPhantomReferenceの違いのような迷惑な質問はしませんが、候補者が特定の分野に特化していると感じたら、彼のスキルについて話す機会を与えます。 2番目のパー、彼が自宅で開発した彼のアプリのレビューでは、候補者が開発の非常に重要な部分であるリファクタリングのスキルを確認したいと思います。 私とのインタビューの最後の部分では、候補者に、会社、アプリのコードベース、必要に応じてサッカーについてなど、好きなトピックについて質問させていただきます。 最後になりましたが、私は同僚と私が学ぶことができる人を雇いたいです。 すべての新しい従業員が会社に新しい知識をもたらします。候補者が喜んで、この知識を私たちと共有する勇気を持っていることを確認したいと思います。



Javaプログラミング言語、ActivityやServicesなどのAndroidコンポーネントのライフサイクル管理、XMLで効率的なレイアウトを構築でき、SQLの基礎知識と優れた知識を持っている必要があります。 HTTPプロトコルの理解。 設計パターンとソフトウェアアーキテクチャはプラスですが、強い要件ではありません。



Gradleの助けを借りてプロジェクトをコンパイルするのに時間がかかるという事実についてどう思いますか。 コンパイルに費やす時間を最小限に抑えるのに役立つアーキテクチャへのアプローチはありますか？



コンパイル時間は恐ろしいです。 コンパイル時間が遅いために、企業がどれほどお金を失うか想像することすらできません。 この問題がどのように解決されるかは気にしません。javac、Jack＆Jill、またはaaptの高度なバージョンなど、最適化できるものであれば問題ではありませんが、この問題はできるだけ早く解決する必要があります。 私はしばらくの間FacebookのBuckビルドシステムを使用し、非常に高速でしたが、非公式のビルドシステムに永久に切り替えたくありませんでした。 Buckを適切に設定することにも問題がありましたが、これは私のせいだと思います。 Buckは間違いなく良い選択肢です。



本物かアーセナル？ :)

私はサッカーが大好きです。本当に好きです。 だから、ドロイドパーティーでアンドロイド関連のトピックを使い果たした場合に備えて、何時間もサッカーについて話すことができます。 レアルマドリードとバイエルンミュンヘンのサポーターです。