レビュアのためのガイド
コードレビューで何を期待するべきか
システムに対して適切な設計かどうか
? コードを変更するか・ライブラリを変更するか? その機能を追加するのは今が最適なタイミングなのか期待している機能（振る舞い）をするか、コードのユーザー（同じチームの他の開発者）にとって良いものか
簡潔な記述か
正確な名前をつけているか
注釈（コメント）は明確か
「なぜこのコードが必要か（Why）」というものだけでいい
反対に、このコードでは何をするか（What）を書く必要がある場合は、そのコードが簡潔ではない
テストがあるか
振る舞いを評価する定量的な・システム化された品質管理
コードレビューのスピード
>コードレビューはどのくらい速く行うべきか？
> 集中状態にあるタスクがない場合には、レビュー対象のコードが来たすぐ後にコードレビューを行なわなければなりません。
> コードレビューリクエストに対して、返事をするまでに掛けることが許される最大の時間は、1営業日です。 (つまり、最低でも翌日最初にするべきです。)
レビューのリクエストが来た際に自分のタスクを進めている場合は例外
基本的にオフィスを離れる前に自分が持っているレビューがない状態が理想
コメント付きLGTMという概念で、「〇〇だけ修正すればマージしてもらって問題ない」と指示することがある
1. （指摘した）〇〇の部分を開発者自身で適切に対処できるであろう場合
2. 指摘した点が「Nitタグ」が付いているなどで、些細な点でのレビューな場合
コードレビューのコメントの書き方
>問題を指摘して明確な方向性を示すことと、開発者自身に決定させることのバランスを取りましょう。
一般に、CL を修正するのは開発者の責任であり、レビュアの責任ではありません
開発者の方がコードに親しんでいるので、優れた解決方法を生み出せる可能性が高いのは開発者である
専門家はマネジメントできないに通じる部分がある
コードレビューでの反対の扱い方
基本的には、コードレビュー 開発者ガイド | eng-practices#613088ed09c5f20000459c8aなので開発者の方が専門領域について知見があるという前提
しかし、レビュアは開発者が手を加えている範囲よりも、より大きな機能開発の範囲を俯瞰している場合が多いので、「なぜこの提案を行なったのか」を説明しなければならない
コードレビューの基準
「完璧」なコードというものはどこにも存在せず、あるのはよりよいコードだけだということです
レビュアーが求めるべきなのは、完璧さではなく継続的な改善
>レビュアには常に、もっと改善できるはずだと思う点についてコメントする自由がなければなりません。しかしそれほど重要な点ではないのなら、コメントの最初に “Nit: “ (訳注: 些細な点という意味、ニッチの単数形) のようなキーワードを付けて、作者に改善可能な点だが改善するか否かは作者に委ねる、ということを知らせてあげましょう。
フィードバックとレビューと同じかもしれない