「当社のアプリケーションはTARDISのようなものです。内部は外部よりも大きくなっています」-モバイル開発に関するAvito

Avitoがモバイル開発に注意を払っていることを主張することはできません。彼らは、 Kotlinが流行するずっと前にKotlinを使用し始め、この会社のスピーカーはMobiusカンファレンスで定期的に講演しています。 そして、モスクワメビウスの前夜、2人のAvitoの従業員に尋ねました。Dmitrydivor VoroninがKotlinの使用経験について正確に語り、 Yegor YourDestiny Tolstoyがモバイル開発全般について語りました。

ドミトリー・ボロニン

-以前、Avitoの経験に基づいて、KotlinとRxについてのレポートがありましたが、会社で具体的に何をしていますか？



-現時点では、アプリケーションのリリースサイクルを短縮するために組織された特別なチームの一部として、セルフテスト用のインフラストラクチャを開発しています。



-現在、Androidの世界では誰もがKotlinを愛していますが、Avitoはそれをずっと早く使い始めました。



-AvitoのKotlinの最初のクラスは、2014年12月の地域に登場しました。 その後、2015年に、Kotlinですべての新しいAndroidアプリケーションコードを記述することにしました。 ベータ版以降、Kotlinを使用していることがわかりました。



-もともと彼に使用を促したのは何ですか？ Avitoは、コトリン愛好家のジェイクウォートンが働いていたSquareのモバイル開発を積極的に使用しています。



-2014年、最後までJava 6が登場するようでした。 Googleはその時点でいかなる計画も開示していません。 既存のプロジェクトのKotlinで数十のクラスを作成した後、Java + Guavaバンドルを見ると、すぐに落胆が引き起こされました。 より読みやすいコードに加えて、より強く型付けされたコードに加えて、既存のコードとの相互運用-双方にとって好都合な状況のように見えました。



ジェイクと他の伝道者は確かに、この決定を後押しする大きな影響を与えました。 彼の象徴的な投稿を読み直すことは非常に興味深いことでした。



-言語を使用している間にKotlinの開発にどの程度の変化がありましたか？ どれほど便利になり、定期的に「再学習」する必要がありましたか？



-はい、多くが変更されました。Kotlinで作業するのが著しく快適になりました。 Gradleプロジェクトのインクリメンタルコンパイルがなく、コードの書式設定がいくつかのチェックボックスから行われ、検査を無効にしなければならなかったため、IDEの速度が低下しました。 今、これはすべて過去です。



言語の新しい機能を表示されるように使用しようとしていますが、コルーチンや不変コレクションをプロジェクトにまだ含めていませんが、これはすぐに来ると思います。 このような変更は、プロジェクト全体に一度に展開されるのではなく、徐々にコードベースに浸透します。 誰もが実行可能性と落とし穴に慣れて議論する時間があります。



主にJavaでソースを開くときに再学習する必要があります。行末にセミコロンを入れるのを忘れるたびに;）



-Kotlinの「落とし穴」を強調してもらえますか。これまでのところ、この言語の使用のみを考えている人の注意を喚起したいと思いますか。



-Androidについて話していることを明確にします。 それらのいくつかがあります：

1. 注釈処理（kapt）はKotlinの非常に信頼性の低い部分であり、ある程度のモジュールでは、コード生成を通じて機能するすべてのツールを意識的に放棄しました。 最近まで、一般的に自分の危険とリスクでのみ使用することが可能でしたが、状況は改善されています。 Java + Gradle用AndroidプラグインのannotationProcessorで記述されたDagger 2モジュールおよびコンポーネントファクトリーの束は、kaptよりもプロジェクトでより効率的に機能します。
2. Kotlinのツールは、多くの重要な面でJavaに遅れをとっています。 静的アナライザーがないことは最も苦痛です（Android Lintは次のバージョンでのみKotlinソースファイルを見る方法を学習します）。AndroidStudioに組み込まれたLintサポートは、CIでの起動に新たな課題をもたらし、多くの不快なバグがあります。
3. パフォーマンス：大規模プロジェクトのKotlinプラグインは貧弱です。 このトピックに関する問題により、すべての新しいリリースが閉じられますが、Javaはまだまだ先です。

