Submit Search
Upload
「速」を落とさないコードレビュー
•
419 likes
•
55,620 views
Takafumi ONAKA
Follow
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/
Read less
Read more
Technology
Report
Share
Report
Share
1 of 62
Download now
Download to read offline
Recommended
Oss貢献超入門
Oss貢献超入門
Michihito Shigemura
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
onozaty
こわくない Git
こわくない Git
Kota Saito
何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門
masayoshi takahashi
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
Recommended
Oss貢献超入門
Oss貢献超入門
Michihito Shigemura
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
onozaty
こわくない Git
こわくない Git
Kota Saito
何となく勉強した気分になれるパーサ入門
何となく勉強した気分になれるパーサ入門
masayoshi takahashi
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
エンジニアから飛んでくるマサカリを受け止める心得
エンジニアから飛んでくるマサカリを受け止める心得
Reimi Kuramochi Chiba
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
例外設計における大罪
例外設計における大罪
Takuto Wada
関数型プログラミングのデザインパターンひとめぐり
関数型プログラミングのデザインパターンひとめぐり
Kazuyuki TAKASE
オブジェクト指向できていますか?
オブジェクト指向できていますか?
Moriharu Ohzu
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
C++ マルチスレッド 入門
C++ マルチスレッド 入門
京大 マイコンクラブ
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
Glibc malloc internal
Glibc malloc internal
Motohiro KOSAKI
良い?悪い?コードコメントの書き方
良い?悪い?コードコメントの書き方
Shigenori Sagawa
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
GoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホン
Akihiko Horiuchi
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略
Takayuki Shimizukawa
Docker Compose 徹底解説
Docker Compose 徹底解説
Masahito Zembutsu
Twitterのsnowflakeについて
Twitterのsnowflakeについて
moai kids
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
できる!並列・並行プログラミング
できる!並列・並行プログラミング
Preferred Networks
プログラマが欲しい仕様書とは
プログラマが欲しい仕様書とは
Katsutoshi Makino
XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」
XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」
Shuji Morisaki
More Related Content
What's hot
エンジニアから飛んでくるマサカリを受け止める心得
エンジニアから飛んでくるマサカリを受け止める心得
Reimi Kuramochi Chiba
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
例外設計における大罪
例外設計における大罪
Takuto Wada
関数型プログラミングのデザインパターンひとめぐり
関数型プログラミングのデザインパターンひとめぐり
Kazuyuki TAKASE
オブジェクト指向できていますか?
オブジェクト指向できていますか?
Moriharu Ohzu
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
C++ マルチスレッド 入門
C++ マルチスレッド 入門
京大 マイコンクラブ
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
Glibc malloc internal
Glibc malloc internal
Motohiro KOSAKI
良い?悪い?コードコメントの書き方
良い?悪い?コードコメントの書き方
Shigenori Sagawa
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
Masahito Zembutsu
GoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホン
Akihiko Horiuchi
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略
Takayuki Shimizukawa
Docker Compose 徹底解説
Docker Compose 徹底解説
Masahito Zembutsu
Twitterのsnowflakeについて
Twitterのsnowflakeについて
moai kids
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
できる!並列・並行プログラミング
できる!並列・並行プログラミング
Preferred Networks
What's hot
(20)
エンジニアから飛んでくるマサカリを受け止める心得
エンジニアから飛んでくるマサカリを受け止める心得
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
例外設計における大罪
例外設計における大罪
関数型プログラミングのデザインパターンひとめぐり
関数型プログラミングのデザインパターンひとめぐり
オブジェクト指向できていますか?
オブジェクト指向できていますか?
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
C++ マルチスレッド 入門
C++ マルチスレッド 入門
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
TLS, HTTP/2演習
TLS, HTTP/2演習
Glibc malloc internal
Glibc malloc internal
良い?悪い?コードコメントの書き方
良い?悪い?コードコメントの書き方
Dockerfile を書くためのベストプラクティス解説編
Dockerfile を書くためのベストプラクティス解説編
GoによるWebアプリ開発のキホン
GoによるWebアプリ開発のキホン
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略
Docker Compose 徹底解説
Docker Compose 徹底解説
Twitterのsnowflakeについて
Twitterのsnowflakeについて
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
できる!並列・並行プログラミング
できる!並列・並行プログラミング
Similar to 「速」を落とさないコードレビュー
プログラマが欲しい仕様書とは
プログラマが欲しい仕様書とは
Katsutoshi Makino
XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」
XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」
Shuji Morisaki
リモートチームとふりかえり改善フレームワーク
リモートチームとふりかえり改善フレームワーク
Maehana Tsuyoshi
connpass特徴と開発の流れ
connpass特徴と開発の流れ
Ikeda Yosuke
デキるプログラマだけが知っているコードレビュー7つの秘訣(DevLove版)
デキるプログラマだけが知っているコードレビュー7つの秘訣(DevLove版)
Masahiro Nishimi
今さら聞けない人のためのDevOps超入門
今さら聞けない人のためのDevOps超入門
VirtualTech Japan Inc./Begi.net Inc.
議論を描く技術「ファシリテーショングラフィック」
議論を描く技術「ファシリテーショングラフィック」
nishikawa_makoto7
TDDBC osaka 2012/06/02
TDDBC osaka 2012/06/02
Hiro Yoshioka
Intalio japan special cloud workshop
Intalio japan special cloud workshop
Daisuke Sugai
わんくま同盟 大阪勉強会 #46
わんくま同盟 大阪勉強会 #46
Atsuo Yamasaki
今さら聞けない人のためのDevOps超入門
今さら聞けない人のためのDevOps超入門
VirtualTech Japan Inc./Begi.net Inc.
今さら聞けない人のためのDevOps超入門
今さら聞けない人のためのDevOps超入門
VirtualTech Japan Inc./Begi.net Inc.
Scrum,Test,Metrics #sgt2016
Scrum,Test,Metrics #sgt2016
kyon mm
アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱
Koichi ITO
機能追加を行う際に考慮したい3つのポイント
機能追加を行う際に考慮したい3つのポイント
Miwa Kuramitsu
Hiroshima Ruby Conference発表資料
Hiroshima Ruby Conference発表資料
Kakigi Katuyuki
大規模ソフトウェア開発とテストの経験について
大規模ソフトウェア開発とテストの経験について
Rakuten Group, Inc.
今さら聞けない人のためのDevOps超入門
今さら聞けない人のためのDevOps超入門
VirtualTech Japan Inc./Begi.net Inc.
今なぜサーバーレスなのか
今なぜサーバーレスなのか
真吾 吉田
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
Koichi ITO
Similar to 「速」を落とさないコードレビュー
(20)
プログラマが欲しい仕様書とは
プログラマが欲しい仕様書とは
XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」
XP祭り関西2011 森崎 修司「プラクティスが有効にはたらく前提は明らかになっていますか?」
リモートチームとふりかえり改善フレームワーク
リモートチームとふりかえり改善フレームワーク
connpass特徴と開発の流れ
connpass特徴と開発の流れ
デキるプログラマだけが知っているコードレビュー7つの秘訣(DevLove版)
デキるプログラマだけが知っているコードレビュー7つの秘訣(DevLove版)
今さら聞けない人のためのDevOps超入門
今さら聞けない人のためのDevOps超入門
議論を描く技術「ファシリテーショングラフィック」
議論を描く技術「ファシリテーショングラフィック」
TDDBC osaka 2012/06/02
TDDBC osaka 2012/06/02
Intalio japan special cloud workshop
Intalio japan special cloud workshop
わんくま同盟 大阪勉強会 #46
わんくま同盟 大阪勉強会 #46
今さら聞けない人のためのDevOps超入門
今さら聞けない人のためのDevOps超入門
今さら聞けない人のためのDevOps超入門
今さら聞けない人のためのDevOps超入門
Scrum,Test,Metrics #sgt2016
Scrum,Test,Metrics #sgt2016
アジャイルソフトウェア開発の道具箱
アジャイルソフトウェア開発の道具箱
機能追加を行う際に考慮したい3つのポイント
機能追加を行う際に考慮したい3つのポイント
Hiroshima Ruby Conference発表資料
Hiroshima Ruby Conference発表資料
大規模ソフトウェア開発とテストの経験について
大規模ソフトウェア開発とテストの経験について
今さら聞けない人のためのDevOps超入門
今さら聞けない人のためのDevOps超入門
今なぜサーバーレスなのか
今なぜサーバーレスなのか
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
俺も受託開発〜準委任契約によるふつうのソフトウェア開発〜
More from Takafumi ONAKA
不正のトライアングルとコードベースの治安維持
不正のトライアングルとコードベースの治安維持
Takafumi ONAKA
技術記事を書く&楽しむチームの作り方
技術記事を書く&楽しむチームの作り方
Takafumi ONAKA
グルーミングしながら進めるプロダクト開発
グルーミングしながら進めるプロダクト開発
Takafumi ONAKA
Hatena::Letの式年遷宮
Hatena::Letの式年遷宮
Takafumi ONAKA
pt-query-digest は Perl!!
pt-query-digest は Perl!!
Takafumi ONAKA
アプリケーションを作るときに考える25のこと
アプリケーションを作るときに考える25のこと
Takafumi ONAKA
cpanfileがRubyでパースできることに気づいた俺たちは
cpanfileがRubyでパースできることに気づいた俺たちは
Takafumi ONAKA
Perl使いの国のRubyist
Perl使いの国のRubyist
Takafumi ONAKA
ApplicationTemplateのススメ
ApplicationTemplateのススメ
Takafumi ONAKA
RSpecしぐさ
RSpecしぐさ
Takafumi ONAKA
ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発
Takafumi ONAKA
クローズドソースから始めるオープンソース
クローズドソースから始めるオープンソース
Takafumi ONAKA
短期間で新技術を学ぶ技術
短期間で新技術を学ぶ技術
Takafumi ONAKA
Application Bootstrap
Application Bootstrap
Takafumi ONAKA
ドリコム×ピクシブ 社会人交換留学説明資料
ドリコム×ピクシブ 社会人交換留学説明資料
Takafumi ONAKA
すこやかRails
すこやかRails
Takafumi ONAKA
マジカルsvnとキュアgit
マジカルsvnとキュアgit
Takafumi ONAKA
Github Enterprise じゃなくてもいいじゃん
Github Enterprise じゃなくてもいいじゃん
Takafumi ONAKA
ターミナルで画像確認するヤツ作った
ターミナルで画像確認するヤツ作った
Takafumi ONAKA
Webアプリケーションは難しい
Webアプリケーションは難しい
Takafumi ONAKA
More from Takafumi ONAKA
(20)
不正のトライアングルとコードベースの治安維持
不正のトライアングルとコードベースの治安維持
技術記事を書く&楽しむチームの作り方
技術記事を書く&楽しむチームの作り方
グルーミングしながら進めるプロダクト開発
グルーミングしながら進めるプロダクト開発
Hatena::Letの式年遷宮
Hatena::Letの式年遷宮
pt-query-digest は Perl!!
pt-query-digest は Perl!!
アプリケーションを作るときに考える25のこと
アプリケーションを作るときに考える25のこと
cpanfileがRubyでパースできることに気づいた俺たちは
cpanfileがRubyでパースできることに気づいた俺たちは
Perl使いの国のRubyist
Perl使いの国のRubyist
ApplicationTemplateのススメ
ApplicationTemplateのススメ
RSpecしぐさ
RSpecしぐさ
ふつうのRailsアプリケーション開発
ふつうのRailsアプリケーション開発
クローズドソースから始めるオープンソース
クローズドソースから始めるオープンソース
短期間で新技術を学ぶ技術
短期間で新技術を学ぶ技術
Application Bootstrap
Application Bootstrap
ドリコム×ピクシブ 社会人交換留学説明資料
ドリコム×ピクシブ 社会人交換留学説明資料
すこやかRails
すこやかRails
マジカルsvnとキュアgit
マジカルsvnとキュアgit
Github Enterprise じゃなくてもいいじゃん
Github Enterprise じゃなくてもいいじゃん
ターミナルで画像確認するヤツ作った
ターミナルで画像確認するヤツ作った
Webアプリケーションは難しい
Webアプリケーションは難しい
「速」を落とさないコードレビュー
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
4.
今日の話 ユーザに 価値を 届ける 3 最低限の 品質を 保つ レビュー の基盤を 作る
5.
前提 • 事業会社の話 – 人月単価ではないサービスを提供している •
Pull Request 駆動開発をしている – これができていない場合は 「マジカルsvnとキュアgit」 を見てください 4 http://www.slideshare.net/takafumionaka/20130322-svngit
6.
やってしまったレビュー風景 5
7.
やってしまったレビュー風景 6
8.
100コメントにかかる時間 • Pull Request
が出る • 気づく (5min) • やりたいことを把握する (5min) • コメントする (10min) • レスがある or 修正のコミットがある (120min) • ↑をn往復 (10~20hour) • 何も成果がリリースされないまま1日が終わる 7
9.
何もリリースできない徒労感 かつ ひたすら指摘され続けて疲弊 8
10.
このコードレビューでは 何をやっていたのか 9
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 最低限を満たしていな いと、違和感が酷くて 本来のレビューに入る ことができない
21.
「最低限の水準を保とう」 という話をし過ぎると スピードが低下する 20
22.
でも最低限の水準にはなる 21
23.
最低限を満たすのにレビューは要るのか • コードフォーマット – コードフォーマッタで自動修正 –
スタイルガイドを作って配布 • 眼鏡を外したレビュー – 行数やネスト、循環的複雑度やABC Metric等、機械的に指摘 できる • Rubyらしさとか、他のメソッド名との整合性とか – まだレビューが必要だが、数年後には自動化できそう 22
24.
最低限を満たすのにレビューは要るのか • セキュリティ担保 – まだレビューが必要だが、良いフレームワークを使うことで 足元を撃ち抜かない書き方を強制できる •
パフォーマンス担保 – まだレビューが必要だが、例えば N+1 を自動検出するツール は存在するので上手に使おう 23
25.
最低限の品質を 機械的にチェック することができる 24
26.
機械相手に試行錯誤する環境を 作るとレビューコストが大幅減 25
27.
本来レビューすべきだったもの リリースしたら価値が届 く、本来レビューすべき だったもの 26 • コードが仕様を満たして いるか • 仕様に考慮漏れが無いか •
エンバグは無いか • 良い設計をしているか
28.
本来レビューすべきだったもの もっと短縮できないだろうか? 27
29.
コード差分の理由を書く 28 http://techlife.cookpad.com/entry/2015/03/30/174713
30.
僕がよく使うフォーマット • 目的 • 方針 •
実装 • テスト • 相談 29
31.
僕がよく使うフォーマット • 目的 • 方針 •
実装 • テスト • 相談 30 • この PR をマージすると以下のことが できるようになりまぁす! • 仕様書や Issue があればリンクを貼る
32.
僕がよく使うフォーマット • 目的 • 方針 •
実装 • テスト • 相談 31 • 何を考えてこの PR を作ったのか、み たいなのがあれば • 考えた結果、除外したものがあれば 書いて欲しい • 例) 「GitLab に似たような画面が あったので同じ model 構造にした」 「1 万件程度なので LIKE 検索で十分 実用に耐える速度が出せると判断」
33.
僕がよく使うフォーマット • 目的 • 方針 •
実装 • テスト • 相談 32 • 方針に沿って実装していく中でレ ビュアーに伝えるべきものがあれば 補足 • コードだけだと実装意図を読み解き づらい場合に図や疑似コードで流れ を説明するとか
34.
僕がよく使うフォーマット • 目的 • 方針 •
実装 • テスト • 相談 33 • マージボタンを押してもらうための 安心できる材料 • 例) 「実機で一覧表示を確認した」 「DBA にクエリを見てもらって OK 貰ってます」
35.
僕がよく使うフォーマット • 目的 • 方針 •
実装 • テスト • 相談 34 • 書いてみたものの自信が無いところ とか • diff の中にラインコメントの形で書い ても良い
36.
PRの目的とコード差分が分かるように もっと短縮できないだろうか? 35
37.
レビューの前提条件を提示する • レビュアーに求めているレビュー内容を書いておく – 例)
リリース直前なので、ブロッカーになるような不具合が無 いかどうかのチェックをお願いします • これによって減るレビュー – typo の指摘 – そもそも論 36
38.
不要なレビューが減った もっと短縮できないだろうか? 37
39.
成果物が見える状態でレビューする • Before/After のスクリーンショットを貼る –
変化する対象がより分かりやすくなるので マージしやすくなる • Pull Request 単位で自動デプロイする – 動作確認がサクッと終わるので マージしやすくなる 38
40.
マージまでが速くなった もっと短縮できないだろうか? 39
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
43.
もっと短縮できないだろうか? 42
44.
サービス開発はゴールが分からないのが前提 • 不確実な状況下にある – ユーザが本当に欲しいものって分かってる? •
今見えるゴールが正解である保証も無い • リリース後が 8 割 • サービスのリリースはスタートにすぎない 43 速い馬!
45.
リリースを躊躇しない • Pragmaticであること Dogmaticにならないこと • リリースしてから Be
Professional Day で 綺麗にする 44 https://speakerdeck.com/hirak/mercariday2017-api
46.
ここまでのまとめ 45 レビュー の基盤を 作る ユーザに 価値を 届ける 最低限の 品質を 保つ
47.
最低限の品質を保つ • コーディング規約を用意する • 機械に指摘させることで –
一人で試行錯誤できる状況を作る 46
48.
ユーザに価値を届ける • レビューは「改善する」行為 – 改善は損失を減らすが、何かを作ってはいない •
レビューによってリリースが遅くなるのは本末転倒 • 素早くマージできる状態を作っていこう – レビュアーとの意思疎通に気を払ってPull Requestを出す 47
49.
レビューの基盤を作る 48
50.
レビューの目的はさまざま • 最低限の品質担保 • 不安の解消 •
属人化を防ぐ • レビュイーの教育 • チームビルド • etc… 49
51.
関係性のアンチパターンがある 50 http://www.songmu.jp/riji/entry/2014-01-19-cross2014.html
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
60.
今日の話 ユーザに 価値を 届ける 59 最低限の 品質を 保つ レビュー の基盤を 作る
61.
レビューの基盤を作る • レビュイーとレビュアーの関係性に気を遣う – 「問題
vs. 私たち」 – 「空気を導入しない」 • レビュイーが育っていく道筋を敷く – ルーキーだからレビュアーになれないわけではない 60
62.
ご清聴ありがとうございました 61
Download now