f:id:timers-tech:20180223162247p:plain

こんにちは。Androidエンジニアの斎藤です。先月Android Architecture Components(以下AAC)をプロダクトに導入しました。 AACが発表されてから公式HPなどで動向を伺っていましたが、プロダクトへの導入については、各プロジェクトの進捗状況や既存コードへの導入するときの影響、導入に伴う一時的な開発速度の低下/混乱を避けるために見送っていました。 AACのようなアーキテクチャに関わるライブラリを既存のコードに導入することは、既存アーキテクチャとのバッティングやチームへの認識共有など、なかなか考えることが多く導入まで時間がかかるのではないかと思います。そこでAndroidチームがAACを導入するに至った経緯、実際にどうやって導入したかを書いていきます。AACの具体的な使用方法については様々なブログで詳細されているので割愛させていただきます。

なぜ導入するのか

考えることを少なくしたい
- チームメンバーごとに微妙に実装方法が異なりレビュー時に悩んだり、コンフリクト解消に手を焼く場面を少なくしたい。
テスト不足
- 既存コードはテストがしにくい設計になっています。そのため、API周りや特定のUtilsクラスのテストしかなく、どうしてもテストしたい場合はテスト用のclassとしてロジックを切り出すなどしていました。しかし、今後テスト用のオブジェクトが増えていくにつれてテストありclassとテストなしclassが混合しカオス化する未来が見えていたのでテスタブルな設計を導入したいと思ってました。
Google 公式の安心感
- 他にもAACを使わずともアーキテクチャを導入することは可能ですが、アーキテクチャに関しては個人で好き嫌いが分かれると思います。Googleお墨付きとなればチームでの合意は得られやすく、AAC1.0の発表もタイミングがよかったです。Volleyのことは忘れました。

www.youtube.com

導入のためのプチ合宿

プチ合宿を開催しました。以前Kotlin導入時にはチームで時間をとってプチ勉強会を開催しましたが、今回は1日みっちり時間をとってAAC導入までの下積みを作るためです。場所はオフィスの会議室を1日貸し切って行いました。当初コワーキングスペースで作業を予定していましたが、恵比寿近辺、モニター、Wifi、ホワイトボードなど各条件を考慮した結果、オフィスの会議室で落ち着いてしまいました。

合宿の流れとしては、AACのサンプルを参考に小さいアプリをチームで確認しながら作っていくというものです。作っていく過程で浮かんできた疑問点や改善点などをチームで解決していくことで、実装イメージを共有することができます。後術しますが、これが個人的には一番よかったなと思います。

合宿のよかったこと

コードへの共通理解
- 新しいアーキテクチャで実装するにあたり、こういう時どうしましょー？って疑問を早く/多く解決することができました。特に導入初期には多くの疑問が発生しがちですが、簡単なアプリを1から作ることでケーススタディーを通してチームの共通解を作ることができたので助かりました。
わからない問題はチームで考える
- 新しい技術に触れるときは未知のエラーに遭遇することは多々あります。正直一人だと気が滅入ってしまったり、気がつかない凡ミスもあったりするのですが、これにチームで立ち向かうととても心強かったです。解決もとても早い！
すぐにプロダクトに適用
- 合宿の最後のアクションとして build.gradle に必要なライブラリの導入やチームで決めたパッケージを作成してプロダクトに適用しました。こうすることで明日にでも実装を開始できます。

ファインプレー

スコープを広げない
- チーム、個人で理想的なアーキテクチャはあるのですが、そこに直線で向かうとあれもこれもとなって導入コストが肥大化しがちです。この合宿では1日という区切りを設けて、明日から導入するためにどうすべきかだけにフォーカスして議論できたことはファインプレーでした。

合宿の悪かったとこ

長い
- 1日という時間はアーキテクチャ導入には短いですが、集中するには長すぎます。1~2時間の間に休憩はとっていましたが、後半はガス欠気味でした。何かリフレッシュするという意味でも、やはりコワーキングスペースなど新鮮な環境の方がよかったかもしれません。

AAC導入してみてどうたった？

レビュー速度の向上
- アーキテクチャによってある程度コードが矯正されるので、自然と似たような実装になりレビュー速度/質が向上しました。
テストを書く量が増えた
- 今までは個人の裁量でテスト書く書かないを決めていましたが、決めれたテストは書くというルールをチームで決めたことでサボることはなくなりました。また、テストコードを書くことで実装のスピードが落ちるのは仕方ないと思っていましたが、アーキテクチャによってコードが矯正されることで実装時に考慮することが減ったので、結果的に実装スピードは変わらないように感じます。

資料

合宿の時に参考にしたリポジトリ

Architecture Components 1.0 安定版のお知らせ

積極採用中!!

子育て家族アプリFamm、カップル専用アプリPairyを運営するTimers inc. では、現在エンジニアを積極採用中！急成長中のサービスの技術の話を少しでも聞いてみたい方、スタートアップで働きたい方など、是非お気軽にご連絡ください！採用HP : http://timers-inc.com/engineerings