「Looks Good To Me 〜みんなのコードレビュー」を読んでみました。まず、お伝えしたいのが、ただのコードレビューに特化した書籍ではなく、PRを作成する側の視点やコードレビューにいたるまでのサイクルにまで言及されていました。具体的にはCIを用いたLinter導入やTWA（Team Working Agreement）の設定など、良いコードを生み出す様々な仕組み作りの方法が述べられていました。
本記事では個人的に学びがあり、取り入れたいなと感じた視点をピックアップしております。仕組み作りなど細かな実践的な方法が知りたい方は本書を手にとってみてください。
PR
タイトル
（本書p.29あたり）
タイトルはコード変更の「エレベーターピッチ」と述べられており、これまでIssueのタイトルをそのまま使うこと、少し変えることが多かったのでタイトルにもこだわりたいなと思った。
そして、「極めて優れたタイトルは要点を押さえており、PRの残りの部分で説明が不要」とも述べられており、現実的に説明をなくすのは難しいかもしれないが、それくらいタイトルが重要なんだと認識させてくれた。
Check List
- PRの「何」を明確かつ簡潔に説明すること
- タイトルを80文字以内の収める
- 分類プレフィックスを使う
- fix:, feat:, doc:, chore:, breaking:
PRレビュー
レビュー担当
（本書p.52あたり）
テキストで物事を伝えるときに100%相手に思っていることが伝わらないことがあると思う。これはテキストに限らず、リアルでも起きることだが、テキストだとレスポンスがいつになるかわからないのでなるべく、誤解・誤認を生まない文言にしておく必要がある。
Check List
- 「質問が自明か？」
- 「FBで誤解を生まないか？」
セルフレビュー
「PRオープン前に席を立ち、休憩を取り自分がはじめのレビュー者になる。」ということが述べられていた。確かに、実装後連続してPRを作成していると、客観的な視点を持つことが難しいと感じていた。早くPRを作成すれば良いというものでもないので、散歩するなどリラックスした状態でコードを見直すのは大事だと思った。
Check List
- コードとPRで提供した情報に基づいて、変更をわかりやすく説明できるか？
- PRを読んでいる際に疑問が出てきたか？
- 自身の知識で補完している箇所がないか？
- エッジケースを考慮したか？
チームのコードレビュープロセス構築
知識移転・共有
（本書p.79あたり）
Check List
- バケーション係数を下げる（一部のメンバーへの依存度）
- 自分が知っている知識でメンバーが知らない知識をドキュメントにする
コードレビューの目標の選定
（本書p.84あたり）
Check List
- バグの発見
- コードベースの安全性とメンテナンス性
- 知識移転・共有
- メンタリング
- 記録の保持・作成
コードレビュー
レビューコメント
（本書p.181あたり）
Check List
- 提案するときは根拠を合わせてすることで、受け手の誤認を減らし、対応しやすくなる
- 変更を提案する前に立ち止まって孰考する
- コメントへの返事なども同様に、一度立ち止まって孰考する
- コードベースのメンテナンスのしやすさを目指して、レビューコメントを書く
- この目標に貢献しないのであれば書く必要のないコメントかもしれない
- ポジティブフィードバックも有効
まとめ
- PRを作成するときの視点とレビューするときの視点それぞれで取り入れたいものがあった
- CIを用いたフローやチームのレビューフローなどは、現在の環境でも良い感じに自動化されていたり整備されていることがわかった（先人に感謝）
- シニアエンジニアのレビューの質が高いことも実感できた（これも感謝）その上でコードベースにとってプラスになることは、つっこんだり、話を膨らませるのが良いと思った
各々の環境や経験によって、本書から得られる知見が違うと思います。ぜひ手にとってみてはいかがでしょうか??