マルチモジュールなプロジェクトでテストはどう変わる?
- テストを書く意識は上がった
- PITが便利そうだった
- コードの変更で今書いているテストが失敗するか?を確認することで、テストケースの妥当性を判定してくれるライブラリ
マルチモジュールプロジェクトでのDagger2を用いたDependency Injection
- DIの利用により疎結合となり、コンポーネント間の依存性が下がることで、テスタビリティが上がる
- Daggerは どこに 何を injectするかを定義する
- 何を → module
- どこに → component
- fragmentInjectorが複数のinjectorを持てるように実装することで、マルチモジュールにも対応できる
LiveData と Coroutines で実装する DDD の戦術的設計
- 昨年よりも、より実践に近いDDD講座
- 話すペースや声のトーンがちょうど良く、すごく聞きやすかった。
- ユビキタス言語を探しながら、値オブジェクトやエンティティを定義していく
- idをIntではなくエンティティにするという発想が新鮮だった
data class Session(val id: SessionId)
data class SessionId(val value: Int)
data class Session(val id:Int)
- モデルの形式が保存形式(DBの情報)と一致させる必要はない
- 例えば、セッション一覧に表示するイベントとして、通常のセッション以外にもウェルカムトークやランチタイムを表示する場合
- DB的には、Eventテーブルにtypeをもたせて保存する
- フロントのモデルとしては、typeを使わなくても、
seald class
で表現できる
seald class Event {
abstract val id: Int
abstract val userName: String
data class Session(override val id: Int, override val userName: String, val title: String) : Event()
data class Lunch(override val id: Int, override val userName: String) : Event()
}
ぼくのかんがえた最強のUsecaseの作り方~あるいはビジネスロジックとはなにかという1つの回答~
- Reduxについてに実装例
- オフィスアワーで聞いてみた
- Q: Storeの初期化はApplicationクラス?
- A: Dagger使ってるので、そっちで管理されてる。ライフサイクル的にはApplicationと同じ
- Q: FatStoreにならないか?
- A: 現状困っていない。ストアが持つ情報がネストしていくので、深くはなるがFatにはならなそう
- Q: 画面遷移などはReduxで管理しないなら、どこに書く?View側
- A: Activityなどで、startActivity()やfinish()すればいい
- Q: マルチモジュールになったらどうすれば
- 後ろがならんでて焦ってたのか、聞いた内容忘れてしまった・・・
Fireside Chat
- 何を考えたか、何に苦しんだかをカジュアルに語ってくれた
- 理解できないところもあったが、こういう情報はなかなかウェブの情報として上がってこないので、すごく助かる
感想
- 今年は2回目ということもあり、多少余裕があった。
- コントリビュートできたし、意識して前に座るようにしたし(去年はずっと後ろの席)、オフィスアワーで初質問できた
- 2日目も頑張る