「速」を落とさないコードレビュー

「速」を落とさないコードレビュー

1. 1. 「速」を落とさない コードレビュー 2017-01-28 Forkwell Meetup #3 Productivity Engineering 大仲 能史 a.k.a. @onk
2. 2. 自己紹介 • 大仲 能史 a.k.a. @onk • 株式会社ドリコム 11年目 – アプリケーションスペシャリスト – Rails 歴が一番長くて 8 年ぐらい • 趣味 – コードを読むこと • 社内リポジトリ 1800 のうち 300 ぐらい watch 中 – 社内ツール作成 1
3. 3. 宣伝 • ドリコムは Elixir CONF Japan 2017 の Gold Sponsor です – セッションもあるよ • Elixir, Ruby エンジニアに限らず 色んな職種を積極採用中なので 交流タイムに声かけてください！ 2
4. 4. 今日の話 ユーザに 価値を 届ける 3 最低限の 品質を 保つ レビュー の基盤を 作る
5. 5. 前提 • 事業会社の話 – 人月単価ではないサービスを提供している • Pull Request 駆動開発をしている – これができていない場合は 「マジカルsvnとキュアgit」 を見てください 4 http://www.slideshare.net/takafumionaka/20130322-svngit
6. 6. やってしまったレビュー風景 5
7. 7. やってしまったレビュー風景 6
8. 8. 100コメントにかかる時間 • Pull Request が出る • 気づく (5min) • やりたいことを把握する (5min) • コメントする (10min) • レスがある or 修正のコミットがある (120min) • ↑をn往復 (10～20hour) • 何も成果がリリースされないまま1日が終わる 7
9. 9. 何もリリースできない徒労感 かつ ひたすら指摘され続けて疲弊 8
10. 10. このコードレビューでは 何をやっていたのか 9
11. 11. コードレビューでやったこと • コードフォーマット • 眼鏡を外してレビュー • 記述が分かりやすいか • セキュリティ担保 • パフォーマンス担保 10 • コードが仕様を満たして いるか • 仕様に考慮漏れが無いか • エンバグは無いか • 良い設計をしているか
12. 12. コードレビューでやったこと • コードフォーマット • 眼鏡を外してレビュー • 記述が分かりやすいか • セキュリティ担保 • パフォーマンス担保 11 • スペースとかインデン トとか typo とか = の右に半角スペースが2つあります シングルクォートじゃなくダブル クォートを使うようにしてください regist m9(^Д^)ﾌﾟｷﾞｬｰ
13. 13. コードレビューでやったこと • コードフォーマット • 眼鏡を外してレビュー • 記述が分かりやすいか • セキュリティ担保 • パフォーマンス担保 12 • メソッドの長さとか ネストの深さとか http://postd.cc/code-review-without-your-glasses/
14. 14. コードレビューでやったこと • コードフォーマット • 眼鏡を外してレビュー • 記述が分かりやすいか • セキュリティ担保 • パフォーマンス担保 13 • メソッド/変数名とか 簡潔なロジックとか guard 句で早めに raise したい Array#detect 使うともっとシンプル score って変数に kind の値が入っ てるけど score じゃないような
15. 15. コードレビューでやったこと • コードフォーマット • 眼鏡を外してレビュー • 記述が分かりやすいか • セキュリティ担保 • パフォーマンス担保 14 ユーザ入力をそのまま ORDER BY に 入れたらダメです。asc, desc かど うかを確かめてから HTML を自前で組み立てていて、 XSS 脆弱性があります validate するようにしてください UNIQUE 制約忘れずにー
16. 16. コードレビューでやったこと • コードフォーマット • 眼鏡を外してレビュー • 記述が分かりやすいか • セキュリティ担保 • パフォーマンス担保 15 N+1 気を付けてー 不要なインスタンスを作らない 二重ループになっているけど、工夫 したらループ1回で済みます
17. 17. コードレビューでやったこと • コードフォーマット • 眼鏡を外してレビュー • 記述が分かりやすいか • セキュリティ担保 • パフォーマンス担保 16 • コードが仕様を満たして いるか • 仕様に考慮漏れが無いか • エンバグは無いか • 良い設計をしているか
18. 18. コードレビューでやったこと • コードフォーマット • 眼鏡を外してレビュー • 記述が分かりやすいか • セキュリティ担保 • パフォーマンス担保 17 最低限の守りたい品質
19. 19. コードレビューでやったこと リリースしたら価値が届 く、本来レビューすべき だったもの 18 • コードが仕様を満たして いるか • 仕様に考慮漏れが無いか • エンバグは無いか • 良い設計をしているか
20. 20. コードレビューでやったこと • コードフォーマット • 眼鏡を外してレビュー • 記述が分かりやすいか • セキュリティ担保 • パフォーマンス担保 19 最低限を満たしていな いと、違和感が酷くて 本来のレビューに入る ことができない
21. 21. 「最低限の水準を保とう」 という話をし過ぎると スピードが低下する 20
22. 22. でも最低限の水準にはなる 21
23. 23. 最低限を満たすのにレビューは要るのか • コードフォーマット – コードフォーマッタで自動修正 – スタイルガイドを作って配布 • 眼鏡を外したレビュー – 行数やネスト、循環的複雑度やABC Metric等、機械的に指摘 できる • Rubyらしさとか、他のメソッド名との整合性とか – まだレビューが必要だが、数年後には自動化できそう 22
24. 24. 最低限を満たすのにレビューは要るのか • セキュリティ担保 – まだレビューが必要だが、良いフレームワークを使うことで 足元を撃ち抜かない書き方を強制できる • パフォーマンス担保 – まだレビューが必要だが、例えば N+1 を自動検出するツール は存在するので上手に使おう 23
25. 25. 最低限の品質を 機械的にチェック することができる 24
26. 26. 機械相手に試行錯誤する環境を 作るとレビューコストが大幅減 25
27. 27. 本来レビューすべきだったもの リリースしたら価値が届 く、本来レビューすべき だったもの 26 • コードが仕様を満たして いるか • 仕様に考慮漏れが無いか • エンバグは無いか • 良い設計をしているか
28. 28. 本来レビューすべきだったもの もっと短縮できないだろうか？ 27
29. 29. コード差分の理由を書く 28 http://techlife.cookpad.com/entry/2015/03/30/174713
30. 30. 僕がよく使うフォーマット • 目的 • 方針 • 実装 • テスト • 相談 29
31. 31. 僕がよく使うフォーマット • 目的 • 方針 • 実装 • テスト • 相談 30 • この PR をマージすると以下のことが できるようになりまぁす！ • 仕様書や Issue があればリンクを貼る
32. 32. 僕がよく使うフォーマット • 目的 • 方針 • 実装 • テスト • 相談 31 • 何を考えてこの PR を作ったのか、み たいなのがあれば • 考えた結果、除外したものがあれば 書いて欲しい • 例) 「GitLab に似たような画面が あったので同じ model 構造にした」 「1 万件程度なので LIKE 検索で十分 実用に耐える速度が出せると判断」
33. 33. 僕がよく使うフォーマット • 目的 • 方針 • 実装 • テスト • 相談 32 • 方針に沿って実装していく中でレ ビュアーに伝えるべきものがあれば 補足 • コードだけだと実装意図を読み解き づらい場合に図や疑似コードで流れ を説明するとか
34. 34. 僕がよく使うフォーマット • 目的 • 方針 • 実装 • テスト • 相談 33 • マージボタンを押してもらうための 安心できる材料 • 例) 「実機で一覧表示を確認した」 「DBA にクエリを見てもらって OK 貰ってます」
35. 35. 僕がよく使うフォーマット • 目的 • 方針 • 実装 • テスト • 相談 34 • 書いてみたものの自信が無いところ とか • diff の中にラインコメントの形で書い ても良い
36. 36. PRの目的とコード差分が分かるように もっと短縮できないだろうか？ 35
37. 37. レビューの前提条件を提示する • レビュアーに求めているレビュー内容を書いておく – 例) リリース直前なので、ブロッカーになるような不具合が無 いかどうかのチェックをお願いします • これによって減るレビュー – typo の指摘 – そもそも論 36
38. 38. 不要なレビューが減った もっと短縮できないだろうか？ 37
39. 39. 成果物が見える状態でレビューする • Before/After のスクリーンショットを貼る – 変化する対象がより分かりやすくなるので マージしやすくなる • Pull Request 単位で自動デプロイする – 動作確認がサクッと終わるので マージしやすくなる 38
40. 40. マージまでが速くなった もっと短縮できないだろうか？ 39
41. 41. 方針の段階でレビューする • 生煮え Pull Request (WIP) – 「migration と routes 書いたら push してね」 – 全体を書く前にレビューすることができるので 無駄になるコード量が激減する 40 https://speakerdeck.com/ken_c_lo/pull-request-4-designers- githubwoshi-tutapuroguramatodezainafalseitereteibunakai-fa- huro
42. 42. 方針の段階でレビューする • 設計レビュー – 設計のみを Markdown で書いて Pull Request する – description に書く場合と違い • ラインコメントができる • コメントに対する修正がコミットになり、追いやすい 41 http://blog.shibayu36.org/entry/2016/08/05/103000
43. 43. もっと短縮できないだろうか？ 42
44. 44. サービス開発はゴールが分からないのが前提 • 不確実な状況下にある – ユーザが本当に欲しいものって分かってる？ • 今見えるゴールが正解である保証も無い • リリース後が 8 割 • サービスのリリースはスタートにすぎない 43 速い馬！
45. 45. リリースを躊躇しない • Pragmaticであること Dogmaticにならないこと • リリースしてから Be Professional Day で 綺麗にする 44 https://speakerdeck.com/hirak/mercariday2017-api
46. 46. ここまでのまとめ 45 レビュー の基盤を 作る ユーザに 価値を 届ける 最低限の 品質を 保つ
47. 47. 最低限の品質を保つ • コーディング規約を用意する • 機械に指摘させることで – 一人で試行錯誤できる状況を作る 46
48. 48. ユーザに価値を届ける • レビューは「改善する」行為 – 改善は損失を減らすが、何かを作ってはいない • レビューによってリリースが遅くなるのは本末転倒 • 素早くマージできる状態を作っていこう – レビュアーとの意思疎通に気を払ってPull Requestを出す 47
49. 49. レビューの基盤を作る 48
50. 50. レビューの目的はさまざま • 最低限の品質担保 • 不安の解消 • 属人化を防ぐ • レビュイーの教育 • チームビルド • etc… 49
51. 51. 関係性のアンチパターンがある 50 http://www.songmu.jp/riji/entry/2014-01-19-cross2014.html
52. 52. レビュアー・レビュイーの関係性 • 問題 vs. 私たち、という大前提 – レビュイーは人格攻撃と受け取らない – レビュアーは権威的になってはいけない • フィードバックは感情を押し付けるも のではなく、受け手が成果物をより良 くするために必要な情報を届けること 51
53. 53. 心理的安全性 • 不具合のある状態でリリースしたい人は居ない – レビュイーは悪意でバグを作っているわけではない – レビュアーは悪意で指摘しているわけではない • というのを分かりやすくするために – レビュイーは前提をしっかり提示する – レビュアーは伝え方を丁寧にする 52
54. 54. レビューは取り込むもの • 本来コードレビュー文化のあるべき正しき姿はチーム間 で議論をしてサービスにとって最終的に良いと判断した ことを取り込むこと • レビュアーからレビュイーへの一方的な指摘にしない – 納得をして「取り込む」 – 納得していれば「指摘対応」というコミットメッセージには ならない 53 http://yutokyokutyo.hatenablog.com/entry/20161213/148159 0322
55. 55. レビューは取り込むもの • 納得していなかったら同じ指摘を繰り返すことになる • レビュイーは納得していない指摘を繰り返し受ける – やらされる感++ – 自己効力感— • 権威に頼りつつレビューする – 「条件式が分かりづらいです。リーダブル コード 7.1 参照」 – リーダブルコード、リファクタリングがド安定 54
56. 56. レビュアーが固定されている • 常にベテラン → ルーキーの方向のレビューしか無い状態 は健全ではない – ベテランの無駄遣い問題 • レビューコストを外して開発に専念して欲しい – ベテランを信用しすぎ問題 – ルーキーの成長が悪い問題 • レビューはする側に回った方が教育効果が大きい 55
57. 57. レビュイーからレビュアーへ • 二段階レビューを導入 – ルーキーがレビューして、その後ベテランがレビューする – ルーキーが見落としするたびに心に爪痕が残り、学ぶ – ルーキーで役に立つのか？は、やり方次第 • 「ここよく分かんないです」を言うだけで価値がある • 分かりづらい部分はだいたい怪しい • テスト書いてなくね？も言って欲しい • ルーキーから指摘する障壁をどんどん取り除きたい 56
58. 58. レビュイーからレビュアーへ • レビュータイムを設ける – 全員がレビュアーとなる – ルーキーからレビューする 障壁を外す – 溜まったレビュー待ちの Pull Request が消化される 良い副作用もある • 最初はそちらを目的にしていた 57
59. 59. まとめ 58
60. 60. 今日の話 ユーザに 価値を 届ける 59 最低限の 品質を 保つ レビュー の基盤を 作る
61. 61. レビューの基盤を作る • レビュイーとレビュアーの関係性に気を遣う – 「問題 vs. 私たち」 – 「空気を導入しない」 • レビュイーが育っていく道筋を敷く – ルーキーだからレビュアーになれないわけではない 60
62. 62. ご清聴ありがとうございました 61