こんにちは、アプリケーションエンジニアの
id:takuji31です。今年の4月にはてなブックマークのチームにjoinし、はてなブックマークAndroidアプリのリノベーションを担当しました。
4月の末にはてなブックマークAndroidアプリのリノベーションが一通り完了しました。今日は大規模なアプリのリノベーションを完了して、実際にどうなったかを振り返ります。
はてなブックマークAndroidアプリのリノベーションについて
リノベーションを行った経緯やおおまかな方針については、以前に
id:funnelbitが投稿した記事の通りです。
DroidKaigi 2017 で「大規模アプリのリノベーション」の発表を行いました - Hatena Developer Blog
簡単にまとめますと
- はてなブックマークAndroidアプリはコードベースが大きく、大きなリファクタリングも行わなかった結果、2011年のリリースからの古いコードが残り続けている
- コードが大きく、かつ設計が統一されず、機能追加やバグフィックスでのコード追跡にコストがかかっていた
- リファクタリングという規模ではないのでリノベーションと呼ぶことにした
- ドメイン知識の獲得→設計→リファクタリングの順番で行った
- 設計はおおよそClean ArchitectureとMVVMをベースにした
- Repository → Interactor → ViewModelの順に実装した
- 使用されているライブラリーを整理し、メンテナンスが停止しているもの、非推奨のものはモダンなライブラリーへの切り替えを行った
という風にして、統一感のない設計で書かれたコードをあらかじめ決めた設計に統一するようにリファクタリングを行いました。
成果
画面ごとに優先順位をつけて、リファクタリングするものを選択した
まずは実装にあたって画面ごとに優先順位をつけました。
特に今後も積極的にメンテナンスを行っていくであろう画面を優先順位が高いものとし、リノベーション完了予定だった2017年4月末までに対応する画面を選択しました。
これにより、今後あまり変更が入らないであろう機能のリファクタリングを行わずに済むため、リファクタリングの必要度が高い部分に注力できたと考えられます。
Activity/Fragment、ロジック部分のリファクタリングを行った
優先順位をつけ選択した画面に関連するほぼ全ての部分をリファクタリングしました。
リノベーション前のアプリは、各画面の設計が統一されておらず、MVVM、MVP、MVPVM、MVC、マッチョActivityなど各画面ごとにかなり設計が違っていました。
これを事前に決定した設計に基づいたものに全て変更しました。
これにより、アプリ全体のコードに統一感ができ、(事前にまとめたドキュメントと合わせて)開発メンバー全員がアプリの設計について共通認識を持てるようになりました。
週に1回の定期リリースを行った
リノベーションは既存のアプリをベースに行い、週に1回その成果をバグ修正などと共に定期リリースしていました。 これにより「最後にまとめてチェックしたらめちゃくちゃバグっていた」という大規模な変更にありがちな問題を回避することができたと考えられます。
やっていないこと
大きく変更が加わらないであろう画面のリノベーション
今後大きく変わらないであろう優先順位の低い画面は今回のリノベーションでは特に変更は加えませんでした。
ですが、これらの画面も今後メンテナンスが必要になってきた時に、今回の設計を元にリファクタリングをする予定です。
実際にやって見えた課題
大規模なアプリのコードをリファクタリングする見積の難しさ
はてなブックマークAndroidアプリは非常にコードベースが大きく、1カ所の変更が非常に多くの箇所に影響が起こるようなことも多いです。
こういったコードをリファクタリングする場合に「実際やってみたら影響範囲が大きすぎて思ったよりかなり大変」といったことになりがちです。
リノベーションでは見積の粒度を可能な限り下げることで、この乖離を極力減らすようにしました。詳細な見積をするのは当たり前のことではありますが、結構見落としがちな印象があります。
設計の例外
リノベーションの設計は熟慮され、サンプルアプリでも検証されており、非常に出来の良い設計(と言うと語弊がありますが、このアプリとマッチしている設計)と思われます。
ですが、それでもこの設計で対応できない例外はいくつか起こりました。
これについては開発メンバー全員で話し合い、問題なければ許容することにしました。
途中参加したメンバーとしてリノベーションをどう感じたか
私は開発メンバーとして4月頭から末までの1ヶ月のみ、途中参加でリノベーションに参加しました。
途中参加メンバーとしてリノベーションに参加してみて
- 設計が非常によく練られていて作りやすいし読みやすい
- (以前ブックマークアプリのチームに短期間ヘルプで入った時より)かなりコードがすっきりしていた
と感じました。
これは同時に、今後新しいメンバーが開発に参加した場合にも導入が容易にできる状態になった、とも考えられます。
今後の課題
メンテナンス性の維持
今回のリノベーションではてなブックマークAndroidアプリは高いメンテナンス性を得ることができましたが、今後もこの状態を維持していくことは恐らく簡単ではないでしょう。
開発メンバーの入れ替わりがあったとしても、今のメンテナンス性の高い状態を維持していくにはどうすれば良いか考えていく必要があると思っています。
設計を今後どうしていくか
メンテナンス性の維持に関わる部分でもありますが、今後時代の流れや例外の増加によって設計を見直す必要があるかもしれません。
そうなった場合に既存の設計で作られたものをどうしていくか、そもそも設計を変更する必要があるか？などは都度その時の開発メンバーと話し合って決めていき、ドキュメントとコードに反映していく必要があると考えられます。
技術選択
リノベーションでは古いライブラリーを設計に合わせてモダンなものに変更しました。
今後も技術の選択(ライブラリー、言語など)については新しいものに振り回されすぎず、保守的になりすぎずバランスよく選んでいく必要があります。
最近だとKotlinがAndroidの開発言語として公式に認められましたので、Kotlinを導入するか、という部分についても検討する必要があると思われます。
最後に
個人的な意見ですが、今回のリノベーションは長期間にはなりましたが、非常に成功したと考えています。
実際に今も新機能の開発を行っていますが、コードベースが新しくなったことで、既存の部分に手を入れる対応の見積もしやすくなりましたし、新規開発の部分についても設計に迷う必要がなくなりました。
はてなでは、スマートフォンアプリエンジニアを募集しています。
私たちと一緒に最高のモバイルアプリを作りましょう！ご応募お待ちしております。
