Androidブラウザーでコードの品質を制御する方法。 ヤンデックス講義

この講義の著者は、サンクトペテルブルクのAndroid開発チームYandex.Browserの責任者であるKonstantin Zaikin kzaikinです。 彼は、Android開発者とチーム全体のツールについて、またレガシーコードを処理し、大規模なプロジェクトを予定通りに公開し、コードの品質を改善する方法について話しました。





-友人、こんにちは。 あなた方の多くが今日来てくれてとてもうれしいです。 私はサンクトペテルブルクから来ました、私は約6年間Yandexで働いています。 私は、マップ、タクシー、メトリック、および検索に光を当てることができました。 2年間、Yandex.Browser for Androidの開発に取り組んでいます。



今日は、ブラウザで適切なコードを提供する方法を説明します。 Android用のブラウザはかなり面倒です。 原則として、ブラウザーのコアはChromiumのコアであり、Yandexサービスのコアを支えています。これらはすべてC ++で書かれており、プラットフォームアプリケーションは互いに埋め込まれたこれら2つのコアを中心に書かれています。 Yandex.Browserは、Windows、Mac、Linux、Android、およびiOSで使用できます。 基本的に、Androidのコード、特にJavaとKotlinについて説明します。





Yandexには200人のモバイル開発者がいますが、1つのブラウザー（デスクトップとその他すべて）に200人のユーザーがいます。 そのうち約30人がAndroidで書いています。 たくさんの人がいて、たくさんのコードを書きました。 行数では、Yandexで最大です。 そして、私たちのプロジェクトでは、あらゆる生物と同様に、自然な方法でコードが生まれ、生き、古くなります。あなたはそれを監視し、その健康を確保する必要があります。



コードの品質を確保するために適用したプロセスと、使用するツールについて順次説明します。 発生するバグには、解決できるいくつかのポイントがあります。 バグを作成することはできません。 開発者の開いているエディターウィンドウにあるバグを解決できます。 単体テストで見つけることができます。 後でテストまたは実稼働で見つけることができます。





これらのすべての段階でバグの最大数がキャッチされるか、まったく発生しないようにプロセスを調整しようとしました。 まず、コードスタイルをブラウザに記録しました。 大規模なプロジェクトでは、関連性があり、サポートされている記述されたコードスタイルがあることが非常に重要であり、コードスタイルMDとしてリポジトリに配置しました。 編集するには、プルリクエストを行う必要があります。そのため、通常のコードとして修正され、洗練され、チームが同意し、その後全員がこれらのルールに同意します。 または、新しい変更について議論し、作成しています。



チーム全体に共通のルールを修正することに加えて、Codestyleには教育機能もあります。 私たちには大きなチームがあり、たくさんの新しい人を私たちの場所に招待しています。 初心者は主にWikiを読み、多くの説明があり、Wikiが大好きです。 そして、コードスタイルを読んでください。 それを行う方法としない方法の例があります。 開発者は、コードスタイルに従って新しい機能を作成した後、それをコミットする必要があります。 受け入れられたルールから逸脱したコードをコミットできないようにするプリコミットフックを作成しました。 それはコードスタイルであり、静的分析が簡単にキャッチできるものです。 つまり、コードがコミットに入るのを防ぐために、gitはそのようなコードを受け入れることを拒否します。



その後、コードレビューを行うことは必須です。 私たちはBitbucketを使用しています。2人の同僚からのアップグレード後にのみ、どのコードでもリポジトリにアクセスできるというルールがあります。 2人の生きている人が来て、コードを見て、楽しんでください。 そして、このプルリクエストはまとまって、すべてのユニットテストに合格するはずです。 そして、多くのテストがあります。 そして、レビュアーが見て、すべての事前コミットフック。 一部の人は、どのくらい時間がかかるのだろうと思うかもしれませんか？ 結局のところ、大きなプロジェクトです。 プルリクエストを作成してからコードをリポジトリに入れるまでの最短時間は約30分であると誇らしく言えます。 これは、コードがマスターに到達する最小時間です。 私たちは長い間これに行ってきました。 また、通常のChromiumベースのブラウザがあります。 このようなブラウザーを作成するすべてのユーザーは、ビルド時間に関して非常に大きな問題を抱えています。 100万行のコードは、コンパイルする必要があり、長時間コンパイルします。 また、40万行のJavaコードをコンパイルしてテストを実行する必要があります。 これはチーム全体の作業の結果です。 私たちは皆、ローカルまたはTeamCityでビルドを待つ方法ではなく、プロセスについて結果をよりよく考えることができるように取り組んでいます。



