DroidKaigi 2016 での発表資料です。

1. 2016-02-19 / DroidKaigi 2016
5 年続く「はてなブックマーク」アプリ
を継続開発する技術
信岡 裕也
NOBUOKA Yuya
株式会社はてな (Hatena Co., Ltd.)

2. 自己紹介
● はてな id:nobuoka
● Twitter @nobuoka
● ソフトウェアエンジニア
 モバイルアプリ (Android アプリ / UWP アプリ)
 Web サービス (Java / Scala / Perl / TypeScript)
● 経歴
 2012 – 2014 年 : 主に 「B!」 サーバーサイド
 2014 年 : 主に 「少年ジャンプルーキー」
 2015 年 : 「B!」 Android アプリ開発

3. 背景

4. 「はてなブックマーク」 アプリの開発
● 「はてなブックマーク」
 自社の web サービス
 ソーシャルブックマーク
 サービス自体は 10 年以上続いている
● 今月 2/4 に Android アプリ 「はてなブック
マーク」 が 5 周年！

5. 「はてなブックマーク」 で web ページをブックマーク

6. 他の人がブックマークした web ページ一覧を閲覧できる

7. 現在の B! Android アプリ開発チーム
● 企画 (マネージャも) 2 人
● デザイナー 1 人
● エンジニア 2 (+1) 人
Cashlytics

8. B! Android アプリの歩み
● 2011-02-04 最初のリリース
 API level 4+ 対応
 最新の Android は 2.3 という時代
● 継続的に開発 (エンジニアが兼任で 1 〜 2 人程度)
● 2015 年からエンジニア 2 (+1) 人体制
 大きな機能追加や変更ができるように
● 5 年続いてきて、この 1 年ほど特に開発が盛ん

9. B! Android アプリの歩み
2015-01-01

10. 長く開発しているアプリで遭遇する問題
● コードの変更が意図せぬ影響を起こして期待す
る動作をしないようになる
● 機能追加、変更時に既存の設計では対応できな
い
● Android プラットフォームの変化への追従
● などなど

11. この発表の目指すところ
● 継続的にアプリ開発を行うには？
 チームでの取り組み、方針を紹介
● 話題としては
 自動テスト、CI サーバー、ビルドシステム
 チーム体制、開発フロー
 アプリ設計、ライブラリ化

12. 第 1 部
テスト・CI・自動化

13. ソフトウェアテストの話

14. ソフトウェアテスト
● テストを書いてますか？
 Instrumented tests
 Local unit tests (Gradle plugin 1.1 より)
● テストは我々の開発を助けてくれる
 バグの早期発見 (新規開発時もコード変更時も)
 テストしやすく → より良い設計
● Gradle によりテストが書きやすくなった
 → Gradle 導入後からテストを書くように
Getting Started with Testing | Android Developers

16. B! アプリ開発とテスト
● コード品質を高める一つの手段としてテストを
利用
● 標準のテストツールをベースに
 Testing Concepts (Android Developers)
 AndroidJUnitRunner、Espresso
● テスト用のビルドタイプ (“ttest”) を用意
 Build config / ProGuard / テスト用コード

17. 目的を意識してテストを書く
● あらゆる状況・動作をテストすることは困難
● 何をテストするのか不明確なままテストを書い
ても効果は薄い
● 目的に応じて手段も変わってくる

18. 目的を意識してテストを書く
● 各 API level で問題なく動作するか？
● 手動での動作確認では発見しづらい項目の検査
 スクリーンビューの記録とか
● 将来変更するときに見逃しそうな部分
● 複雑な処理が期待通りに動くか？
● 外部とのやりとり
● など

19. テストを自動で実行する
● 手動ではなかなかテストを実行しない
 テスト実行には時間がかかる・面倒
 テストに落ちるのに気付くのが遅れる
● → 自動で実行されるように
● Jenkins
● Android SDK のエミュレータを利用
● SDK セットアップ : sdk-manager-plugin

20. テスト結果のフィードバック
● 自動で動いていても気づかなければ意味がない
● 目に入る場所にフィードバックする
 Slack のチャンネル
 GHE の pull request

21. テスト結果のフィードバック
● Jenkins → Slack
 Jenkins Slack plugin
● Jenkins → GitHub
 curl コマンドで GitHub の API を叩く
● プラグイン等なくても Web API 等が提供され
ていれば戦える

22. 最近進めていること
● Jenkins の Pipeline plugin の利用
 旧称 Workflow plugin
 ジョブの処理を Groovy の DSL で記述
→ 柔軟に書きやすく・管理しやすく
 Android エミュレータの起動・終了を Gradle タ
スクに
→ ジョブを柔軟に・Jenkins への依存を小さく
● スクリーンショットによる表示のテスト

23. テストを書いて変更しやすくし、品質を高めよう
● 欠陥検出や品質を高めるための一つの手段
 コードレビューなどと組み合わせて
● 必要ならテスト用の build type を用意
● 何を目的としてテストを書くのか意識する
● 動かさないと腐っていくので
 まずは自動化
 目につくところにフィードバック

24. リリースフローと自動化

