AndroidAudit。 犯罪現場としてのAndroidアプリ

翻訳者から：プロセスと開発の結果を評価することは、重量の尺度が使用されない場合、かなり主観的なものです。 タブやスペース、gitまたはmercurial、mavenまたはgradleなど、長い間議論することができますが、そのような論争はそれでもフレーバーやいくつかの特別なケースに陥ります。 もう1つは、プロジェクトの均一性の遵守です。これはすでに測定可能な量です。

悪い方法論は、方法論なしよりも優れています。

一般的なことに加えて、Android専用のモバイル開発にのみ固有の固有のものがあります。 KarumiのPedro VicenteGómezSánchezは、主な技術分野を骨ごとに分解し、Androidプラットフォームの開発の正確で客観的な評価のために正確な質問をしました。 タスクが表示される場合：他の人のプロジェクトを評価するには、その方法論を使用することをお勧めします。 この方法論をチェックリストとして使用しました。 結果は、非専門家にとって非常に理解しやすい文書でした。各カテゴリの前には、0〜1の正確さを順守するという特定の価値があります 。





iOSおよびAndroidアプリケーションの技術監査は、Karumiでの日常業務の不可欠な部分となっています。 一見シンプルに見えますが、このようなチェックの実装には、検討する価値のある詳細がたくさんあります。 このドキュメントでは、監査中に最も重要と考えるものを検討し、それを技術分野に分割します。



バージョン管理システム



バージョン管理システムを使用するかどうか、どのシステム、どのように作業プロセスを編成するか-これにより、開発プロセスについて多くのことがわかります。

• IDEメタデータファイルおよびその他の無関係な要素がリポジトリに分類されないように、適切に構成された*無視ファイルがありますか？
  
  
• サードパーティのライブラリは外部依存関係として構成されていますか、それともストレージにありますか？
  
  
• コミットに関して簡潔で表現力豊かなコメントを使用していますか？
  
  
• コミットのサイズは適切ですか？
  
  
• コミット内のすべてのファイルは同じ問題または機能に関連していますか？
  
  
• 「機能ブランチ」や「git-flow」などのブランチスキームを使用していますか？
  
  
• 支店名は十分な情報を提供していますか？
  
  
• マスターでコードをマージする前にプルリクエスト/コードレビューを使用していますか？
  
  
  • PR（プルリクエスト）を検討する際に注意する必要があることに関して規制はありますか？
    
    
  • 各PRの平均コメント数は？
    
    
  • 各PRを考慮する人数
    
    
  • マージするためにPRにどれだけ「+1」する必要がありますか？
    
    
  • ブランチを閉じる責任は誰にありますか？
  
  
  
• リリースごとにリリースブランチを使用していますか？
  
  
• ステージングプロセスはどのくらい開いていますか？
  
  
• リリース候補をリリースする前に、リリース候補に対していくつの修正を行いますか？
  
  
• アプリケーションの公開バージョンの正確なコードに切り替えることは可能ですか？
  
  
• 昨年リリースした修正プログラムの修正はいくつですか？
  
  
• マスター/開発ブランチにマージする前にコミットをマージ（スカッシュ）しますか？
  
  
• マスター/開発ブランチはいつでもリリースの準備ができていますか？

ビルドツール



決定要因は、開発者のマシンおよび他の外部システム（たとえば、継続的インテグレーションシステム）でアセンブリプロセスを開始できるかどうかです。

