伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書

https://gyazo.com/1ab3a00308fb4bf18ab9f46807ef5580

わかるわかると頷きまくってしまった。tipsが並んでいるので、実際のレビューの際にピッと書籍を参照して話に出しやすいのも嬉しいポイント。

----

【Part1　心構え編】

・「伝わるコードレビュー」とは

-この本は何のための・どのような本か

-コードレビューの利点と難しさ

-コードレビューはコミュニケーション

・伝わるコードレビューの5大ルール

-コードレビューで守るべきルール

-ルール（1）：決めつけない

-ルール（2）：客観的な根拠に基づく

-ルール（3）：お互いの前提知識を揃える

-ルール（4）：チームで仕組みを作る

-ルール（5）：率直さを心がける

-コードレビューは双方向のコミュニケーション

【Part2　実践編】

Case1：緊張感のあるレビューコメント

Case2：説明不足のPR

Case3：進捗が遅れているPR

Case4：考え方・価値観の食い違い

Case5：細かすぎるレビューコメント

Case6：Lintツールの言いなりの修正

Case7：「あの人が言っているから大丈夫」という思考停止

Case8：質問コメントに答えない修正PR

Case9：レビューポイントがわかりにくいPR

Case10：気を遣いすぎたレビューコメント

Case11：レビューされないPR

Case12：前提が揃っていないPR

Case13：コメントへの訂正情報の不足

Case14：放置された議論

Case15：見過ごされた質問コメント

Case16：想像に基づく修正

Case17：調べる前に相手に投げてしまう質問

Case18：関係者へ確認ができていないPR

Case19：感情的なコメント

【Part3　TIPS編】

1：クイズを出さない

2：命令しない

3：性善説で考える

4：相手の意図を断定しない

5：まずは共感を示す

6：チームで共有するタグを作る

7：Lintツールを入れる

8：作業ログをつけて参照場所をリンクする

9：相談までの時間を決める

10：詰まっていることを伝える

11：わからないレベルを伝える

12：遠回しに言わない

13：自分の考え・意見を添える

14：根拠がないなら根拠がないことを添える

15：詳細を明示する

16：何をして欲しいかを伝える

17：「念のため」の確認をする

18：同期コミュニケーションに移行する

19：質問先を明示する

20：上手に催促する

21：期限を明示する

22：すぐに返せないことを伝える

23：聞きたいことを絞る

24：相手の知識に合わせる

25：はい・いいえで答えてもらう

26：論破ではなく納得を目指す

27：Before／Afterの画像を載せる

28：「やっていないこと」を書く

29：テンプレートを用意する

30：ラベルをつける

31：箇条書きを使う

32：レビュアーを指名するロジックを作る

33：相手の理解の段階を踏む