重要なことは、30分がTeamCityの時間であり、ローカル開発者のビルドには30秒かかることです。 彼はすべての単体テストを実行するわけではなく、すべてのプラットフォーム、すべての組み合わせのすべてのアセンブリを収集するわけでもありません。 そして、TeamCityで収集します。 さらに、TeamCityはテストを実行します。 現在、この30分間で約20ユニットがあり、さらに、高品質のコードを確保するために、技術的なクォータが導入されています。 私たちはチームの時間の30％を、なんとか積み上げた技術的負債の返済に費やします。 チームの各スプリントの30％は、リファクタリング、既存のコードの改善、存在しないユニットテストの作成、またはツールの改善に取り組んでいます。



一般に、何かを改善するには、非常に重要なルールがあります。何かを改善する前に、それを測定する必要があります。 お願いします。 この製品を改善するために、高品質のコードと高品質の製品がどれだけあるかを理解するために、測定することを提案するものを提案してください。 たとえば、わかりやすいことを挙げましょう。テストカバレッジの何パーセントですか。 それでも理解すべきオプションはありますか？あなたのコードは高品質であるかどうか？ メソッドの行数。 クラスの数。 実行速度、アプリケーションの起動時間、リストのスクロール速度。 インターフェースの数は、原則として同じメトリックです。 消費電力は良いですか？ ビルド時間も。



あなたが呼んだすべてのために、私たちはツールを持っています。 1年前のように、プロジェクトの現在の状況と現在の状況を測定できます。 まず、実稼働環境でアプリケーションの状態を測定し、AppMetricaを使用します。これは、イベント、クラッシュ、アプリケーションの状態を監視できるパブリックサービスです。 AppMetricaを使用して、多くの技術的な指標を収集します。



次に、ClickHouseと独自の自作ツールを使用して、このデータからレポートを作成します。 このデータベースへのアクセスに投資し、特別な要求を行ったという事実だけのため、AppMetricaの平均的なユーザーよりも少し多くのユーザーがいます。 AppMetricaを使用すると、イベントの事実を収集できます。 イベントが発生しました-非常に多くの作品。 ただし、AppMetricaでは数値データを見ることができません。 たとえば、いくつかのオウムのエネルギー消費量を測定する必要があります。 また、現在のバージョンでは、さまざまなユーザーがこれらのオウムがどれだけ発生したかを理解する必要があります。 エネルギー消費によるユーザーの分布はどのように見えますか。 開始時刻によるユーザーの分布はどのように見えるか。 FPSのスクロール速度またはフレーム間の時間によるユーザーの分布はどのように見えるか。 そして、そのような数値データを収集し、分析するために、ヒストグラムを使用しました。



私の同僚は彼らについて非常によく話しました。彼らは「ヒストグラム」という言葉でYandexにいます。最初のビデオは、数値指標を収集して分析する方法についての私のチームの同僚の話です。 同じイリヤボギンは、これらの数値指標を収集する方法を詳細に伝えることができます。 そして、明らかな指標があります-未解決のバグ。 製品があり、テストがあり、ユーザーがいます。 彼らはバグを報告します。 バグが多いほど、製品の品質は低下します。 ブロッカーバグが多いほど、製品の品質は低下します。 ブロッカーのバグを未成年者と比較する...バグ、ゼロバグポリシー、条件付きで製品の品質を示す別のメトリックがあります。





これは、100万セッションごとのクラッシュ数を収集する実際のツールのスクリーンショットです。 あまりはっきりとは見えませんが、一番下のグラフはJavaでのクラッシュの数であり、100万セッションあたり約200です。 上位2つ...最初に、ネイティブでクラッシュが発生しました。Chromiumコアがあり、多くの「プラス」があるため、非常に多く発生しています。 最高は合計です。 通常、この指標を管理し、改善に取り組んでいます。 スケジュールが短いほど良い。 これは昨年のためであり、私たちは働き、改善しています。



同じこと、消費電力、スクロール速度、その他すべてに同じグラフィックがあります。





さらに、SonarQubeを実装し、非常に積極的に使用しています。皆さんにアドバイスします。 あなたがインディー開発者であるか、チームの一員であるかにかかわらず、あなたはそれを自分自身に置くことができます。 これは、静的コードアナライザーをねじ留めできるプラットフォームです。 オープンソースであり、無料であり、発生するほとんどすべてのプログラミング言語を分析できます。 私たちはそれを実装しましたが、現在はプロジェクトの健康指標を監視するために絶えず使用しています。 このスライドの内容を簡単に確認してください。 これはドキュメントに記載されているため非常に重要ですが、あまり明確ではありません。



