チームメンバーとのコミュニケーションを密にとっているか
他のチームメンバーと同じ開発をしていた、やっていると思っていたらやっていなかったなどとならないように密にコミュニケーションを取る必要がある。
コンウェイの法則（コンウェイの法則とは、ソフトウェアシステムのアーキテクチャは開発チームの組織とよく似る）という法則から考えてもコミュニケーションは重要
チームメンバーの心理的安全性は確保されているか
Gogoleが2012年に採用したことが脚光を浴びた概念。これは成功に導くチームを構築する上で重要で、意見や提案をする上で、冷笑されたり、煙たがられたり、聞く耳を持たれない状態ではうまくいかないということ。
より早く実装完了することに気を取られていないか
クラス設計と実装のフィードバックサイクルを回しているか
仕様変更の際には最低でもメモ書き程度のクラス図を書くこと。責務や凝集性などの観点から問題ないかをチームでレビューし、なさそうであれば実装に取り掛かる。取り掛かってから見落としに気づくことも多々あるので、それをクラス図にフィードバックすること。
厳密に設計しすぎていないか
厳密に設計しても見落としはあるもの。そのせいで設計をしても無意味だと判断するのではなく、こういうものだと割り切ってサイクルを回し続けることが大切。
設計ルールは設計スキルの高いメンバが中心となって作っているか
改善できる点に気がついた箇所を改善する意識を持っているか
既存コードを信用しすぎていないか
既存コードを一切信用しないくらいの心構えでコードを書くこと。
アンカリング効果に振り回されないように注意。
ジョシュアツリーの法則にも注意。
# コーディング規約を利用しているか
色々あるみたいですね。
https://techracho.bpsinc.jp/hachi8833/2017_05_15/38869
https://github.com/cookpad/styleguide/blob/master/ruby.ja.md
https://qiita.com/tomoharutt/items/51254ae5dafba645dc6d
命名規約を利用しているか
https://qiita.com/TakeshiFukushima/items/647a652439b55525945f
https://techracho.bpsinc.jp/hachi8833/2017_02_13/35364
設計的な妥当性に重点を置いてレビューしているか
敬意と礼儀を持ってレビューしているか
レビューで理由を説明しているか
レビューで不明瞭な点について理由を聞いているか
レビューで徹底を追い求めて終わりを見つけているか
24時間以内にレビューしているか
ポジティブな点を見つけようとしてレビューしているか
# 人を蔑めるようなレビューをしていないか