More Related Content
Similar to 「速」を落とさないコードレビュー (20)
More from Takafumi ONAKA (20)
「速」を落とさないコードレビュー
- 2. 自己紹介
• 大仲 能史 a.k.a. @onk
• 株式会社ドリコム 11年目
– アプリケーションスペシャリスト
– Rails 歴が一番長くて 8 年ぐらい
• 趣味
– コードを読むこと
• 社内リポジトリ 1800 のうち 300 ぐらい watch 中
– 社内ツール作成
1
- 3. 宣伝
• ドリコムは Elixir CONF Japan 2017 の
Gold Sponsor です
– セッションもあるよ
• Elixir, Ruby エンジニアに限らず
色んな職種を積極採用中なので
交流タイムに声かけてください!
2
- 8. 100コメントにかかる時間
• Pull Request が出る
• 気づく (5min)
• やりたいことを把握する (5min)
• コメントする (10min)
• レスがある or 修正のコミットがある (120min)
• ↑をn往復 (10~20hour)
• 何も成果がリリースされないまま1日が終わる
7
- 15. コードレビューでやったこと
• コードフォーマット
• 眼鏡を外してレビュー
• 記述が分かりやすいか
• セキュリティ担保
• パフォーマンス担保
14
ユーザ入力をそのまま ORDER BY に
入れたらダメです。asc, desc かど
うかを確かめてから
HTML を自前で組み立てていて、
XSS 脆弱性があります
validate するようにしてください
UNIQUE 制約忘れずにー
- 32. 僕がよく使うフォーマット
• 目的
• 方針
• 実装
• テスト
• 相談
31
• 何を考えてこの PR を作ったのか、み
たいなのがあれば
• 考えた結果、除外したものがあれば
書いて欲しい
• 例) 「GitLab に似たような画面が
あったので同じ model 構造にした」
「1 万件程度なので LIKE 検索で十分
実用に耐える速度が出せると判断」
- 33. 僕がよく使うフォーマット
• 目的
• 方針
• 実装
• テスト
• 相談
32
• 方針に沿って実装していく中でレ
ビュアーに伝えるべきものがあれば
補足
• コードだけだと実装意図を読み解き
づらい場合に図や疑似コードで流れ
を説明するとか
- 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
- 52. レビュアー・レビュイーの関係性
• 問題 vs. 私たち、という大前提
– レビュイーは人格攻撃と受け取らない
– レビュアーは権威的になってはいけない
• フィードバックは感情を押し付けるも
のではなく、受け手が成果物をより良
くするために必要な情報を届けること
51
- 56. レビュアーが固定されている
• 常にベテラン → ルーキーの方向のレビューしか無い状態
は健全ではない
– ベテランの無駄遣い問題
• レビューコストを外して開発に専念して欲しい
– ベテランを信用しすぎ問題
– ルーキーの成長が悪い問題
• レビューはする側に回った方が教育効果が大きい
55