@thorikiriのてょりっき

@thorikiriがWebとかAndroidとかの技術ネタや本を読んだブログです

Android Casual Talks #1 #androidcasual に行ってきました


クックパッドで開催されたAndroid Casual Talks #1に行ってきました。
美味しいタイカレーも頂きました。
http://images.miil.me/i/fe4abd0e-109b-11e3-8a3d-22000a84999a.jpg
Android Casual Talks #1 : ATND
Android Casual Talks #1 #androidcasual まとめ - Togetterまとめ
以下、メモを。

クックパッドの開発環境について

  • 以前の状況
    • 開発者が1人だった
      • 規約無し
      • 手動ビルドだった
      • などなど問題があった
    • 属人性を下げるために
      • 快適にコードを書くために
      • 継続的に改善するために
  • コーディング規約
    • コーディングスタイルが統一されていなかった
    • Prefixのmがついていたり、ついていなかったり
      • 開発者が1人だが、ずっと同じ人と言うわけではなかった
    • サーバ側のRubyチームのコーディングガイドラインなどは、Github Enterpriseで管理されていた
    • AndroidJava用も作りました
    • 規約があるので、書きやすく、レビューも楽に
  • Eclipseから、Android Studio + Gradleに移行
    • Ant、MavenXMLファイルの設定から、GradleでのGroovyのDSLで設定を書くことに
      • プログラムで書くので、条件をで色々書くことができるので良い
      • Gradleは割りと新しいものであるが、大概の事は出来る
    • Mavenリポジトリのサーバ
      • ライブラリプロジェクトを登録。
    • Android Studioはまだ早いんじゃないの?
      • でも、Rubyチームは新しいものを取り入れる文化だった
      • なので、Androidチームもそれを踏襲する
  • ビルド
    • Debugビルド
    • Betaビルド
      • マスターブランチのビルド
      • セキュリティ試験などが行われる
      • 社内の人が実際に利用してβテストを行う
    • リリースビルド
      • クラッシュレポートを有効
      • デバッグをオフにするなど
      • PAPAと言う社内ツールでアナリティクスを行う。お問い合わせとかにも使われる。
  • まとめ
    • ゴールはユーザに価値を届けること
    • 高品質なアプリを早く作る事ができる環境を作る

品質を保つための組織的な取り組みと人に依存しないテスト

  • ポイント
    • マインド
      • 人です。組織の目標を統一する
    • 反復
      • 開発は繰り返し、小さな目標に分割する
    • 計測と評価
      • 品質を正当に評価する、メトリクスは大事
  • 開発プロセスの決定
    • ウォーターフォール
    • メンバーは20人くらい。
    • まず開発方針、プロセスとかを決める。
      • バグがゼロとかではなく、前回より、何%向上とかそういう事
      • レビュー工数の割合とか、自動で計測できるカバレッジを計測
      • レビュー工数は全体の15%は確保するなど
      • 不具合発見工程、原因工程など
    • 開発者の中で話し合う
  • イテレーションで行う
    • 1週間でイテレーションして、お客さんに見せる
    • そのなかで、設計、実装、テストでどんどん確認していく
  • 良い点
    • 4ヶ月のように長いスパンだと、振り返る時に忘れる
      • 振り返りは早いほうがいい
    • 単体テストの自動化はやる、JUnitとか
      • テストの密度が少なかったら追加する
    • テスト設計は結構きっちりする
      • 直交表を作るなど
    • 設計と検証はワンセットでやる
    • 作りきったものに、テストフレーム枠を入れるのは難しい
      • なので、初めから導入する
  • マインド形成
    • 開発者が納得する目的を探す
    • QCDを全て満たすのは不可能である
      • Weeklyで何にプライオリティを置くか変える
    • テストの重要性を理解する
      • 不具合を修正するときに、テストをスキップしたがる気持ち
      • フェーズ毎にによってスキップしてはいけないフェーズを決める
  • 結果
    • とは言え、不具合は発生する
    • 残業を敵視するようになる
    • 目標通りの納期
      • 数値化されているので、機能を落とす交渉に説得力がある

グリーにJenkinsを導入して2年半でおこった事

資料 → 2013 08-29 jenkins for cookpad android

  • Jenkins(Hudson)に関する記事をBlogに書いたのが2006年
  • 移行普及活動などをしていた
  • IndesignのデータからJenkinsで自動で電子書籍アプリを開発したり
  • 2年半前にGREEに入社して、Jnekinsを導入。
  • 導入のモチベーション
    • 変えないことは、大きなリスクです
      • 内的要因、競合変化、技術発展
    • 変えないと技術的負債が大きくなる
      • ひたすら負債を返済するために働くようになる
  • 導入のポイント
    • ツールを導入すれば良いのではなくて、ワークフローを変えなくてはならない
    • じっくり慎重にやる
    • 無理強いしない
      • 無理強いすると開発者の反乱が起こる
      • ある程度は許容すること
    • 拡張、改善の余地を残す
      • 見守る
      • 変化についてくるための時間は待ってあげる
      • ゆっくり熟成されるまで
  • GREEの場合
    • エンジニア、デザイナー、ディレクター、プロダクトマネージャーが関わっている
    • 作業が属人化してしまう
      • 見ているバージョンが違ったりする
      • 違うバージョンを見ていて咬み合わないことがある
    • 先ずはビルドをするところだけを、Jenkins導入
      • 同じビルドを使ってテストをすることが出来るようになった
      • ここまで来たら、見守ってあげる
    • 自然にワークフローを変えるようなことをしてくれる
      • 仕組みを改善することで、自然に色々と改善してくる
  • 指標、マトリクスを取得する
    • 取るだけでは自己満足になる。
      • リリース基準との結びつきがない
    • あるべき論や精神論から、許容できる範囲の仕組み・制度にする。
    • 品質基準については、ゆっくり合意していく
      • 徐々にワークフローに組み入れる。
      • → 仕事の方向が揃うと大きな力になる
      • 方向が揃わないとダメ
      • 一緒に揃えていく
  • もうひとつ
    • トヨタかんばん方式
      • トヨタ系列で作って、売っている
      • 季節などによって出荷量が変化しない
      • 顧客が出荷まで3週間くらい待ってくれる
      • いくつ売れたか、陸運局に登録されるので、わかる
      • なので、在庫とかの調整が出来る
    • 野菜農家(でも何でも)
      • 季節によって出荷量は変わる
      • 幾ら消費されて、いくら破棄されているかわからない
      • なので、野菜農家では、かんばん方式はうまくいかない
    • 業種業態や、ビジネスによって、方法は同じではない
      • なので、良い方法を見つける必要がある