• プロジェクトで使用されているライブラリの数は？
  
  
• プロジェクトはモジュールに分割されていますか？
  
  
• MavenまたはGradleモジュールは依存関係を解決するために使用されていますか、またはローカルの.jarファイルが使用されていますか？
  
  
• プロジェクトは、危険な距離にある.dexファイルのメソッド数の制限に近づいていますか？ それとももうすでに？
  
  
• プロジェクトで不要なライブラリを使用していますか？
  
  
• マルチデックスは使用されていますか？
  
  
• 外部依存関係はすべて最新バージョンに更新されていますか？
  
  
• すべてのサードパーティライブラリライセンスが尊重されていますか？
  
  
• 廃止またはサポートされていないサードパーティのライブラリが使用されていますか？
  
  
• 最小SDKは技術仕様（製品の説明）の要件の対象ですか？
  
  
• ターゲットSDKは関連していますか？
  
  
• ProGuardまたは他の難読化ツールが使用されていますか（難読化）？ 電源が入っていて正しく構成されていますか？
  
  
• キーストアの資格情報とGoogle Playの資格情報は安全な場所に保存されていますか？
  
  
• アプリケーションキーストアと資格情報は安全な場所に保存されていますか？
  
  
• ビルドタイプは適切に構成されていますか？
  
  
• フレーバーは正しく使用されていますか？
  
  
• リリースビルドタイプは正しく構成されていますか？
  
  
• バックアップオプションは有効になっていますか？
  
  
• リントは有効ですか？ テストに合格しましたか？
  
  
• 静的解析ツールはありますか？ それは構成され、テストに成功しますか？
  
  
• チェックスタイルはありますか？ それは構成され、テストに成功しますか？
  
  
• アプリケーションIDとバージョン名/コードは正しく構成されていますか？
  
  
• IDバージョン管理の構造または戦略を使用していますか？
  
  
• 継続的統合ツールが使用されていますか、正しく構成されていますか？
  
  
• リリースプロセスは自動化されていますか？

Androidリソースの使用



Androidの世界にはさまざまなデバイスがあり、それぞれが独自の画面サイズ、機能などを備えています。 デバイスに関係なく、ユーザーがアプリケーションを最適に使用できるように、いくつかのAndroidツールを非常に慎重に使用する必要があります。

• 密度、フレーバー、およびビルドタイプに不足しているリソースはありますか？
  
  
• アプリケーションには、技術仕様に従って異なるピクセル密度（密度）の画面が必要ですか？
  
  
• アプリケーションは、ドロアブル/ミップマップ、フォント、またはベクターリソースを使用しますか？
  
  
• 欠落している翻訳はありますか？
  
  
• 翻訳プロセスは自動化されていますか？
  
  
• 翻訳にはデフォルトでどの言語が選択されていますか？
  
  
• アプリケーションはサードパーティのフォントを使用していますか？
  
  
• アプリケーションは、文字列リソースファイル内の構成値を使用しますか？
  
  
• リソースに統一名を割り当てることに同意はありますか？
  
  
• デバイスのハードウェアに関連する構成パラメーターはありますか？正しく構成されていますか？
  
  
• タブレットはサポートされていますか？

Androidレイアウトの使用



先ほど言ったように、世界にはさまざまなAndroidデバイスがあり、それぞれが独自のサイズと画面密度を持っています。 決定要因は、Androidレイアウトの適切な使用です。

• アプリケーションのレイアウトのレイヤー数に起因するパフォーマンスの問題はありますか？
  
  
• テーマとスタイルを使用していますか？
  
  
• 「include」タグを使用してレイアウトを再利用しますか？
  
  
• レイアウトで正しいタイプのグループ化を使用していますか？
  
  
• さまざまな画面サイズがレイアウトに含まれていますか？
  
  
• レイアウトとウィジェットに割り当てられた名前を統一するために、命名規則が使用されていますか？
  
  
• リストはListViewまたはRecyclerViewを使用して実装されていますか？
  
  
• Androidサポートライブラリは正しく使用されていますか？

アクセス権



アプリケーションの可能なアクション（許可）の要求は、アプリケーションに対するユーザーの信頼を高め、他のサービスとの「透過的な」統合によりその機能を拡張します。

• 要求されたすべての許可は本当に必要ですか？
  
  
• 許可は意図的に使用されていますか？
  
  
• 不足している権限はありますか？
  
  
• ターゲットSDKが23より大きい場合、互換性許可システムから「危険な許可」が要求されていますか？
  
  
• 使用する際に許可が必要ですか？
  
  
• 許可が必要な理由を説明するユーザーフィードバックはありますか？

