コードレビューの文化を少しずつ改善していった話

#code_kaizen
コード改善 #3 で発表したスライドです。

Transcript

1. コードレビューの文化を少しず つ改善していった話 Yasuhiro Kiyota @yasuhiroki
2. 自己紹介
3. 自己紹介 • Yasuhiro Kiyota • @yasuhiroki • Twitter: @duck_yasuhiroki • GitHub: https://github.com/yasuhiroki • 開発者（個人）のためのJenkins - Git Plugin編 • http://qiita.com/yasuhiroki/items/61a2be613fc7dcfc8682 • そのシェルスクリプトもうちょっとシンプルに書けそう Tips集（Golf/シェル芸ではない） • http://qiita.com/yasuhiroki/items/fad876db9e5505fceb03
4. https://certificates.cloudbees.com/10203903
5. 趣味 n=1 s='n=%d\40s=%s\40eval\40$\47printf\40"#改善レベル ${n}\n${s}"\40"$((+ +n))"\40"${s@Q}"\47' eval $'printf "#改善レベル ${n}\n${s}" "$((++n))" "${s@Q}"'
6. 本題
7. 謝辞
8. 前回のコード改善#2で発表しました https://www.slideshare.net/yasuhirokiyota/ss-68577272
9. 前回のコード改善#2への感謝 • 自分の発表に対するTwitterの反応 • 「似たような取り組み自分たちもやってる」 • 「XXな方法もあるよ」 • 他の方の発表 • 自分とは違う視点での改善方法 • 視野が広がった • 議論タイムでの意見交換 • 自チームを客観的に見ることができた
10. Agenda • 前回の発表 (2016/11) から
 現在 (2017/06) までの取り組み・成果 • （ちなみに）開発はGitHubで進めています
11. 前回発表のおさらい
12. 前回発表のおさらい • まずは、とにかく話す • コードレビューに不慣れな人とまずは話す • 話したやりとりをGitHub上にも残してもらう • 自然とGitHubだけでも議論できるようになった • GitHub テンプレート・ラベルの活用 • WIP、 PleaseReview ラベル • 初心を忘れない • どんな思いから、
 どんな文化を作りたかったのか忘れない
13. 前回参加時に感じた自チームの <課題> • テスト書いてない • typoやインデントのチェックも人間まかせ • 機械的なレビューは機械に任すべき • 良いコードとは何か、チームとして答えを持っていな い • ふわふわとした不安感 • これでいい…のかなぁ…
14. 前回参加時に感じた自チームの <強い所> • 全員がレビューワー • 上司・先輩・後輩 関係なく全員がレビューワー • コードレビューに対する意識が統一されている • レビューはお願いするもの • マージは自分でするもの • レビューワーへの優しさ • レビューしやすいcommit粒度にする意識が高い • “fix” だけのコミットメッセージはない • 万一あった時は、朝会で愛のある吊し上げにあう
15. 現在の環境
16. 前回から変わった現在の環境 • プロジェクトが変わった • TypeScript + AngularJS なあれこれ • TypeScript + Express なあれこれ • TypeScript + AWS Lambda なあれこれ • メンバーはほぼ変わらず • 手探りで作った文化をそのまま継承できた • 文化はできているので少しずつ改善
17. 取り組んだこと
18. 取り組んだこと • テスト書いた • Jenkins で PR 毎に自動ビルド • 動作検証用の環境をDockerで用意 • 結合テスト用の環境を簡単に用意できる • 動作確認がスムーズに
19. 取り組んだこと • プルリクエスト テンプレートの改善 • どういう観点で動作確認したか書くことを必須に • 開発者QAと呼んでいる • 「XXした時にYYとなることをUTで担保」 • 「＊＊の処理が最後まで実行されること」 • QAを専門にしてきたメンバーがいるので、
 テスト観点のレビューもしてもらっている • レビューワーは、
 仕様通りにテストされているか簡単に知ることがで きる
20. 開発者QAの背景 • QA担当がチームに１人いる • 最終的な評価は全てその人任せに • スケールしない • その人は別のタスクもある • 開発者がQAできるようになればいい • 開発者がQAした内容をレビューしてもらいたい • コードレビューと同じタイミングでやれば良い
21. 取り組んだこと • 設計資料もコードレビュー • PlantUML で システム構成図を書く • PlantUMLと生成される画像を一緒に git push • 設計のレビューもGitHub上に残す • 設計資料もコードと見なして世代管理 • 参考） PlantUML • http://plantuml.com/ • http://qiita.com/ykawakami/items/ f6688b845945669f0ce5
22. 安心と自信をもって
 マージできるように
23. 取り組んだこと • 朝会でのゲリラレビューを実施 • 朝会で突発的に、適当なプルリクをピックアップ • 内容をメンバー全員で確認 • がっつりコードレビューするわけではなく、
 「こういう書き方 XX さんぽいねー」
 「このプルリクもっとレビューしやすくできそう」 
 などと表面的な意見交換をする • チームでコードレビューしてる感
24. 意識の変化 • テストしやすいコードとは、を意識するように • どんなコードだと簡単なのか議論が活発に • 口頭のやりとりはコードレビューにも残す • （残せてないもの増えてきたかも…） • 良いコードとは、の模索がチーム共通の課題に • たまに朝会で議論
25. 開発者QAの義務化の恩恵 • 何をテストしたか、のエビデンスが残る • テスト漏れがあった時に振り返られる • テスト観点に対するレビューも行える • 全員で品質を守る意識
26. 課題
27. コードレビューの負荷増 • 開発者QAへのレビューが特に… • レビューワーの担当が何となく決まっている • タイミングによっては１人に負荷が集中しがち • まんべんなくレビューできる人ほど負荷高い • レビューツールを入れて改善したい.. • Danger を試し中
28. おしまい