25. リリースの流れ
● 週初めにリリース内容相談・決定
 基本的にリリース可能なものからどんどん出す
● 機能が揃う → リリース用ブランチを切る
 リリース用ブランチでバージョン更新
 自動テスト、パッケージ作成、チーム内への配
布・動作確認
● Play Store へのアップロード・公開

26. いつもの手順
● リリース用パッケージのビルド
● チーム内に配布 (Beta by Crashlytics)
● GitHub Enterprise に “リリース” 作成
● Google Play Store にアップロード・公開

27. いつもの手順

28. リリースフローが手動だと？
● 面倒
 APK パッケージを作って Play Store にアッ
プロードするぐらいならいいけど
● ミスが起こりがち
 手順漏れ (clean、GHE のリリース作成等)
 アップロードすべきパッケージを間違う
 など

29. 自動化しよう！

31. Gradle のタスク作成 & Jenkins 上で実行
● Gradle のタスク
 リリース用の APK パッケージ作成
 GHE の “リリース” を作成 & アップロード
 将来的には Google Play Store へも
● Jenkins 上で実行
 将来的に Pipeline plugin を予定
● リリースフローの自動化がしやすそう

32. リリースフローの自動化をしよう
● 面倒だと感じたら / ミスしそうだと感じたら
● とりあえず Gradle のタスクを書こう
 わりと手軽にいろいろできる
 がっつり時間を取るのは難しいので少しずつ
● さらに CI サーバー上で実行
 手元にビルド環境が整ってない状況でもリ
リースできる

33. テストや CI 関連のトーク
● Android CI: 2016 edition
● 僕がテスト書け書けおじさんになった経緯とそ
の過程でやったこと
● Advanced Android Espresso
● 生まれ変わった UI Automator を使いこなす
● Android Lint で正しさを学ぼう
● 怖くない gradle でのビルド環境設定と Bazel

34. 第 2 部
開発フロー

35. 開発の流れ
● 企画・タスク管理 (Trello)
● デザイン・設計・コーディング
 やりとりは口頭・チャットツール (Slack)
● 東京・京都の遠隔、非同期コミュニケーション
● コードレビュー (GHE)
● 自動テスト (Jenkins)
● チーム内へのパッケージ配布 (Beta by Crashlytics)

36. B! アプリ開発と Git ブランチ
● Git flow
dev
master
release
feature

37. B! アプリ開発とコードレビュー
● 社内の文化としてコードレビューは定着
● 継続して開発するためにも重要
 他人が見て意図がわかるか？
 将来、変更が難しくなってしまわないか？
● レビューされやすいように依頼側も気を付ける
 適切な規模 (数百行程度)
 変更の目的を明確に (複数の変更を混ぜない)

38. dev
Dev ブランチにマージする段階で
レビュー完了しているように

39. dev
規模が大きくなるなら分ける

40. リファクタリング
● 長く開発を続けていると & 続けていくにはリファクタ
リングが必要
 機能追加・変更時に設計を変える必要
 レガシーコード改善
● リファクタリングする際の問題
 機能追加・変更前に必要なリファクタリングを見極
めづらい
 他の変更とコンフリクトする

41. B! アプリ開発とリファクタリング
● リファクタリングと機能追加は分ける
 混ざるとレビューできない
● 機能開発時に必要になった箇所をリファクタリングとして切り
だす
 不必要なリファクタリングは行わない
 これはヤバい、という場所はリファクタリングする
● 小さな単位でリファクタリング
 レビューしやすい
 早く dev ブランチに取り込みコンフリクトを避ける

42. dev
開発中にリファクタリングが必要になったら
ブランチを新たに切って先にレビュー
Refactoring
feature

43. Preview 版と大規模な新機能開発
● 大規模な新機能開発
 dev ブランチでリファクタリングすると feature ブランチと
コンフリクトしがち
● どんどん dev ブランチにマージ？
 開発中の状態でリリースされると困る！！！
● Preview 版 (product flavor) でのみ機能を有効に
 これ自体がバグの原因になりうるので注意
 規模が大きい場合は有効
● 開発中の状態で動作確認してもらうのもやりやすい

44. Preview 版専用画面

45. メンテナンスしやすいコードを生み出す体制
● コードレビューしよう
 依頼側はレビューしやすいように気を付ける
● 必要なリファクタリングはどんどんやる
 リファクタリングと機能開発は分ける
● 開発用にプレビュー版などを作るといいかも
 Product flavor

46. 第 3 部
設計・実装

47. 継続して開発するために必要なこと
● 古い API level の対応
 Android Support Library
 自前で実装
● 将来にわたってメンテナンスしやすい設計・実装
 クラスの役割を明確に、クラス間の結合度を小さく
 処理は共通化する
 Activity、Fragment を肥大化させない
 複雑な処理はライブラリを作るなどして隠す
 意図がわかるように (コメントやアノテーションなど)

48. Android Support Library の互換機能
● B! アプリは現状 API level 10+ 対応
● v7 appcompat library などが重宝
● 誰もが使っている機能
 Fragment、AppCompatActivity、など
● あまり使われてなさそうな便利機能
 Drawable tinting など