injectionの基礎(android編)

資料 → @inject presentation by G G on Prezi

  • DI 依存性の注入。
    • Inversion of Control、制御の反転。
    • マーチンファウラーたんの仕組みを考えたとき、IoCだった
    • プログラマとプログラムのインタラクション
      • 誰が制御するかを変える。
  • チャットアプリを作るのを例として考える
    • 自分の連絡先の一欄を出す画面
      • List contacts = Contacts.query(...);
      • 普通なら、こんなふうに考える。
    • 同じようコンタクトリストを表示する他の画面ではどうするだろうか?
      • コピペするだろうか?
      • リファクタしますね
      • 役割を持ったクラスを作って、実装を一箇所にする
    • 現在オンライン中のコンタクトリストは
      • Lister contactLister = new OnlineContactLister(connection, ...);
      • これで、よくなったでしょ、一箇所にまとまったよね。
    • 仕様が変わりました
      • 連絡先を外部のデータベースに置き換えてみる
      • これを変更するのは結構大変です。Contextが無いとか。
    • Factoryパターン
      • 自分でnewするのではなくて、ContactListerを作ってもらう。
      • Localから取得するのか、Onlineから取得するのかは、どこかの設定ファイルで見る
      • 設定ファイルを変えるだけで、実装を変更しなくてもよい
      • Factoryは、DIの機能に近い
    • パラメータはどうしましょうか?
      • オフラインでLocalから取得する場合はコネクションとか要らないですよね
      • ここで、DIのフレームワークになります。
  • Ingector
    • Ingectorオブジェクトがあります。
    • Ingectorの設定ファイルに、このインタフェースは、この実装クラスを作りますよ、とかを書く
    • 実装では、
      • @Inject Lister contactLister;
      • とするだけで、自動的に、NetPersonListerを作って当てはめてくれる
    • 依存関係を設定ファイルによって自動で設定してくれる
      • 設定ファイルには、パラメータを設定するようなことも出来ます
      • 柔軟性が上がる
      • Injector Modules 設定のまとまり
  • とは言え、そんなに置き換えないじゃない?
    • テストの時に一番役に立つ
    • Onlineから情報を取得するとなると、Onlineから取れる情報がいつでも同じというわけにはいかない
      • なので、擬似データを取得するための方法として、DIが良く使われる
  • フレームワーク
  • Spring
    • サーバサイドでは有名
    • Android向けのSpringも出ているらしい
  • Roboguice
    • GuiceAndroid向けに作ったもの
    • Activityクラスの場合に、RoboActivityを使うようにする
  • Proton
    • 軽量
  • Dagger
    • Staticでインジェクションをやっている
      • コンパイル時に実際のコードを置き換える仕組みで、ランタイム時ではない

意外と役立つ?Android Open Source Projectすすめ。

  • OHA
  • Androidアーキテクチャ
    • 多くの人は、Application層を作っている
  • アプリ開発で悩んだときは?
  • それでもわからないときは?
    • 他のアプリを逆コンパイル
    • 明日考える
    • 仕様をドロップする
  • 最終解決方法
    • OHAのコードリーディングをする
    • 事前準備
      • 言語を英語にしましょう
      • 設定アプリ内の画面に表示されてるものを検索するため
  • OpenGrokと言うサービスを使う
  • 検索する
    • string.xmlが引っかかるので、name="aaaa" の部分で、再度検索する
    • Javaファイルが出るので、そのあたりのコードをコピペします
    • 一般のアプリでは通常は使えないAPIが表示される事もある
      • @Hiddenが付いているAPIは使えない
    • 諦めたら試合終了だよ。

アプリのリニューアルとその効果測定について

  • PixivのAndroidアプリをリニューアルしました
    • 黒ベースから、白ベースに華やかに
    • 今風のUIに
    • 使いやすくなったはずだ
    • レビューを見ると、前のほうが良いという意見が沢山
    • 批判レビューが沢山出てくる
    • しかしながら、レビューの意見だけがユーザの意見ではない
  • GA等を使って解析してみよう
    • ブックマーク機能
    • コンテキストメニューから、アクションバーに移行
      • ブックマーク操作のイベント数は約7倍になっていた
    • 画面遷移を少なくし、操作数を減らす
      • ステップ数が4つあった物を1つにしました
      • スクリーンビューと滞在時間を比べて見る
      • ムダな画面は見なくなったけど、一つの画面での滞在時間は増える傾向になりました
  • ポイント
    • よく使う機能はアクセスしやすく
    • ムダな画面遷移をさせない
    • 戻るボタンを多用させない
    • おかげでユーザ数も増えています
  • とは言え
    • レビューは批判も含めて貴重な意見
    • ユーザ全員がレビューしてくれるわけではない