【完全】コードレビュー ガイドライン
Googleレビュー術
コードレビューを「受ける」人
こういう心持ちで挑みましょう！
「成果物を評価しているのであって、人格を否定しているわけではない」
図太く生きましょう。
「出来てなくて当たり前」
「本実装前に気づけて良かった」
「伸びしろがたくさんある」
これぐらいの心づもりでOK。
コードレビューを「行う」人
ぜったいにやらないでください。
チームにとっても、あなたにとっても大損害です😡
人格攻撃はするな
「なんでこんなこともできないの？」
「そんなことだから何をしても駄目なんだよ」
「ハゲ！」
みたいなその人を直接攻撃するような発言はNG
なぜ直すべきか説明してください
「ここができてません」おしまい。
ダメ絶対。レビューの意味がありません。
コードレビューを「受ける」側は
既に自身にとってのベストプラクティスを見せてくれているわけで・・・
「そう言われてもわからんものはわからん」
「調べてみたけどわからなかった。落ち込む」
「それっぽい理由を発見したけどこれも間違っていたらどうしよう」
となりがちです。
副作用が強すぎるので直さなければいけない理由は
しっかり伝えてあげたほうが良いと思います。
してほしい箇所を口頭のみで伝えないで
ここを怠ると双方で「言った・言ってない」事故が起きる原因になります。
文字として残しておくと事故防止に繋がります。
コードレビューを「受ける」人の issues に直してほしい部分を書いてあげると◎。
意識して使ってみよう💮
issues のタイトルを「～しよう」に統一する
Bad✖
「 axios を使用していない」
Good〇
「axios を使ってみよう」
ほんのちょっと文章を変えただけで印象がガラッと変わりますね。
なぜ・何を・どう直すか issues へ具体的に書く
期限も設けたい場合は「いつ」も明記してあげましょう。
その際文体を「～でしょう」に統一しておくと自然にポジティブな印象を与えることができ◎です。
1: Not good
「boolean名が不適切」
2: Can be better
「booleanがforUpdatingという名前ではどんな機能なのか判断しづらい。isUpdatingなどに変えること。」
3: Good
「booleanがforUpdatingという名前ではどんな機能なのか判断しづらいため、isUpdatingなどに変えると良いでしょう。」
2でより具体的に。3でよりポジティブに。
2⇔3で言っていることは同じですが、
3の文体の方がぐっと柔らかく明るい印象になります。
「良かったところ」もissues に書く（おまけ）
開発はやはりみんなで楽しくやりたいですよね🐾
その人が今できているところをしっかり拾って褒めると以下の効果が期待できます。
できていた部分が印象に残って次も意識しやすくなる（※人にもよると思います）
現時点で出来ている部分と改善すべき部分がより明確になる
ついでにその場の空気もよくなる
Discussion