アーサー・ドレモフは、これらおよび他の欠点の優れた概要を持っています 。



-公式のGoogleサポートはKotlinの使用にどのように影響しましたか。GoogleI / Oの前にコミュニティで何を見ましたか。



-2016年にDmitry Zhemerovの参加を得てAndroid開発者の会議を開催しました。人々がプロジェクトで新しい言語を試してみたかったのは明らかでしたが、不確実性が多くを止めました。 Googleのサポートは多くの人に道を開いたと思います。



一定の信頼の基礎が現れました。 とにかくJetBrainsに疑いがなければ、Android Studioと呼ばれるIntellij IDEAからの分岐点はますます脇に寄っていました（ここでは少しインスタントマジック、ここではクラスパスで少しハードコード...）これのために。 これで息を吐くことができます。



-KotlinをサポートするAndroid Studio 3.0は「そのまま」サポートされており、その他の技術革新は現在リリースされています-しかし、このリリースはあなたのために何かを変更しますか？



「正直なところ何も気づかなかった。」 いくつかのバージョンリリースで廃止されたKotlin IDEプラグインを事前定義リストに追加したように見えます。



Kotlinファイルの最初のAndroid Lintサポートにより、バージョン3.1で大きな変更が行われます。



-最近、2018年末にAndroidアプリケーションがJavaよりもKotlinでより頻繁に書き込みを開始するという予測がありました。そのような予測をどの程度信じていますか。また、将来Kotlinに何を期待しますか？



-予測は非常に現実的で、障害はありません。 人気のあるライブラリにはKotlinのサポートが追加されます（Androidサポートライブラリのnullabilityアノテーションは素晴らしい例です）。



開発者がコンパイラのパフォーマンスと開発ツールに焦点を合わせたKotlinバージョン1.2および1.3では、言語にほとんど変更がないことは既に知られています。 私にとって、これは良い兆候です。問題のある領域が立ち上がっています。



私はKotlin / Nativeに興味を持っていますが、私の現実では、プラットフォーム間でコードを手探りする最初の人になるとは思いません。 私たちは仲間のヒップスターからのサクセスストーリーを楽しみにしています！

エゴール・トルストイ

-Avitoでは何をしていますか？



-過去1年間、私はAvitoのすべてのモバイル開発を担当しました-エンジニアリング文化の構築、チーム開発戦略の開発と実装、アプリケーションの安定性とリリースの継続性の責任。 ある時点で、長い説明に入らないように、1つの単純な比phorを使い始めました。 モバイル開発が掘削機であると想像した場合、私の役割は、それが適切に機能し、故障なしで掘削でき、タンク内の燃料が終了しないことを保証することでした。



最近、状況が変わりました。 現在、私の責任範囲は、Avitoが動作するすべてのプラットフォーム（Web、モバイルWeb、iOS、Android）の技術開発を担当するチームです。 これらのプラットフォームのリリースサイクル、アーキテクチャの開発、開発者向けの便利なツールの作成、その他多くのプロジェクトを担当しています。 掘削機で比phorに戻ると、そのサービスに加えて、私は今、その運転手としても行動しています。



-テキストへのリンクを使用して、 Android Good ReadsとiOS Good Readsの 2つの電報チャネルを同時に実行します。 半深刻な質問に制約はありません。2つの世界を同時に積極的に監視するために、あなたの頭が裂けないのですか？ どのようにそれと一緒に住んでいますか？



-はい、それほど難しくありません。私はすべての興味深いリンクをPocketに保存し、定期的に読んでいます。 まあ、長い間、最も興味深いチャンネルに入れてください。 もちろん、私は多くのことを斜めから見ており、もし見たものが購読者にとって潜在的に有用であると思われるなら、私もそれを公開します。



-Avito全体のモバイル開発では、人が異なる世界を同時に見ている場合が一般的ですか、それともより一般的な部門が優先されますか？



-すべてが私たちと一緒にクールです。 多くの開発者は、プラットフォームと言語だけに焦点を合わせておらず、希望または必要に応じて同僚を支援します。 モバイル開発者が自分のタスクのバックエンドを記述すると、その逆が起こります。



