みなさん、警告ってきちんと対応してますか？
この記事では私が色々なプロジェクトで警告を0件にしていった経験を踏まえた警告の修正方針などについてまとめてみました。

警告の確認方法

Android Studioでは、Analyze → Inspect CodeからInspectionを実行することができます。

Whole projectでInspectionを実行してみると、警告対応をきちんとやれてないプロジェクトでは物凄い数の警告が発生していることでしょう。

警告対応方針

「これだけ警告が出てても問題なく動くのなら、対応しなくてもいいのでは？」という意見が聞こえてくるかもしれません。
特に企画やPMあたりには警告対応の重要性を理解してもらえないこともあると思います。
警告を対応していくにあたっては、こういった警告対応に対する無関心さと戦うことから始めねばなりません。
そこで、まずは警告の対応における方針を以下の中から選択することにしましょう。

通常のアップデートにこっそり警告修正を混ぜ込む
毎回PMに確認を入れてから警告を修正する
1と2の折衷案（ユーザ影響がなさそうな修正は混ぜ込み、ユーザ影響がありそうな修正はPM確認する）
その他

どのような方針を取るかはチームによるとは思いますが、対応するのに工数がそこそこかかるような場合はPM確認が必要になるケースも多々あると思われます。
その場合は、警告を対応しないことによるデメリットを強調して伝えることをお勧めします。
自分の場合は以下のようなデメリットを羅列して伝えることにしています。

警告を無視していると、ユーザに悪影響を及ぼす警告を見逃すことになる（クラッシュやアプリに必要な権限の取得ができないなどの致命的な問題が発生しうる）
適切に警告が対応されていないプロジェクトでは、エンジニアのモチベーションが下がる
適切なUIなどの指示も含まれているため、Material DesignやGoogle推奨の設計やUIに沿っていない箇所を見逃すことになる

以上のような形でデメリットを伝達し、なんとかPMに許可をもらえて初めて警告をどういう順序で解消していくかを検討するフェーズに入ります。

警告の対応の前に

Pull Requestで警告が出るようにしよう

lintチェックを毎回手動でチェックするのはしんどいものです。
https://github.com/loadsmart/danger-android_lint などのツールを利用し、Pull Requestでdangerを走らせて警告チェックがなされるようにしておくことをお勧めします。

IDEの力を借りて警告を修正しよう

未使用警告や単純な置換で済む警告なんかはIDEの力で置換や削除を行ってくれます。
コード上の警告箇所でoption+enter（winならAlt+Enter)からクイック修正をできる他、以下の画像のようにInspection Resultsに表示された対象の警告の詳細を見ると同じクイック修正のアクションが表示されているのでそちらから修正することも可能です。

IDEの力をなるべく活用して警告の修正をしましょう。

警告の対応順序

さて、山程存在する警告を見ているとゲンナリしてやる気を失ってしまいかねません。
警告を0件にしていくのに最も大事なのはエンジニアのモチベーションだと私は思います。
なので、まずは警告の総数と種類をガッと減らしていくのが望ましいですね。
そこで私はいつも以下のような順序で警告の対応しています（多少前後したり、目についたものを先にやることはあります。モチベーション優先で決めましょう）。

1. 未使用の警告に対応する

未使用の変数やパラメータもそうですが、未使用の関数やクラスがあれば真っ先に排除しましょう。
無駄コードが存在すると鬱陶しいですし、使ってないのに別の警告が中に含まれたりしています。
ただし、本当に利用していないかどうかは文字列検索などをしてみないとわかりません。
確実に利用していないことを確かめながら消していきましょう。

2. inspectionのScope調整

Preferences＞Appearance & Behavior＞Scopeから、Inspectionの対象となるScopeを作ることができます。
例えばgradle関係や.editorconfigなどをtypoチェック対象から外したい、といったケースはよくあると思いますが、こうしたScope調整は先に済ませてしまうのがおすすめです。
私はtypoチェックの対象以外にも、shrinker、syntaxのScopeを作ってInspectionの範囲から除外しています。

3. プロジェクト固有の辞書を追加する

typo警告は多くの場合、プロジェクト固有の単語などで発生しています。
そこで、プロジェクト用の辞書ファイルを作成し、単語のリストを作成してしまいましょう。
ここで注意すべきなのは、各個人で適用するための共通のdicファイルを用意するという点です。
Android Studioのイケてない仕様により、typoチェックに使われる辞書は通常だと個人個人での作成になってしまい、そのdicファイルは自分の氏名での命名になっています。
そこでリポジトリに共通のdicファイルを作って配置しておき、各々の環境でそのdicファイルを適用するという構成にすると良いでしょう。

4. 簡単な置換で済ませられる警告の対応

例えばアップデートで不要になったnullableをnon-nullに変更するであるとか、valでいいところをvarにしている警告であるとか、そうした修正理由も修正内容も明らかで簡単なものは一気に置換してしまいましょう。
おそらく山程警告が残っているプロジェクトでも、その多くはこうした一括対応で済むような警告であることが大半だと思われます。
ただし、簡単に置換できるからと一つのコミットで複数種類の置換をしないように注意しましょう。
一種類の置換につき一つのコミットにしておくとコードレビューも一瞬で終わるのでお勧めです。

5. 簡単ではないが、置換で済ませられる警告の対応

この系統には、例えばアイコン系の置き換えがあります。
通知用のアイコンは白にしなさいとか、xxdpi用の画像がないとか、そうした簡単に一括対応はできないものの適切に置き換え・追加すれば済むものも多数存在します。
こうしたものも修正理由・修正内容ともに明らかであるため、適宜対応しましょう。

6. 対応できない、あるいは対応する必要がない警告を抑制する

ViewModelFactoryのUnchecked castや、SharedPreferenceのキーで現在は使っていない項目の未使用警告といった、警告を意図的に無視する必要がある箇所は見つけ次第警告を抑制しましょう。
基本的には該当箇所の前の行に @Suppress("警告名") や //noinspection 警告名 を記載することで警告を抑制できます。

7. 対応を後回しにする警告をタスク化する

アクセシビリティ関係などのUXに関わる警告は、通常デザイナーやPMとすり合わせを行なった上で修正が必要になります。
デザイナーやPMとのすり合わせに時間がかかって大変な場合は、一度警告を抑制した上でタスクとして管理することをおすすめします。
時間がかかる割に緊急ではない後回し系タスクについては、より重要な警告をきちんとキャッチできるように一旦警告がなくなる状態にしておくといいでしょう。
ただし、こうしたタスクは往々にして優先順位が下げられて対応されないことも多々あるので、きちんと対応時期を決めたり、エンジニア主導で改善できる体制を作るなどの対応をおすすめします

8. 残りの警告の対応

ここまでくると、残りはdeprecatedやAndroidManifestの修正といった気軽に対応しづらい項目が残ってきます。
経験上は数十個くらいはこうした警告であることが多いです。
こうした警告はなるべく早く正しく修正しておく必要性があることも多いので、確実に一つずつ対応していきましょう。

最後に

DeNAでは今年、2021年度新卒エンジニア・2022年度新卒内定エンジニアの Advent Calendar もあります！本 Advent Calendar とは違った種類、違った視点での記事をぜひお楽しみください！

▼DeNA 2021年度新卒エンジニア・2022年度新卒内定エンジニアによる Advent Calendar 2021 https://qiita.com/advent-calendar/2021/dena-21x22