49. 古い API level をサポートする自前の実装
● Support Library の実装を参考に
● 例えば ProgressBar の色変更
 “android:progressTint” 的なもの
 ProgressBar のサブクラスを作って対応
● 例えば影の実装 : “Build.VERSION.SDK_INT” で分岐
 API level 21 以降で elevation
 それ未満では Drawable
● 古い API level では諦めて何もしない場合も

50. アノテーションによるサポート
● Annotations Support Library を使おう！
● @Nullable/@NonNull
● 各種リソース (@StringRes など)
● @MainThread / @WorkerThread
 整理されてない古いコードで便利

51. Activity・Fragment を肥大化させない

52. Activity や Fragment は肥大化しがち
● 各コールバックメソッドでいろいろな処理
● View 操作を直接行いがち
 setContentView メソッドや findViewById
メソッドなどの存在
 View 操作のためのクラスの準備が面倒
● どこに書けばいいか迷うもの
● 特定の Activity/Fragment でのみ必要な処理

53. さらには同じような処理が分散
● Activity/Fragment 内に書かれた処理が別の
場所でも必要になったら？
● 分離しづらいとそのままコピペされるなど
● 同じような処理が複数の Activity/Fragment
に存在！！！！
● メンテナンスしづらい

54. 具体例
● Web ページ一覧のリスト項目のコンテキストメニュー
 「あとで読む」
 → 非ログイン状態の場合、ログイン画面に遷移し、ロ
グインして戻ってきた場合は 「あとで読む」 の HTTP
リクエストを送信
● Activity/Fragment と密な部分
 コンテキストメニュータップ時の処理
(onContextMenuItemSelected)
 onActivityResult メソッド

56. Activity や Fragment から処理を分離
Activity/Fragment
View / UI の処理
コールバックメソッド
ライフサイクルに応じた状態管理
その他何らかの処理
何らかの処理をするクラス
ユーザー入力

57. Activity や Fragment から処理を分離
Activity/Fragment
View / UI の処理
コールバックメソッド
ライフサイクルに応じた状態管理
その他何らかの処理
ユーザー入力
(外に出した部分の設計しなおしも大事)

58. コールバックメソッドからのメソッド呼び出し
● onCreate、onStart、onStop など
● メソッド呼び出しを求められることが多い
 広告とか
● 問題
 明示的に呼ぶ必要があるのは面倒
 呼び忘れしやすい

59. CallbacksAppComponents
● 自作ライブラリ
 Activity や Fragment のベースクラスを提供
 各コールバックメソッドの呼び出しを受け付けるイン
ターフェイスを実装したオブジェクトを登録できる
 登録しておけばベースクラスで勝手に呼んでくれる
● 各コールバックメソッドで種々の処理をする必要がある
ために Activity/Fragment から処理を分離しにくい問
題を解決

60. ベースクラスがコールバックメソッドを呼ぶ
Activity/Fragment
View / UI の処理
コールバックメソッド
ライフサイクルに応じた状態管理
その他何らかの処理
ユーザー入力
ベースクラス

61. https://github.com/nobuoka/CallbacksAppComponents

62. 複雑な処理をライブラリにする

63. 複雑な仕様には複雑な処理を書く必要
● どんどん複雑になるページ一覧のリストの処理
 リストをセクション分けする
 リストの項目を動的に追加していく
 リストの最後に何かを表示 (広告とか次ページ読
み込みボタンとか)
 記事一覧のリストの途中 (10 件目とか) に 「お
すすめユーザー」 などを表示 → 厳しい！！！！

65. 複雑な処理をライブラリにする
● 複雑な機能は 2 つに分けて考える
 機能に特化した部分 (扱うクラス・データ内
容等)
 汎用的で複雑な部分 → ライブラリ化
● 複雑な処理はライブラリに押し込んでしまう
● アプリケーションコードでは単にライブラリを
使うだけ

66. ComponentsRecyclerAdapter
● 先の複雑なリストを実現するために作ったライブラリ
● 複数の item view type の使用を容易に
● 表示のためのデータ構造をコンポーネントの木構造に
 コンポーネントでセクション分けしたり
 ベースのリストの途中に別のコンポーネントを指
し込むコンポーネント

67. Components-
RecyclerAdapter
ViewHolderFactory
Binder
Component
ViewHodler
onCreateViewHolder
onBindViewHolder
Retrieve item / item view type
Create
Component Component
Pass view holder and item
Domain model

68. https://github.com/nobuoka/ComponentsRecyclerAdapter

69. メンテナンスしやすいコードを書こう
● アノテーションと lint を活用
● ドキュメントコメント
● 設計を考える
 Actvity/Fragment を肥大化させない
 複雑な処理はライブラリにする
 などなど

70. まとめ

71. まとめ
● 継続して開発を続けるには？
● コード変更を行いやすく・コード品質を高める
 ソフトウェアテスト (自動化・フィードバック重要)
 リファクタリング (機能開発とは分ける)
 コードレビュー
 アプリケーションの設計・実装
● さらに、自動化
 Gradle のタスクを書くところから始めよう