T字型スキルの重要性を強く信じており、本当にクールな開発者にとっては、言語とフレームワークを変更することは問題ではありません。



-電報チャンネルに加えて、あなたは潜水艦ポッドキャストに参加し、Mobiusのスピーカーとして活動し、現在はプログラム委員会に参加していますか？それはすべて「自分のためだけ」ですか、これはあなたの仕事に有益な効果があると思いますか？



-基本的に自分のために-私はこれを行うことに本当に興味があります、それは話題をもたらす趣味です。 それ以外はすべて、クールな追加ボーナスが付いています。

彼らの専門能力開発のためのこれらすべての重要性は否定できません。 ポッドキャストへの参加は特に際立っています。おかげで、毎週何らかの形で私よりもかっこいい人を毎週知り、彼から私の知識やスキルを学んでいます。



-コードレビューについてお話されましたが、このプロセスはAvitoで具体的にどのように見えますか？



-Avitoの作業は数十のチームで並行して行われ、各チームは製品の機能の特定の部分または一部のユーザーニーズの充足を担当します。 各チームは可能な限り独立しており、その機能の実装の品質とタイミングについて完全に責任を負います。 コードレビューの段階で他の人への依存を排除​​するために、1つのチームのフレームワーク内でこのプロセスを終了しようとします。



これはコードレビューの1つの側面です。 もう1つは、それでも1つの製品を見ているということです。そのため、あるチームの人が別のチームが担当するコードを変更しなければならない状況がしばしば発生します。 混乱を防ぐために、コード所有者と特定のファイル、モジュール、またはフォルダーの変更をサブスクライブする機能を自動的に検出するシステムを積極的に開発しています。 これにより、発生した変更について知る必要がある人は見逃すことはありません。



-外部からは、Avitoには単純なアプリケーション（大まかに言うと、「カタログとディスプレイを用意する」）が必要なように思えるかもしれませんが、掘り下げてみると、すぐにニュアンスが見つかります。 自明でないタスクの例をもっと教えていただけますか？



-「シンプルなアプリケーション」に関するこれらのストーリーが大好きです。 Uberには通常1つの画面があり、100人以上のモバイル開発者が作業しています。 TARDISのようなAvitoアプリ：外から見ると一見思えるほど多くの内部。



私たちは仕事で直面する興味深いタスクについて話すのが大好きです。 いくつかの例：

• Lesha Shpirko、 バックエンド駆動UI
• Timur Yusipov、 ディップリンクを使用
• Artem RazinovとInessa Voronina、 モバイルデザインシステム

モバイルアーキテクチャとモバイルスピードの2つのチームは、モバイル開発の技術開発に密接に関与しています。 ここでは、モジュールアーキテクチャ、コンポーネントテスト、リリースの自動化、コンパイルの高速化など、ほとんど毎日のように重要な課題を抱えています。 そして、これについてもすぐに話します。



-あなたはメビウスプログラム委員会のメンバーであり、リハーサルで既にレポートを見ています-見逃してはならない特定のレポートに会議参加者の注意を引きたいですか？



-私が主にAvito の Max Sokolovのレポートに行くことをお勧めすることは明らかです。 彼は、他の製品の開発者に役立つ可能性のあるモバイルメッセンジャーを作成する上で非常に素晴らしい経験を共有しています。 Gleb Novikも見てください。 彼が私たちのポッドキャストもホストしているからではなく、まさに彼の報告のためです。 運用におけるサービス層の実装は爆弾です。このアプローチを非常に積極的に使用し、多くの利益を得ました。



とにかく、私たちが持っているすべてのレポートは非​​常にクールです。 選択は可能な限り厳しく、プログラムに残されたものは本当に最高でした。 当初、私はモスクワのメビウスの物語を強く信じていました。スピーカーの現在の構成と彼らの報告は将来の成功を裏付けています。



-ありがとう！ Moscow Mobiusでお待ちしていますが、今のところ、サンクトペテルブルクからのコードレビューに関するレポートを読者に思い出させます。