チームで育てるAndroidアプリ設計を読んだ

マスタカと言えば、
Androidエンジニア
エンジニアリングマネージャー
そんなわけで、チームとAndroidの本書を読んでみた

・本書の内容
アーキテクチャを中心にチームの生産性を落とさない方法を書いた本
組織まで踏み込んでるのが面白い
アーキテクチャに興味ある人
チーム開発に興味がある人
マネジメントに興味がある人
であれば楽しく読めると思う

・アーキテクチャ選定の理由
生産性を下げずに開発を進めるため

・MVVMとだけ決めた場合
アーキテクチャが決まってないと人によって実装がバラバラになる
MVVMとだけ決めおいておいた方がましだけど
命名規則がバラバラだったり
コールバックの実装方法がバラバラになる
なのでMVVMと決めただけだとまだ足りず、統一性がなくなる

・アーキテクチャの選定の基準
リードの習熟度を考慮して選定する
学習コストが高いと習熟に時間がかかるため
加えて開発者のモチベーションも考慮する

統一されていることとコスパが重要なので、コスパを無視すればどれを選んでも最終的に問題ないとは思う

・レイヤーで分ける場合
2層：プレゼンテーション + データ層
3層：プレゼンテーション + ユースケース + データ層
4層：プレゼンテーション + ユースケース + ドメイン層 + データ層

・冗長と統一性
どちらかを重視するなら、統一性
冗長でも同じように書こう

場所によって挙動が揃ってないと
後から来た人がどっちが正しいのか悩むことになる

・アーキテクチャが浸透している状態とは
1. 実装するクラスと分け方の名前が揃っている
2. 公開するインターフェイスレベルと名前がそろってる
ここまでやれれば普及している
さらに
3. プライベートな関数やメンバーまでそろってる
4. 関数の中身の実装まで揃ってる

・アーキテクチャを普及させるには
ドキュメントを用意する
概要図
パッケージ構造
層の説明
各クラスの説明

また、コーディング規約のドキュメントを作るときはサンプルコードも書くべき

・クラス図のレビュー
UMLでクラス図をかいて、emptyコミットしてPRを投げてれレビューを受ける

これはやったことないので、そういう考えもあるんだなぁって思った

・負債の解消
あるコードを修正して負債を解消しようとする場合
一時的に一貫性が崩して徐々に負債を解消することになる
このときには、EXCEL等で一覧を作り、各々に担当をつけるマネジメントになる

・組織構造
育成はチームメンバーの数が多い方がやりやすい
ジュニアが占める割合が小さい方が影響は少ないため

リードエンジニアがコード書く時間が減る問題
ジュニアを一次、二次レビューにリードエンジニアをアサインし、そのうちジュニアだけのレビューにするとのこと
これは分かるんだけど、レビューは二人の方が良いと思うのでこれには反対

・活躍できる人間
新規開発：フルスタック志向
大規模開発：専門性

ただし、新規開発でもアーキテクチャ決める場合、専門性が必要になる

本書はとてもためになりました
ぜひ読んでみてください