Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

49,440 views

Published on

Forkwell Meetup #3
https://forkwell.connpass.com/event/48147/

Published in: Technology
  • Visit this site: tinyurl.com/sexinarea and find sex in your area for one night)) You can find me on this site too)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Sex in your area for one night is there tinyurl.com/hotsexinarea Copy and paste link in your browser to visit a site)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Girls for sex are waiting for you https://bit.ly/2TQ8UAY
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Meetings for sex in your area are there: https://bit.ly/2TQ8UAY
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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

  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

×