f:id:vasilyjp:20180927112657j:plain

Androidエンジニアの @nissiy です。Androidが発表されてからもうすぐ10年になろうとしています。長いですね。
実はAndroid版IQON、今年の4月でリリースしてから丸5年を迎えます。ここまで長くサービスを続けられて、かつ3年連続でベストアプリをいただけたのは、使ってくれているユーザーの方々のおかげであると日々感謝しています。
この5年で様々な追加機能の開発を行ってきました。新機能を1つ追加する度に、古い機能を1つ削除することを徹底して開発を進めてきたものの、長く開発を続けているのでそれなりに巨大なアプリになっています。

今回はAndroid版IQONを長く開発し続けるためにチーム内で徹底しているルールをいくつか紹介したいと思います。
当たり前な話ばかりですが、大きくOSのアップデートを繰り返すAndroidのアプリ開発に取っては大事な話ばかりですので、少しでも参考にしていただけると嬉しいです。

f:id:vasilyjp:20170227234424p:plain

1. 使用しなくなったクラスやリソースファイルはすぐに消す

1つのアプリを長く開発していると節目節目に大きくリファクタリングが行われると思います。そうすると使用しなくなったクラスやリソースファイルが現れますが、そのようなファイルはすぐに消すことを徹底しています。
一度不要になったものを再度使用することなんてほとんどありませんし、仮に必要になったらコミットログから引っ張り出せばいいだけなので容赦なく削除しましょう。
アプリサイズ削減にも直接効くので消し忘れがないように、Android Studioの Inspect Code を実行して探し出すのがポイントです。

2. Googleが提供しているAPIや、Support Libraryを標準に沿って使い倒す

Googleが提供しているAPIや、Support Libraryを標準に沿って使い倒すことがAndroidの開発においてはとても重要になってきます。
標準に沿って使うことで、ガイドラインに変更が入ったりした際に移行がとてもスムーズにできるようになりますし、正しいMaterial Design（Androidのデザインガイドライン）の実装に近づけることができます。そのため、標準から大きく外れた使い方はなるべく控えた方がいいと思います。
仕様上、デザイン上、どうしても標準から外れた実装をしなければならない状況になりましたら、ある程度の覚悟を決めてカスタマイズに望みましょう。

3. サードパーティ製のUI系Libraryは慎重に選定する

Design Support Libraryが充実してきたおかげで最近は使うことが少なくなったサードパーティ製のUI系Libraryですが、もしも使用しないといけない場合が来たら慎重に選定することをオススメします。
UI系Libraryはガイドライン変更の影響を受けやすいため、標準から大きく外れた実装をしていると移行が大変になるケースが多いです。IQONも過去に何度か苦しめられました...
使うことになった際には、開発が活発であるか、長い間使われていて枯れているか、使用するメリットが大きいか、他社での導入実績があるか、など多くの面を調査して選定することをオススメします。

4. コンストラクタやpublicメソッドの引数にはAnnotationを付けるようにする

コンストラクタやpublicメソッドの引数にはAnnotationを付けるように徹底しています。
IQONで良く使われているAnnotationは以下になります。

＠NonNull
＠Nullable
＠DrawableRes
＠LayoutRes
＠StringRes
＠AnimRes
＠MenuRes

Annotationを付けることで誤ったものを渡したときに警告してくれるようになるので開発中に非常に助かります。アプリの規模が大きく、長く開発を続けているアプリであれば恩恵は大きいと思います。
＠NonNull と ＠Nullable に関しては、チームでNullableになるような実装はしないと堅く決めるのであれば必要ないと思いますが、Nullableになる可能性があるのであれば付けたほうが安全です。
またKotlinで書く場合であれば、Nullableの場合は型に ? を付けるだけでスマートにできるため ＠NonNull と ＠Nullable は必要ありません。

5. テキスト、色、余白などの情報はResourceファイルにまとめて必要最低限に保つ

