はじめに
Androidエンジニアの林です。 ジモティーのサービスも10年を超え、昔のコードがまだまだ存在しており、定期的にリファクタを行なっています。 そこで現在チームが抱えている課題をいくつか紹介したいと思います。
まだまだJavaのコードがある
新規画面はKotlinで書くことがルール化されているのですが、昔からあるような主要画面は全てJavaで書かれていました。 2021年はその主要画面を全てリファクタするという目標を掲げほぼKotlin化することができました。 ただあまり改修が入らない画面や、色々な画面から使われている大規模なModelクラスなどは、なかなかKotlin化できずまだ手がつけられていない箇所もあります。 サービスの根幹を担っているクラスがJavaで書かれていると、Kotlinだと簡略化して書ける部分もわざわざJavaでどうやって書くのか調べながらコーディングしなければならず、生産性が上がらない原因となってしまっています。 (現在全体の約65％ほどがKotlinで書かれています。)
デザインシステムがまだ確立していない
デザインシステムがまだ確立しておらず、例えばダイアログ関連のデザインなどが様々でエンジニアも把握しきれず、ダイアログのクラスが肥大化してしまっています。（ダイアログ生成メソッドを新規で作り続けている、1000行超えてます、、） 現在デザイナーチームでデザインシステムの作成を行なっており、確立後にそれに伴うメソッドをまとめたクラスを作成できると考えています。
アーキテクチャーと非同期処理が統一されていない
現在主要な画面はほとんどGoogle推奨のMVVM+Coroutinesになっていますが、
| アーキテクチャー | 非同期処理 |
|---|---|
| MVVM | Coroutines |
| MVP | Coroutines |
| MVP | RX |
という画面構成が乱立しており、新しく入った人のキャッチアップが大変になっている要因になっています。
これから順次RXをCoroutinesに置き換える作業もやっていきたいのですが、MVPで割と整理された画面をMVVMにするのか？という議論もありなかなか手がつけられていません。 理想としてはすべての画面でMVVM+Coroutinesであることが望ましいのですが、工数的な部分もあり、MVPとの併存にしばらくはなるのではないかと考えています。
歴史が長いと負のコードも様々残っており、一気にリファクタしたいところもあるのですが、クラッシュが発生するリスクもありと慎重に進めている状況です。 モジュール分割に向けてApp層からData層のクラスを呼べないようにするなど細かなリファクタも粛々と進めています。
※ 弊社のAndroidアーキテクチャー推移についてはこちら jmty-tech.hatenablog.com
DIの方法が二通りある
リファクタの一環として、Daggerを使ってDIしている画面を順次Hiltに置き換える作業も行なっています。 移行期で仕方ないのですが、複数のModuleクラスが存在してコードの見通しが悪くなっており、こちらも新しく入った人が混乱してしまう要因となっています。
外部要因起因のANR
画面のフリーズを検知するANRも日々チェックを行なっています。 広告を入れていることからどうしてもWebVIewなどでANRが発生してしまうことがあります。 SDKのバージョンアップや負荷がかかる処理を非同期で行うようにするなど、原因を調査してなるべく早期に対応するように心がけています。
まとめ
このようにAndroidチームではリファクタを日々行なっています。 また課題の洗い出しや新技術も含めた解決方法なども話し合いながら業務を行なっています。
最後に
ジモティーでは一緒に課題を解決してくれるエンジニアを募集中です！
jmty.co.jp
