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