セキュリティの問題



開発者として、アプリケーションのセキュリティを意識する必要があります。 ユーザーのデータが漏洩したり、セッションが盗まれたりすることは望ましくありません。

• HTTPクライアントはHTTPSを使用するように構成されていますか？
  
  
• HTTPクライアントは、ビルトイン証明書（証明書のピン留め）とHMACでの認証メッセージを使用するように構成されていますか？
  
  
• アプリケーションはユーザーの機密情報を保持しますか？ どこ？
  
  
• アプリケーションは、内部ストレージシステムの外部に情報を保存しますか？
  
  
• リリースのビルド時にアプリケーションはログを記録しますか？
  
  
• アプリケーションコードは難読化されていますか？
  
  
• アプリケーションは、Androidコンテンツプロバイダー、レシーバー、またはサービスを他のアプリケーションに提供しますか？
  
  
• デバッグ可能オプションはリリースビルドで無効になっていますか？

プッシュ通知



プッシュはいつでもユーザーに通知するための優れたメカニズムですが、これは一見思われるよりも複雑な問題です。

• プッシュ通知システムの実装にサードパーティのライブラリが使用されていますか？
  
  
• GCMシステムは、アプリケーションに情報を伝えるために使用されますか、それとも単にユーザーにメッセージを表示するために使用されますか？
  
  
• プッシュ通知を受信したとき、アプリケーションはどのように動作しますか？
  
  
• プッシュ通知に関連する情報が予期したものではない場合、アプリケーションはどのように動作しますか？
  
  
• 互換性APIを使用して通知が表示されますか？

性能



パフォーマンスは非常に重要です。 高価なデバイスで遅いアプリケーションを使用したい人はいません。 生産性はお金です。

• アプリケーションにメモリリークはありますか？
  
  
• LeakCanaryなどの開発アセンブリでメモリアナライザーが構成されていますか？
  
  
• 開発ビルドでAndroid Strict Modeが接続および構成されていますか？
  
  
• アプリケーションでストリームはどのように使用されますか？ 非同期タスク、インテントサービス、またはその他のサードパーティライブラリを使用していますか？
  
  
• バックグラウンドスレッドの数はパフォーマンスの問題を引き起こしますか？
  
  
• スケジューラポリシーを使用しますか、それともオンデマンドでスレッドを作成しますか？
  
  
• Android Dozeモードをサポートしていますか？
  
  
• ネットワーク状態に関連するイベントや、オペレーティングシステムからのその他の繰り返しイベントは聞こえますか？
  
  
• メインスレッドは、ユーザーインターフェイスコードに関連するタスクにのみ使用されますか？
  
  
• アプリケーションにキャッシュポリシーはありますか？
  
  
• HTTPクライアントはタイムアウトを使用するように構成されていますか？
  
  
• HTTPクライアントはGZIPを使用するように構成されていますか？
  
  
• アプリケーションのユーザーインターフェイスは毎秒60フレームで動作しますか？
  
  
• メモリが多すぎるカスタムビュー、またはUIスレッドで「高価な」タスクを実行するカスタムビューはありますか？
  
  
• ローエンド（低コスト、非生産的）デバイスでアプリケーションをテストしていますか？
  
  
• スクロールするリサイクラビューは「減速」していますか？
  
  
• 画像のダウンロードに使用されるサードパーティのライブラリはありますか、それとも独自のソリューションがありますか？
  
  
• 画像は画面に合わせて拡大縮小されていますか、それとも特定のデバイス画面にすぐに読み込まれますか？
  
  
• メモリは賢明ですか？
  
  
• 「静的」修飾子はJavaで正しく使用されていますか？
  
  
• すべての画像処理タスクは、一度に複数の画像を処理できますか？
  
  
• 統計システムはバックグラウンドスレッドで動作し、正しい優先度で構成されていますか？
  
  
• リリースビルドでコードは最適化されていますか？

Javaパッケージの構造



