なぜNewsPicksのAndroidアプリ設計にMVPを選んだのか - NewsPicks Advent Calendar 2018

あいさつ

NewsPicksの高畑です。
NewsPicks Advent Calendar 2018」7日目のエントリになります。

今年の技術書典5にて「テストが書けない人のためのAndroidMVP」と題してAndroidのMVP設計の本について個人的に出版してきました。
(現場での精一杯の設営画像)


NewsPicksのAndroidアプリでMVPを導入するにあたって、自分が開発しててMVPとはこうあるべきだと感じたことや、いかにテストコードを書ける状態にもっていけるように依存関係を切り離すのかみたいなことが書いてあります。今回は会社のブログなのであまり個人的なブログには書けなかったNewsPicks内部の話や経緯について赤裸々に触れてお届けしたいと思います。
現在BOOTHにてオンライン販売もしておりますので本記事を読んで興味が持たれた方は是非購入してみてください。

NewsPicksのAndroidアプリ開発で抱える課題

NewsPicksのAndroidアプリもリリースしてからそれなりに歴史が長くなってきました。それまではスピードが優先され、これといった共通の設計指針やテストコードもない状態でした。なんとなく皆API系のクラスとモデルを用意してAcitivity,Fragmentから呼び出すという流れにはなっていましたがそれゆえに、いわゆるFatActivity (Fragment)の出現やテストコードがない(書けない)状態が続いておりました 。

しかし成長にともない最近はAndroidの開発メンバーも増えていき、何かしら指針となる設計がないと特に新規に参入したメンバーについてはどういう風に機能を追加していいのかわかりにくいし、ソースコードからどういう機能があるのか読み解くのが難しい状態でありました。これは辛い状況ではありますが長くひとつのプロダクトに携わっていると同じような状況に陥ることはよくあるのではないでしょうか。

そんな中Droidkaigiに行き設計やテストコードに対してメンバー間で意識が高くなったタイミングを期に何かしら設計を導入しようということになりました。

なぜあえてMVPにしたのか

MVPに決まった経緯としては当時の開発体制にあります。

そのとき、ひとつのアプリに日本版NewsPicksとアメリカ版NewsPicksの2つが入っていました。
日本とアメリカで同時に同じプロダクトを触ってはいるがお互い別々の機能を平行して実装してました。
(※US版はQuartzとして別アプリになります。iOS版は先行してリリースされております)

開発メンバーも日本版は日本に、アメリカ版はアメリカに、と地理的に離れておりましたしコミュニケーションをとるのが難しい状態でした。
そんな状態の中で日本側がDagger2やRxJava、Android Data Bindingを入れて突然MVVMやクリーンアーキテクチャにするとこれまでの開発方法との差分やギャップが激しく逆に混乱してしまうのでは?という恐れがありましたし、今そこまでの設計を導入する必要があるのか?現在進行系で各チームがスピード感を持って開発していきたいタイミングで逆に足かせになるかもしれない。
いろいろ考えた結果、MVPにすれば当初の目標である共通の設計指針ができるということ、ある程度Presenterやモデルにテストコードが書ける状態にすることができるだろうという感触があること、日本とアメリカでAndroidにおけるMVPってこういう設計だよね?とあらかじめ共通の認識がほぼ保たれていましたし何より特別なライブラリや複雑な概念を導入することなく今すぐにでも始められる
さらにModel部分が分割され、テストコードを書ける状態にすることにより他の設計に移行した場合でもModel部分は共通で使えるだろうという目論見もあります。
そのような理由からMVPに決定しました。その後すぐに実際に新規で開発していた機能をMVPで実装することで、これからはこういう風にソースコードを分割するんだとほぼノーコミュニケーションで日本とアメリカで共通の認識を持つことができました。

状況としては「Androidアプリ設計パターン入門」の書籍にメルカリさんが大きな改善を行うに至った事例が載っておりますがそれに近い感じかなと勝手に思っております。弊社では大きな改善はまだ行わず、小さな改善を踏み出したという感じです。この書籍は非常に参考になりました。

MVP導入後

現在新規開発は基本的にMVPで開発しておりますが、すべて最初からテストが書ける状態になるのかといえばそんなことはありません。
Singletonや静的メソッド、既存のレガシーコードに引きづられてテストが書きづらいところはあります。
それでもPresenterにテストは書けるようになってきました。
まだまだカバレッジ率は低いのが正直なところですが、徐々にソースコードの品質は上がって来ていると感じています。
弊社ではネイティブアプリのCIツールにbitriseを利用しており、そこでユニットテストからβ版リリースまで自動化されており、攻めの体制だけでなく守りの体制も徐々に整備されつつあります。

いまさらMVP設計って古いと感じられる方も多くいらっしゃると思いますが、ただやりたいからモダンな設計を導入するのではなくそのとき解決したい課題、開発体制、スピード感、現状のソースコードの状態や将来性などさまざまな要因のメリット・デメリットを考慮した結果のMVPでした。
個人的にはMVPから始めたことは良かったと思っています。
しかし大きく改善することも決して諦めたわけではなく、またこれからサービスの成長やそのときの技術トレンドを追いつつタイミングを見極めて行きたいと思います。

さいごに

Androidアプリ開発における問題について赤裸々に書いたつもりなので、現在技術的負債を抱えるチームにおいてどのように戦うのか少しでも参考になればと思います。
ここまで真面目に技術系ブログを書いたのは初めてなので背中がかゆい感じがしますが、技術書典5に出した本にはMVP導入後にいかにテストを書ける状態にもっていくかの小技・テクニックなどをまとめてあります。またこの記事であらためてMVP設計について興味が出た方はMVPってどういう設計だっけ?ということもまとめてありますので気になった方は是非購入してみてください。
ありがたいことにこの書籍はインプレスR&D出版社さんから商業版としても出版を予定しておりますのでお見かけした際は是非購入してください。

表紙はこのような感じになる予定です。

同人誌版も購入可能ですので商業版を待てない方は本記事の始めに紹介したリンクから購入してください。 (在庫限り)

今年はNewsPicksのテックチームとして技術書典に何か本が出せればいいなぁと思っておりますので、一緒に何か技術書を書いてみたいという方や、ただアプリを開発するだけでなく大きめの設計や品質管理、開発フローの整備など色々なことにチャレンジしてみたいという方はぜひご連絡ください。

明日はkirihataさんによる弊社のWEEKLY OCHIAIなどの生番組をどのようなアーキテクチャ構成で配信しているかを書いてくれています。

株式会社ニューズピックス's job postings
Anonymous
1acc82f7 3372 4edd a728 59abf20ff67b?1546869491
Picture?height=40&width=40
A17f0d4a 1df5 44ab ad88 c059fb30ee30?1537709818
3b1862c2 6002 4561 9865 3ce05520969a?1550042012
4f370be0 809c 4f52 b90a f72cb6e463fd?1544296600
12 Likes
Anonymous
1acc82f7 3372 4edd a728 59abf20ff67b?1546869491
Picture?height=40&width=40
A17f0d4a 1df5 44ab ad88 c059fb30ee30?1537709818
3b1862c2 6002 4561 9865 3ce05520969a?1550042012
4f370be0 809c 4f52 b90a f72cb6e463fd?1544296600
12 Likes

Weekly ranking

Show other rankings
If this story triggered your interest, go ahead and visit them to learn more

Page top icon