これは実際のダッシュボードのスクリーンショットです。 たくさんのバグがあります。 セキュリティの脆弱性がいくつかあります。 これは、52.7％のテスト範囲です。 そして、非常に多くの単体テスト。 これはクールなようです。 現在、Yandexモバイルアプリケーションの最大のカバレッジがあります。 重複コードの割合も測定します。 興味深いことに、すべてのYandexモバイルアプリケーションに対してこのことを設定し、プロジェクト間で重複を監視できます。これも非常にクールです。ライブラリに入れる価値のあるコード部分を強調して、もう重複しないようにするのに役立ちます。



これをすべて収集する最も重要なメトリックは、すべての束でもあり、単一の理解可能な図で、どのプロジェクトが良いか悪いかを示しています。 これは技術的な義務です。私たちは、これらの問題がすべて解消されるように機能しなければならない204日間、条件付きデベロッパーの条件付き作業日を真空に置いています。 これは大きな負債か小さな負債だと思いますか？ 私たちには30人の大規模なチームがあります。 引き受けた場合、限られた期間この債務を返済します。 取ってきて始めたときにエピソードがありました-SonarQubeのすべてのブロッカーを修正しましょう。 そして、彼らはそれらを修正し始めました。



ただし、1つの機能があります。 これは特効薬です。 プロジェクトで静的解析を見つけたバグの数は問題ではありません。 新しいバグを作成しないことが重要です。 バグの修正。これは良いことであり、いつかそこにあるかのように長い間存在し続けます。 しかし、彼は起こりませんでした、彼はテストで見つかりませんでした、彼の単体テストは見つかりませんでした。 ほとんどの場合、彼は撃ちません。 そして、古いバグの修正は、新しい実際のバグを持っているという事実につながり、実際のクラッシュにつながります。



主なことは、古いバグを修正することではなく、新しいバグがないことを確認することです。 ダッシュボードは別の指標です-過去14日間で1日の新規債務を蓄積しました。 はい、できますが、非常に穏やかです。 技術的な負債比率の指標があり、コード全体のボリュームに対する負債の割合は着実に減少しています。 そして、これは私たちがすべてを正しく行っていることを示す最高の指標です。





画面上の実際のスクリーンショットからの切り抜き。 これと同じSonarを使用すると、プルリクエストにコメントを追加できます。 2人のレビュアーが来てコメントを残し、さらに3人目のレビュアーがロボットを入れます。 彼は、明らかな問題、コードスタイル、コード設計に関するコメントを残し、セキュリティの脆弱性を発見しました。 人々は彼を愛しています。 新しい負債は追加されません。



さらに、Sonarでは既存のバグを確認できます。 コードベース全体を表示する非常に便利なビューアがあり、各行について、どの問題があるか、いつ追加され、何が行われたかを確認できます。 著者に来て、次のように言うことができます。私の友人、過去2週間で5つのブロッカーを追加しました。 原因に対処して排除します。 私たちは常に問題を根本的に解決し、そのような問題の可能性を排除しようとします。 原則として、バグを許容できないように、何らかのツールを準備するか、作成します。



テストの作成に非常に積極的です。 テストが大好きです。 最近、彼らはそれらを書くことで大きな進歩を遂げました。





JUnitを使用して実行されるテストは非常に多く、これらはホストマシン上で実行されるテストであり、JavaとRobolectricのみです。 そして、Android Instrumentation Tests。 今はたくさんあります。



この数のテストを作成しながら、いくつかの段階を経ました。 テストを書く必要があります。誰もがテストを書きます。高品質の製品が必要です。書きましょう。 私たちは本当にたくさんの問題をかき集めました。 新しいテストを作成します。古いものは常に壊れており、サポートに多くの時間を必要としますが、バグは見つかりません。 コードを変更すると、数十のテストが中断され、テストを修正します。 幸いなことに、私たちはこの危機に合格しました。テストはコードのドキュメントを提供し、開発者にコードが正しく記述されているという自信を与えます。 現在、チーム全体がテストの作成方法を学び、非常に積極的にテストを作成しています。 前のスライドは、新しいコードのカバレッジが55％であることを示しています。 これは古いものよりも多く、正しい方向に進んでいます。 さらに高くなると良いのですが、今のところは。



私たちはRobolectricを積極的に使用しています。これに満足しています。これにより、濡れたり、実際のAndroidを交換したりすることができますが、同時にテストをはるかに高速に実行できます。 9000回のテストはたくさんあります。 これらのうち、約600がエミュレータで実行され、残りのテストはホストマシンで実行されます。 ビルドエージェントは高速で、16コアであり、すべてが迅速かつ簡単です。 エミュレーターを上げると、インストルメンテーションテストが長時間にわたって痛みを伴い実行され始めます。 これを回避しようとしています。 ロボエレクトリックはとても良いです。