テキスト、色、余白などの情報は、レイアウトファイルやJava（Kotlin）側に直接書かず、Resourceファイルに定義して使うように徹底しています。Resourceファイルに定義したものを使うようにすることで、アプリ全体で長期的に統一感を保つ効果があります。
ただし余白に関しては、画面特有の指定がある場合には直接書く場合もあります。
また、定義するだけではダメで 必要最低限に保つ ことが非常に重要です。長く開発を続けていると自然とダブリが発生したりしますが、それを放置せずに常に見直すようにして必要最低限にすることで、定義した情報を使用する際の混乱を防ぐことができます。

6. チームでコードの体裁を揃える

Android Studioの Reformat Code や Optimize Imports を実行して、チームでコードの体裁を揃えることも長く開発し続けるには重要だと考えて行っています。
長く開発を続けているとどうしても人の入れ替わりが発生しますが、共通のルールがないとコードの細かい部分で統一感がなくなってきて少しずつ気になりはじめます（各チームメンバーの性格もあると思いますが）。
今では全員Android Studioを使って開発をしており、体裁を整えることに関してはそこまで苦ではないためルールを設け揃えるように徹底しています。
細かい話ではありますが、いろんな性格のメンバーがいる開発現場では大切なルールです。

7. レイアウトファイルはできる限りシンプルにする

以下の2点に関してはレイアウトファイルをコードレビューする際に注意して見るようにしています。

まとめることで削除できるViewは削除する
不要なパラメータは付けないようにする

まとめることでViewが削除できたり、階層が減らせたりする場合はコードレビューで積極的に指摘しています。最近の端末であればそこまで大きくパフォーマンスに影響はでませんが、古い端末であれば顕著に影響が出る場合があるのでムダがあればドンドン減らしましょう。
特に仕様変更やリファクタリングで修正が入った場合には見落としがちなので注意して見るようにしています。

仕様変更やリファクタリングによって使うViewが変わった際には元のViewで使っていたパラメータが残っている場合が多いので注意してみるようにしています。RelativeLayoutにorientationのパラメータが付いているケースはとてもよく見かけます。
また、あってもなくてもUIに影響がでないようなパラメータも付けないようにしています。本当に必要なときにだけ必要なパラメータを付けることでXMLがスッキリし改修する際に手が入れやすくなります。
ただし、Android Studioが警告してくれるものに関しては準拠するようにしています。

8. APIをシンプルな形で使う

APIの仕様を把握しシンプルな形でAPIを使うことは、アプリを長く開発し続けるのに重要だと考えています。Android DevelopersのDocumentを読んだり、実際にコードを読んだりしてみると、メソッドがオーバーロードされていてよりシンプルな形で使えるようになっていることがあります。
例えば ActionBarの setTitle のメソッドは、引数が CharSequence のものと、 ＠StringResのint のもの、2つが提供されています。
それにも関わらず getSupportActionBar().setTitle(getString(resId)) と書いてしまっているコードをよく見かけるので、APIの仕様をしっかりと把握してよりシンプルになるようにしています。

9. 新しい仕組み・古い仕組みを併用している場合、古い仕組みにはdeprecatedを付ける

アプリを長く開発していると場所によって古い仕組みが残ってしまっているケースが多いと思います。すぐにリファクタリングをして古い仕組みを撤廃できれば全く問題ないのですが、依存している箇所が多いと改修に多大な時間がかかってしまうため併用している場合も多いのではないかと思います。
IQONの場合もAPIクライアントがその状態に当たります。ほとんどのAPIリクエストに関してはRetrofitを使うように書き換えたのですが、一部Apache HTTP Clientをベースに作られたAPIクライアントが残っています。そのまま併用していると間違って新規で使われてしまう恐れがあるため、古いAPIクライアントには deprecated を付けて古い仕組みである、リファクタリングの対象である、ということを明確にしています。