優れたパッケージ構造は、コードをよりスケーラブルにします。

• パッケージは、機能（機能）または概念（ログインとユーザーなど）によってコードを分離するために使用されていますか？
  
  
• パッケージ内の実装の詳細を隠すためにJava可視性修飾子が使用されていますか？
  
  
• すべてのパッケージはルートパッケージから出ていますか？
  
  
• テストディレクトリはソースフォルダの構造を繰り返していますか？
  
  
• 同じパッケージ構造を使用して異なる機能が編成されていますか？
  
  
• クラスは正しいパッケージにありますか？
  
  
• パッケージの統一規則は尊重されますか？
  
  
• ルートパッケージの名前は会社名に関連付けられていますか？

コードスタイル



スタイルに関して一貫したコードベースは、エンジニアがコードを読みやすくするのに役立ちます。 エンジニアは自分が書いたよりもはるかに多くのコードを読み取るため、これは重要な概念です。

• コードスタイルは均一ですか？
  
  
• ハンガリー記法を使用していますか？
  
  
• Checkstyleツールはありますか？ 構成されて機能していますか？
  
  
• Javaコードはコードスタイルと一致しますか？
  
  
• タブまたはスペースを使用しますか？
  
  
• クラスの名前は正しいですか？
  
  
• インターフェイスプレフィックスとして「I」を使用しますか、または実装サフィックスとして「Impl」を使用しますか？
  
  
• 正しい変数名を使用していますか？
  
  
• フィールドに正しい名前を使用していますか？
  
  
• メソッドに正しい名前を使用していますか？
  
  
• メソッド属性と可視性修飾子は適切に使用されていますか？
  
  
• コードは英語で書かれていますか？
  
  
• Javadocを使用していますか？
  
  
• コードコメントを書いていますか？
  
  
• リテラルの重複を避けるために定数または列挙を使用しますか？

オフライン実装



優れたオフラインパフォーマンスを保証することは、アプリケーションの特徴です。

• インターネット接続がないときにアプリケーションを使用できますか？
  
  
• 低速ネットワーク接続中のアプリケーションの動作は何ですか？
  
  
• ネットワーク障害のために要求が失われた場合のアプリケーションの動作は何ですか？
  
  
• 接続が復元された後、アプリケーションデータの変更はバックエンドと同期されますか？
  
  
• ネットワーク接続のタイムアウトは設定されていますか？
  
  
• HTTPキャッシュポリシーは設定されていますか？
  
  
• ユーザーセッションは自動的に復元されますか？

建築



コードの観点から見ると、アプリケーションアーキテクチャは監査の一部であり、アプリケーションの理解を深めます。 アプリケーションアーキテクチャのレビューでは、SOLIDおよびClean Codeの原則に関連する概念に焦点を当てます。



プレゼンテーション層の実装

• GUI（グラフィカルユーザーインターフェイス）の実装に関連するパターンはありますか？ モデルビュープレゼンターまたはモデルビューViewModelは、最もよく使用される2つのアプリケーション開発テンプレートです。 それらは正しく実装されていますか？
  
  
• プレゼンテーション層の実装は、ビューの実装に関連していますか？
  
  
• ビューの実装はモデルの実装に関連していますか？
  
  
• プレゼンテーション層にはビジネスロジックが含まれていますか？
  
  
• ビューの実装はAndroid SDKツールを正しく使用していますか？
  
  
• ビューの実装を簡素化するために、サードパーティのライブラリを使用していますか？
  
  
• 異なる機能の実装は、個別のアクティビティまたはフラグメントで分割されていますか？
  
  
• ユーザーインターフェイスの動作は均一ですか？
  
  
• カスタムビューを使用してユーザーインターフェイスコードを再利用しますか？

ドメイン実装

