クックパッドで開催されたAndroid Casual Talks #1に行ってきました。
美味しいタイカレーも頂きました。
Android Casual Talks #1 : ATND
Android Casual Talks #1 #androidcasual まとめ - Togetterまとめ
以下、メモを。
クックパッドの開発環境について
- 以前の状況
- 開発者が1人だった
- 規約無し
- 手動ビルドだった
- などなど問題があった
- 属人性を下げるために
- 快適にコードを書くために
- 継続的に改善するために
- 開発者が1人だった
- コーディング規約
- Eclipseから、Android Studio + Gradleに移行
- ビルド
- まとめ
- ゴールはユーザに価値を届けること
- 高品質なアプリを早く作る事ができる環境を作る
品質を保つための組織的な取り組みと人に依存しないテスト
- ポイント
- マインド
- 人です。組織の目標を統一する
- 反復
- 開発は繰り返し、小さな目標に分割する
- 計測と評価
- 品質を正当に評価する、メトリクスは大事
- マインド
- 開発プロセスの決定
- イテレーションで行う
- 1週間でイテレーションして、お客さんに見せる
- そのなかで、設計、実装、テストでどんどん確認していく
- 良い点
- マインド形成
- 開発者が納得する目的を探す
- QCDを全て満たすのは不可能である
- Weeklyで何にプライオリティを置くか変える
- テストの重要性を理解する
- 不具合を修正するときに、テストをスキップしたがる気持ち
- フェーズ毎にによってスキップしてはいけないフェーズを決める
- 結果
- とは言え、不具合は発生する
- 残業を敵視するようになる
- 目標通りの納期
- 数値化されているので、機能を落とす交渉に説得力がある
グリーにJenkinsを導入して2年半でおこった事
資料 → 2013 08-29 jenkins for cookpad android
- Jenkins(Hudson)に関する記事をBlogに書いたのが2006年
- 移行普及活動などをしていた
- IndesignのデータからJenkinsで自動で電子書籍アプリを開発したり
- 2年半前にGREEに入社して、Jnekinsを導入。
- 導入のモチベーション
- 変えないことは、大きなリスクです
- 内的要因、競合変化、技術発展
- 変えないと技術的負債が大きくなる
- ひたすら負債を返済するために働くようになる
- 変えないことは、大きなリスクです
- 導入のポイント
- ツールを導入すれば良いのではなくて、ワークフローを変えなくてはならない
- じっくり慎重にやる
- 無理強いしない
- 無理強いすると開発者の反乱が起こる
- ある程度は許容すること
- 拡張、改善の余地を残す
- 見守る
- 変化についてくるための時間は待ってあげる
- ゆっくり熟成されるまで
- GREEの場合
- エンジニア、デザイナー、ディレクター、プロダクトマネージャーが関わっている
- 作業が属人化してしまう
- 見ているバージョンが違ったりする
- 違うバージョンを見ていて咬み合わないことがある
- 先ずはビルドをするところだけを、Jenkins導入
- 同じビルドを使ってテストをすることが出来るようになった
- ここまで来たら、見守ってあげる
- 自然にワークフローを変えるようなことをしてくれる
- 仕組みを改善することで、自然に色々と改善してくる
- 指標、マトリクスを取得する
- 取るだけでは自己満足になる。
- リリース基準との結びつきがない
- あるべき論や精神論から、許容できる範囲の仕組み・制度にする。
- 品質基準については、ゆっくり合意していく
- 徐々にワークフローに組み入れる。
- → 仕事の方向が揃うと大きな力になる
- 方向が揃わないとダメ
- 一緒に揃えていく
- 取るだけでは自己満足になる。
- もうひとつ
injectionの基礎(android編)
資料 → @inject presentation by G G on Prezi
- DI 依存性の注入。
- チャットアプリを作るのを例として考える
- 自分の連絡先の一欄を出す画面
- List
contacts = Contacts.query(...); - 普通なら、こんなふうに考える。
- List
- 同じようコンタクトリストを表示する他の画面ではどうするだろうか?
- コピペするだろうか?
- リファクタしますね
- 役割を持ったクラスを作って、実装を一箇所にする
- 現在オンライン中のコンタクトリストは
- Lister
contactLister = new OnlineContactLister(connection, ...); - これで、よくなったでしょ、一箇所にまとまったよね。
- Lister
- 仕様が変わりました
- 連絡先を外部のデータベースに置き換えてみる
- これを変更するのは結構大変です。Contextが無いとか。
- Factoryパターン
- 自分でnewするのではなくて、ContactListerを作ってもらう。
- Localから取得するのか、Onlineから取得するのかは、どこかの設定ファイルで見る
- 設定ファイルを変えるだけで、実装を変更しなくてもよい
- Factoryは、DIの機能に近い
- パラメータはどうしましょうか?
- オフラインでLocalから取得する場合はコネクションとか要らないですよね
- ここで、DIのフレームワークになります。
- 自分の連絡先の一欄を出す画面
- Ingector
- Ingectorオブジェクトがあります。
- Ingectorの設定ファイルに、このインタフェースは、この実装クラスを作りますよ、とかを書く
- 実装では、
- @Inject Lister
contactLister; - とするだけで、自動的に、NetPersonListerを作って当てはめてくれる
- @Inject Lister
- 依存関係を設定ファイルによって自動で設定してくれる
- 設定ファイルには、パラメータを設定するようなことも出来ます
- 柔軟性が上がる
- Injector Modules 設定のまとまり
- とは言え、そんなに置き換えないじゃない?
- テストの時に一番役に立つ
- Onlineから情報を取得するとなると、Onlineから取れる情報がいつでも同じというわけにはいかない
- なので、擬似データを取得するための方法として、DIが良く使われる
- フレームワーク
- Pico
- マーティン・ファウラーがDIの研究をしてたときに作ったもの
- Guice
- Googleがつくったもので機能が多い
- 高度なことも出来る
- 重いです
- Pico
- Spring
- サーバサイドでは有名
- Android向けのSpringも出ているらしい
- Roboguice
- Proton
- 軽量
- Dagger
- Staticでインジェクションをやっている
- コンパイル時に実際のコードを置き換える仕組みで、ランタイム時ではない
- Staticでインジェクションをやっている
意外と役立つ?Android Open Source Projectすすめ。
- OHA
- Androidのアーキテクチャ図
- 多くの人は、Application層を作っている
- アプリ開発で悩んだときは?
- それでもわからないときは?
- 他のアプリを逆コンパイル
- 明日考える
- 仕様をドロップする
- 最終解決方法
- OHAのコードリーディングをする
- 事前準備
- 言語を英語にしましょう
- 設定アプリ内の画面に表示されてるものを検索するため
- OpenGrokと言うサービスを使う
- {OpenGrok by OpenGrok
- ソースコードの検索サービス
- 検索する
アプリのリニューアルとその効果測定について
- PixivのAndroidアプリをリニューアルしました
- 黒ベースから、白ベースに華やかに
- 今風のUIに
- 使いやすくなったはずだ
- レビューを見ると、前のほうが良いという意見が沢山
- 批判レビューが沢山出てくる
- しかしながら、レビューの意見だけがユーザの意見ではない
- GA等を使って解析してみよう
- ブックマーク機能
- コンテキストメニューから、アクションバーに移行
- ブックマーク操作のイベント数は約7倍になっていた
- 画面遷移を少なくし、操作数を減らす
- ステップ数が4つあった物を1つにしました
- スクリーンビューと滞在時間を比べて見る
- ムダな画面は見なくなったけど、一つの画面での滞在時間は増える傾向になりました
- ポイント
- よく使う機能はアクセスしやすく
- ムダな画面遷移をさせない
- 戻るボタンを多用させない
- おかげでユーザ数も増えています
- とは言え
- レビューは批判も含めて貴重な意見
- ユーザ全員がレビューしてくれるわけではない