1.
コードレビューをより良くする
Danger x Android
2017/09/21(Thu)
Android Test Night #1
平田敏之(@tarappo)

2.
自己紹介
平田 敏之@DeNA / SWET (Software Engineer in Test)
ミッション
DeNAサービス全般の品質向上
DeNAエンジニアの開発生産性向上
私がやっていること(の一部)
クライアントアプリ周りのテスト戦略、自動テストの開発
CI/CD環境整備
テスト基盤環境の開発(マスティフ、ダルメシアン etc)
iOS / Android Test Night 主宰

3.
SWETのBLOGはじめました
http://swet.dena.com/
DeNA Testing Blog

4.
Danger
http://danger.systems/
• Dangerとは？ ( js / ruby )
• PRの(一次)チェックをしてくれる
• チェックするルールは自ら決める(プロジェクト次第)
• プラグインの作成も出来る
• すでに世にあるプラグインを使えば導入が簡単
• 導入事例も増えてきている
• http://techlife.cookpad.com/entry/2017/06/28/190000
• https://techblog.recruitjobs.net/development/danger_driven_development

5.
コードレビュー
コードレビューに時間がかかっていませんか？
• 本筋じゃない箇所への指摘
• チケットのリンクが貼られていない
• PRの向き先が正しくない
• コードフォーマッターに任せられるような指摘 etc
• UI変更時のチェック
• PRにスクリーンショットを貼ってもらったり..
• 変更したコードの動作確認をしているかどうか
• CI(など)で動かしているかどうか
過ぎていく時間
人間によるレビューは貴重なので自動化出来ることは自動化させよう

6.
Dangerでのチェック例
• PRの状態チェック
• ラベルやタイトルにWIPがついていないかどうか
• github.pr.titleやgithub.pr_labelsでチェック可能
• PRの本文チェック
• 対応するチケットが書かれているか
• github.pr_bodyでチェック可能
https://github.com/Moya/Moya/blob/master/Dangerfile より

7.
Danger Plugin
色々あります
• SWET製
• CONFLICT CHECKER
• SLACK
http://danger.systems/ruby より

8.
チームのルール
Androidアプリ
共通(独自Plugin化)
• WIPとタイトルやラベルに記載していないこと
• PRの説明文にチケットのURLがあること
• PRに記載されているタスク全てにチェックがついていること
Android独自(独自Plugin化)
• プロダクトコードを変更した場合
• アプリのビルド、自動テストをおこなっているか
• テストコードを変更した場合
• 自動テストをおこなっているか
• リソースを変更した場合
• スクリーンショット取得をおこなっているか

9.
コード変更時のチェックルール
• プロダクトコードを変更した場合
• ビルド、テストを実行する必要あり
• ビルド・テストが成功(1)
• (1)から最新のコミットまでの間にプロダクトコードに変更なけれ
ば再度実行する必要はない
• テストコードを変更した場合
• テストを実行する必要あり

10.
UI変更時のチェックルール
• リソースを変更した場合
• 各画面のスクリーンショットをPRにいれこむ
• UIテスト(Spoon)を用いて各画面のスクリーンショットを取得
• githubの機能で前回の画像と比較できる

11.
レビューまでのフロー
• PRを出す(WIPでもOK)
• 設計相談をする場合は早めに出す
• 実装が完了
• CIで動かすべきものは動かしておく
• PR上でreviewとコメント
• ルールを全てクリアしていたら
• メンバーにレビュー依頼が飛ぶ

12.
ルールをクリアしなかった場合
実際の指摘例
指摘理由
• WIPとタイトルに記載されている
• PRの本文にチケットのURLが無い
• ソースコード変更後にアプリのビルドをおこ
なっていない
• テストコード変更後にテストの実行をおこな
っていない

13.
まとめ
• コードレビュー前の指摘(の一部)は自動化しよう
その結果
• 実装者(レビューイー)
• 何をするべきかルール化されている、間違えれば指摘されるので分かりやすい
• レビュアー
• (多少の)安心感をもってコードレビューができる
• 本質的な箇所をコードレビューできるようになる