• 別のドメイン層がありますか、またはビジネスロジック全体がプレゼンテーション層に実装されていますか？
  
  
• ドメインルールとさまざまなアプリケーション要件は、ビジネスロジックのメインオブジェクトで表現されていますか？
  
  
• ドメイン層は、OOP原則を使用して実装されていますか？
  
  
• ドメインレイヤーはAndroid SDKまたはサードパーティライブラリに関連付けられていますか？
  
  
• ドメイン層はプレゼンテーション層に接続されていますか？
  
  
• ドメインモデルは「貧血」ですか？
  
  
• シックドメインモデルを使用していますか？
  
  
• コードは疎結合に基づいており、同時に相互にうまくやり取りするコンポーネントに基づいていますか？
  
  
• エラー処理は、例外またはその他のエラー処理メカニズムを使用して実装されていますか？
  
  
• データは異なるレイヤー間でマッピングされていますか？
  
  
• 外部コンポーネントのアーキテクチャ（データベーススキーマやJSON解析など）は、ドメインモデルのアーキテクチャに影響しますか？
  
  
• 開発者は継承を悪用しますか？
  
  
• コードが重複していますか？
  
  
• 依存関係注入ライブラリまたは構成済みのサービスロケーターはありますか？
  
  
• クラスとメソッドの複雑さは高すぎますか？

APIの実装

• APIの実装はAndroid SDKに関連付けられていますか？
  
  
• ネットワーク層の実装に使用されるHTTPクライアントまたはライブラリが原因で、実装の詳細のAPIを介した「リーク」はありますか？
  
  
• APIクライアントは正しいヘッダーを送信しますか？
  
  
• さまざまなHTTP応答に対するクライアントAPIの動作は何ですか？
  
  
• クライアントAPIは認証メカニズムを実装していますか？
  
  
• セッション再開プロセスは正しく実装されていますか？
  
  
• JSON難読化のサポートはありますか？
  
  
• APIの実装は異なるクライアント間で共有されていますか？

ストレージ実装

• 情報はどこに保存されますか？
  
  
• リポジトリへの情報の読み書きにトランザクションが使用されていますか？
  
  
• ユーザーの機密情報の保管は安全ですか？
  
  
• ストレージレイヤーはサードパーティのライブラリを使用していますか？
  
  
• 実装の詳細は、ストレージレイヤーを通じて「漏れ」ますか？
  
  
• テーブル/スキーマは正しく設計されていますか？
  
  
• ストレージへのリクエストは最適化されていますか？
  
  
• データを適切な場所に保存するためにAndroid SDK APIが使用されていますか？ データはデータベースに保存され、設定と小さなデータは共有設定とディスク上のファイルに保存されますか？

テスタビリティ

• アプリケーションにはテストがありますか？
  
  
• アプリケーションはテスト可能ですか？
  
  
• アプリケーションはさまざまなタイプの（ユニット/統合/エンドツーエンド）テストを使用していますか？
  
  
• テストの名前は正しいですか？
  
  
• テストはプロジェクトをカバーするのに十分ですか？
  
  
• テストに過剰な仕様がありますか？
  
  
• リードタイムは妥当ですか？
  
  
• コードカバレッジが低すぎますか？
  
  
• 無視されたテストはありますか？
  
  
• 不安定なテスト（不安定なテスト）はありますか？
  
  
• テストに最新のフレームワークを使用していますか？
  
  
• アサートなしのテストはありますか？
  
  
• テストと生産コードは同じ開発者によって書かれていますか？
  
  
• QAチームはありますか？
  
  
• テストの一部を自動化するQAチームはありますか？
  
  
• 継続的な統合システムはありますか？
  
  
• builders, factories mothers, , ?
  
  
• (assertions) ?
  
  
• ?
  
  
• , ?
  
  
• ?
  
  
• - monkeyrunner?
  
  
• - TDD BDD ?
  
  
• Java, (test cases)?

さまざまな技術分野に関連するこのリストに基づいて、アプリケーションの品質を評価できます。他にも考慮すべき点がありますが、このリストには最も重要な点が含まれています。アプリケーションに関するこれらすべての質問に正しい答えを提供できますか？



投稿者：ペドロ・ビセンテ・ゴメス・サンチェス。