入社してすぐにAndroidアプリの大規模リファクタリングに着手！その時自分に誓ったこと【前編】

こんにちは。コーポレートスタッフの茂木です。

今回は、2018年1月に入社以来、MoneyEasyのAndroidアプリ開発を担当している照井さんに、入社後、最初に行った大工事であるAndroidアプリのフルリファクタリングについて、語っていただきました。
エンジニアの方には、苦労も含めて共感いただけると内容になっていると思います！

入社当時の状況

2017年末にMoneyEasyプラットフォームを使用した最初のサービス「さるぼぼコイン」がリリースされました。
私はこのリリースから1ヶ月後くらいに入社したのですが、当時様々な事情がありAndroidアプリの保守運用は引き継ぎなく私一人で開発することになりました。

この時のAndroidアプリの状態を簡単に表すと、

・FatActivity
・ドキュメントなし

という「まあよくあるよね」という状態でした。

誤解がないよう補足しておくと、収益が見込めるかまだ分からないサービスに対しては、とにかくスピード重視で迅速にサービスをローンチすることが重要だと思うので、こういう状態になってしまうのは仕方ないのかなと思っています。

私自身はエンジニア界隈でも言われている通り、品質とスピードは相反するものではないという考えに賛同しますが、一方で「とにかく動くものを今の最適リソースで作るにはこれしかなかった」という事情も理解できるのです。

そんなわけで、入社直後はこの状態下で溜まっている様々な課題や機能追加を担当することとなりました。

こんな状態で大丈夫？

私は前職がガチガチのSIerで、Androidといえば趣味＆ポートフォリオ用にアプリを作った経験のみでした。（DroidKaigiアプリには毎年お世話になっております。）

そんな私にとって幸か不幸か、当時のAndroidアプリのコードは、上述の通りViewに「描画処理、ビジネスロジック、Http通信」まで全てが1クラスに集約されており、また使用しているライブラリも最低限であったため構成の把握は比較的容易でした。

中途半端にトリッキーなDIをされていたり、オレオレMVXな構成でなかったことは不幸中の幸いだったと思います。

そうはいっても、このコードを今後メンテしていくモチベーションを保つのはなかなか辛いものがありました。
せっかくSIerから転身したし、DroidKaigiのアプリを主に見ていた関係で、もっとモダンな設計やライブラリを使って開発したかったのです。

そして2ヶ月後

入社して1ヶ月後くらいに『DroidKaigi2018』が開催されました。2017年まで私は個人参加していましたが、この年から会社のスポンサー枠で参加させていただけることになりました。

ブースの手伝いは最低限で好きなセッションどんどん見て良いよと言われましたが、お金出していただいているしちょっとは手伝いしないと悪いと思って、結局ブースの方が他社のアプリ開発者と話せる機会が圧倒的に多いので、半日以上いた記憶があります。

2017年のGoogle I/OでAndroidの正式言語にKotlinが含まれたこともあり、当時はよく「そちらのAndroidアプリにはもうKotlin導入しました？」みたいな感じで会話のきっかけを作っていました。
DroidKaigアプリのコードも読んでいてとても面白く、そして羨ましかったことを覚えています。

話はMoneyEasyに戻ります。

比較的大きな機能をリリースした2018年3月くらいでしょうか、開発メンバーから技術的負債返却の声が上がりはじめました。

当然、Androidアプリだけがこんな構成になっている訳ではなく、サービス全体が同様の構成になっており、今後需要が高まりそうなサービスでしたので早めに負債を返却することが急務となりました。

当時サーバーサイドを担当していたメンバーが強烈に後押ししてくれたことと、PMが「責任を持ってやってくれれば自由にしていいよ」と理解ある感じだったため自分はAndroidアプリのリファクタリングを行うことになりました。

責任を持ってやるのは当たり前だ！という話もありますが「そんなリスクは許容できない」「全テストが必要なのでダメ」など、そもそもチャンスすら与えられない環境が多い中、入社して浅い自分にリファクタリングを任せてもらえたことはとても嬉しかったです。

顧客も金融機関では珍しく技術に理解を示してくれているようで、各ステークホルダーに恵まれた環境なのかもしれません。

大規模リファクタリングにあたっての制約

今回のリファクタリングでは一部分ではなく根幹から全て修正することにしました。

リファクタリングを行うにあたっての業務的な制約に加え個人的な制約（誓いに近いです）を念頭に置いて計画を立てました。

１．業務的な制約
　1．スケジュールの関係で7末までに完了させること
　　（8月に機能全テストが必要なリリースがあるのでそれに間に合うことが必須）
　2．既存アプリへの機能拡張＆保守運用は最優先で行う

２．個人的な誓い
　1．MoneyEasyのAndroidアプリの設計や実装について、胸を張って話せるようになる
　2．チームの期待を裏切ることはしない

2-1が私の中で一番大きな要因で、自身が開発しているアプリのことは業務的にもコード的にも胸を張って話したいので、できるだけモダンな設計/実装にしたい想いがありました。

また、PMや開発メンバーが信頼して任せてくれたこととサーバーチームの方々にも設計や方針検討など協力してもらったため、期待通りにやりきることと重大なバグを発生させないことを最優先に考えて取り組みました。

取り組む前の設計/検討

この大規模リファクタリングに当たって考えることは山のようにありました。

コードの改善はもちろんのこと、CI/CDやテストコード導入などやりたいことは多くありましたがリソースとスケジュールの兼ね合いで断念したものも多くありました。

最終的に以下の6項目に分けてそれぞれ設計/検討しました。

１．アーキテクチャ見直し
２．採用言語の検討
３．使用ライブラリ検討
４．リソース設計
５．ログ設計
６．エラー設計

これらは一つ一つが1記事になる書けるくらいになってしまうし、今となってはより良い設計がデファクトスタンダードになっているものもあるため詳細は割愛します。

スケジュールがタイトでしたがいきなりコードを触り始めると絶対失敗するので4月の1ヶ月間はこれらの設計および検討に注力することにしました。そのため、コードに手を入れる期間はGW明けの5月〜7月末の3ヶ月間となりました。

最終的にKotlinを採用し、Android Architecture Components（以下、AAC）を使ったMVVM構成で、各レイヤーの繋ぎこみはRxJavaを使用、DIはDagger2という構成で再構築することにしました。
ちなみに構成は、『DroidKaigi2018』の影響を思いっきり受けています。（笑）

話はまだ続きますが、今回はここまでとなります！
後編は、具体的にどう進めたのか、構成図やポイントを押さえて語っていただきます。

次回をお楽しみに。
お付き合いいただき、ありがとうございました！