インターフェイスも積極的に使用しています。 私たちは純粋なコードのサポーターであり、制御の反転、依存関係の注入を積極的に使用し、インターフェイスを使用して、作成するコードからプラットフォームを分離します。 Robolectricを否定する人々がいます。彼らはインターフェースだけが必要であり、Robolectricは悪であると言います。 私たちは合理的なアプローチの支持者です。 私たちは積極的にMockitoを使用し、意図的にPowermockをカットしました。これは悪いテストスタイルを引き起こしたためです。 これは悪であり、静的なファイルやファイルをシンクすることができ、一般的にすべてを壊し、悪いアーキテクチャを引き起こします。



私たち全員が文書化するこのスライドの主な要約は、他のものと同じです。 「やらない」というスタイルで録音します。 テストの匂いがあります。別のページでは、「非常に悪いが、非常に良い」モードでテストを書くときに発生する典型的な問題が修正されます。 そして、新しい開発者は、来るとき、このことは大いに役立つと言います。なぜなら、それをしない方法の例だけでなく、多くの人がそれを行う方法の右側を見ているからです。 推測できないトリックやツールが数多くあります。それらを経験で理解するか、経験から学ぶ必要があります。 そしてここで、私たちは彼ら全員に銀の大皿で伝えています。





このグラフはそれ自体を物語っています。 このデータは、昨年6月から現在までのものです。 テストカバレッジに取り組み、テストを作成しました。 しかし、もっと重要なことは、私たちはじっとしていなかった、成長したということです。



単体テストに加えて、自動テストを使用します。 これは、アプリケーションをブラックボックスとしてテストするテストの条件付きの名前です。 デバイスまたはエミュレーターで起動し、ゴムの指で条件付きロボットがリストをスクロールし、ボタンを突いて、標準シナリオに従ってアプリケーションを中断しようとします。 自動テストでは、手動のテスターに​​代わって、スクリプトを何度も繰り返すよりも有意義なことをしたほうがよい生きている人々がいます。 回帰を加速し、新しいリリースが適切であり、本番環境に移行できることを確認しています。 現在、3週間ごとにリリースされており、このメリットのかなりの部分は、手動テストを自動テストに移行したことです。 テストの60％以上が自動化されています。





私たちの自動テストはAppiumで書かれており、これはYandexのかなり標準的なツールです。Webをテストした人と一緒にWebをテストすることから生まれました。 これで、Appiumで約3000のテストを作成し、25のエミュレーターを実行することができるインフラストラクチャを展開しました。 しかし、それでもすべてが非常にゆっくりと判明します。 現在、回帰の起動には数時間かかり、ビルドごとにこれを継続的に行うことはできません。 これを行うのに十分なリソースとハードウェアがありません。 そして、これらのツールだけがオープンソースに非常に積極的に貢献しています。YandexQA Toolsの GitHubには多くのツールがあり、これらすべてを置くアクティブなコミュニティがあります。



ここで私たちが苦しんでいると言うことができる別のものです。 当初、自動テストは実際には開発者ではなく個人によって作成されました。 ハンドブレーキがあり、自動化する必要があります。 最初の反応-ハンドブレーキをロボットに置き換えて書き込みましょう。ブラウザとは別に、コードが書かれている場所にリポジトリがあります。 テスターのように、同じJUnitであるJavaでコードを書いているようです。 しかし、最終的には、チームを結合し、統合して、すべての開発者が自動テストを作成できるようになりました。 自動テストがどのように書かれているかを誰もが知っているように、私たちは特別に人を交代させます。 自動テストでは、主な痛みは、それらが常に落ちて壊れ、常に赤いことです。





この問題を解決する1つの方法を紹介します。 これは、そのうちの1つである私のオフィスのテレビです。 私たちは一般的にグラフィックス付きのテレビが好きです。 しかし、これは自動テストに関するテレビです。 緑-正常に完了、黄色-既知の理由で薄片状、赤-未知の理由で。 私たちは常にこれを見ています。 私たちは、常に変化し、テストで何が起こるかを監視する別のアテンダントを割り当てました。 落ちたテストが腐らないようにすることは非常に重要です。 すぐにテストを取り上げて理由を見つけなければ、最終的にこのテストは終了し、開発に費やした労力は無駄になります。 そのため、すべてのテストが反転する理由を常に監視し、把握しています。 これらのテストでは、実際にリグレッション、本番コードで発生する問題を見つけます。 コードを実稼働に移行することはできません。自動テストですべてを見つけ、それを確認するためにハンドブレーキをかけません。





また、エスプレッソも積極的に使用しています。 , Espresso , Appium, Espresso . , . — . Espresso . , . , . - . . , .



, Espresso, Kotlin, DSL, , , . , .



— . . — .





, . , , . . , , , . - . , .



- — . , , , , . , . , .