パルカワ2

最近はFlutterをやっています

Espresso 2.2でdependencyエラー

compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:23.0.1'

androidTestCompile 'com.android.support.test:runner:0.3'
androidTestCompile 'com.android.support.test:rules:0.3'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2'

と書いたらエラーになった。

Warning:Conflict with dependency 'com.android.support:support-annotations'. Resolved versions for app (23.0.1) and test app (22.2.0) differ.

適当にインターネットで得た情報をコピペした事を懺悔しながら、バージョンあげたらなおった。

androidTestCompile 'com.android.support.test:runner:0.4'
androidTestCompile 'com.android.support.test:rules:0.4'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.1'

Testing Support Library | Android Developers
Android Testing Support Library

Androidアプリの MVP アーキテクチャ

AndroidアプリではMVPアーキテクチャがよく使われてるっぽいぞ!?!!!と思ったのでRetrofit触るついでにやってみた。

以下のような認識でいます。

  • Modelは、APIやDBとやり取りをしてEntityを返す。
  • Presenterは、ModelからEntityを受け取り、Viewに渡す
  • Viewは, Viewに関するメソッドを持ち、Entityを利用して表示したりする。

今までActivityはController的なやつ!って説明を見たりしていたので、最初それで考えてウーン??ってなったけど、ActivityはViewじゃんってわかった瞬間にアハ体験した。

こういう感じになった。
f:id:hisaichi5518:20151008010641p:plain

参考

主に以下を見て学びました。

一応書いたコードはGithubにもあげた。
コミットせずに進めてしまったのでわからないけど、最初はEntityを作らずにModelにEntityに入るようなクラスも入れてたけど、Viewに渡すならModelとは別概念がいいなと思って分けるとか色々した。
hisaichi5518/retrofit-mvp · GitHub

開発スピードをあげるには

「開発スピードをあげろ!」と言われる事は多々ある。

実際にチームの開発スピードが遅かったとしたら、それは開発チームがなにかしらの問題を抱えている事になる。それに対して、偉い人達は「とりあえず開発者を増やせばスピードがあがるはず!」と人を追加する。しかし、根本的な問題は解決していないので、大きくスピードは上がらない、もしくは逆に遅くなってしまう事がある。

開発にかかる時間をざっくり分解すると「仕様決め」「コードを書く」「検証」の3つに分ける事が出来る。つまり「仕様決め」「検証」を効率良く進めて「コードを書く」時間を増やす。また「コードを書く」事自体を効率良く進める事が、開発スピードを上げる事だと考えられる。なので、3つのフェーズの問題点とそれらの解決方法を考える必要がある。

例えば、「仕様決め」の問題点は

  • 仕様が決まらず、MTGの時間が長い
  • 仕様を決める人がいない
  • 誰かに確認する事が多い
  • 開発者自身が新しい仕様に必要な現状の仕様の理解をしていない

解決方法は、「機能に関して誰が責任持って決めるのか決める」「機能に関する責任者がいない場合はMTGしない」「必要なこと・不要なことをまず最初にまとめる」など。

「コードを書く」の問題点は

  • 各開発者が、一人で考えこんで必要以上に悩んでいる
  • リファクタリングから始めて、機能開発の着手が遅れる
  • プルリクの目的から逸れたことも同じプルリクでやってしまい、マージが遅れる

解決方法は、「プルリクを分ける」「機能開発してからリファクタリングを行う」など。

「検証」の問題点は

  • 開発者が行う検証に時間がかかっている
  • 開発者がテスト項目書を作っていて時間がかかっている

解決方法は、「QAチームに委譲する」「自動テストの充実化」など。

これらはただの例で、フェーズの中でなにが問題になっているのか・それらの解決方法は、チームや個人によって違う。

まとめ

「開発にかかる時間」を分解し、それらのどこで問題が起きているのか、1つ1つ理解して対応していくことが、「開発スピードをあげる」事につながっていくと思う。

ライト、ついてますか―問題発見の人間学

ライト、ついてますか―問題発見の人間学

という日記が、Day Oneにあったので公開します。

理科系の作文技術 を読んだ。

理科系の作文技術 (中公新書 (624))

理科系の作文技術 (中公新書 (624))

長文書くの苦手で嫌いなのだけど、書く必要があるので読んだ。
長文を書くの、プログラムを書くのと似てるかもなあと思った。

  • 目標規定文
  • 目標規定文の修正
  • 主語はなにか
  • 小さいものをまとめていく
  • 意見と事実の違いを明確にする
  • はっきり言い切る
  • 文章の白さ

Android Pattern Cookbook を読んだ。

Android Pattern Cookbook マーケットで埋もれないための差別化戦略

Android Pattern Cookbook マーケットで埋もれないための差別化戦略

チームのディレクターが貸してくれたので読みました。
満員電車の中で読んでざっくりとしか読めなかったので休日にまた読み返します。

影響力の武器 を読んだ。

影響力の武器[第三版]: なぜ、人は動かされるのか

影響力の武器[第三版]: なぜ、人は動かされるのか

結構前に読んでたけど、書いてなかった。
自分の環境とかに当てはめて読むと面白い。返報性とか。