良いユニットテストの書き方、イベントログの確認方法とaskenさんおふたりの発表内容が自社課題にダイレクトヒットして明日から実践したいと思える内容だった。失敗談から導かれた「コト」に向かう組織作りの取り組みも、目指したい効果に立ち返ってトライしたいと思った。
イベントページ:https://hey.connpass.com/event/335971/
開発生産性から振り返るエンジニアリングマネジメントの失敗2選
@sudo5in5k さん
- Four Keys の計測結果から得られたEMとしての失敗
- ドメイン知識に対するメンバー間の知識差から、組織体制変更の影響が発生 → 誰が欠けても生産性を出し続ける仕組みづくり
- 組織で「コト」へ向かうために
- モブプロ/ドキュメント作成/プロセス標準化(担当が変わっても取り組めるくらい丁寧に。チケット、PR、docs)
- Four Keys 測定意図のすり合わせ
- 本来の意図は健康状態の測定だったが手段と目的が逆転
- 共通理解・共通価値観の設定が大事 → パフォーマンスを出すにはケイパビリティを変えよ(DORA Core Model から)
- 個人の価値観にブレはあるが、会社のバリューは絶対的価値観
- バリューに即した価値観や行動の洗い出し
いいね問題に対する技術選定事例
@tfandkusu さん
- 「いいね問題」:詳細から「いいね」して一覧に戻ったら、当然のように「いいね」ついて欲しい、それをどう実現するのか(3現場の手法比較)
- SQLite:なぜストレージに保存?(Android):OS によるプロセスキルからの復帰挙動のため
- SQLite:要件オーバー、学習コスト高い → 最終的にオンメモリに保存へ(都度サーバーから取得し直せば良い)
「良いユニットテスト」を書こう
@decoymaker さん
- Google のテスト戦略:上にいくほど fidelity が上がりテストの実行に時間がかかる
- TDD だったら実装しながら早期にバグ発見、影響範囲の考慮漏れを受託開発ねしゅつしやすい、テスト書きにくい=関数やクラス設計が悪い→改善しやすい
- テスト対象:MVVM のうち、Model 層はマスト、VM は条件分岐多いなど複雑なところに限定。Viewは書かない(Component testとしてスクショとって比較するよう検討している)
- 良いユニットテストとは?信頼性と可読性
- 信頼性
- テスト結果が不安定:実行のたびに結果が変わる(システム時刻 / DB / SharedPreferences)
- 偽陰性、偽陽性が発生しないこと:バグがあるのに検知できない、正しいのにテスト失敗する
- 可読性
- AAA (arrange/asert/act) 記法 ← こっちを使っている
- Gherkin 記法(given/when/then/and/but)
- テスト計測はDRY原則無視して良い、上から読み下せるように
- テストに必要なデータは計算で作らずベタ書きしよう
- 更なる効果:プラットフォームまたいでテストコードのレビューができるようになり、仕様差異を事前検知できた
アプリ起動時間を80%高速化した話
@n3k0w3n さん
- 在庫数全件取得に時間がかかっていた(N+1問題)
- GraphQLの書き方によりパフォーマンスチューニングを実施
- 副次効果として取得中のクラッシュも改善した(concurrency 対応とか、リファクタリングによって、なぜか)
- 「推測するな計測せよ」
Androidアプリのモジュール分割における:x:common
を考える
@okuzawats さん
- モジュール分割の狙い:開発速度を維持していくこと、予測できない変化にすばやく対応できる
feature
のcommon
モジュールについて- よく考えずに実装すると、
common
に多くの実装が集約して本来やりたかったモジュール分割ができない状態になる - 課題に対応するために実践したこと
- 重複を恐れない
- 複数のサブモジュールに対する影響が発生してしまうので、各モジュールにコードを置くことで解決
- サブモジュールの分割単位を考え直す
- モジュール間で異なる変更がされるのなら、それぞれのモジュールで実装した方が良い
- モジュール間で同じように変更されるなら、同じモジュールに入れるべき
- 既に大きな
common
モジュールを、どう小さくするか:モジュール単位で依存関係逆転原則を適用
UI State設計とテスト方針
@_rmakiyama さん
- ReactorKit:ViewModelまでKMPで共通化している
- 実現したいのは単方向のデータフロー
- Step 1:責務が集約され過ぎているのでは
- Step 2:状態による条件分岐を意識する必要がなくなり関心の分離もできている
- これを踏まえてテストをどう書くか
- UI State は UI が取りうる状態を定義している
- UIテストの責務を絞ること(そうしないとコストがかかってしまう)
Firebaseイベントログの動作確認を効率化する話
@t_osawa_009 さん
- ログの取れ方が期待通りでなかったり、iOS/Android とで差分あったりした
- Firebase の DebugView は面倒だったり、デバッグコンソールも色んなログが混ざってしまっている
- 画面仕様書を整備し、認識をそろいやすくした
- 開発者でなくても使えるようにデバッグメニューを改善した
- 発火タイミングをアプリ上に表示できるようにしたことで、Firebase DebugView よりも手軽に
- 命名をルール化、ユニットテストなどを通じてチェックするようにした
- リリース前に確認修正が行えるようになり、結果リリース後の修正が減った
10年もののバグを退治した話
@n_seki_ さん
- コマンドをC言語で実装しiOS/Androidで使用していた社内ライブラリに潜んでいたバグの解決
- クラッシュログをシンボル化できず、スタックトレースからは情報が追えない
- アクションログなどと組み合わせて、傾向条件掴められないだろうか?
- 二分探索的にコードをコメントアウトしながら最終的に特定した