- 意味のある単位でPRを出す
- 意味のない(動かない, 今後使う, 念の為に)PRは出さない
- 自分で説明することができないコードは書かない
- 複雑になる場合は設計のレビューを先に出す
- PRの作業中はタイトルに[WIP]をつけ、ついてないものは積極的にレビューする
- [WIP]のものはレビューしない
- レビューを依頼する前にセルフレビューをする
- 自ら気がつくことができる問題はあらかじめ取り除いておく
- インラインコメントはコードから読み取れないことのみを書く
- 例) xxx1.5のライブラリではyyyの不具合があるため、問題を回避するためにzzzするようにしている
- PRで議論になった場合後にも議論になる可能性があるので議論のURLを張っておく
- ボーイスカウト精神を持つ
- コードのバグやドキュメントの不備に気づいた場合は治す
- 他の人のコードもテストがあれば変更は怖くない
- レビューは品質の担保と情報共有を行う
- 品質とは保守や性能である
- レビューが通ってないコードはマージしない
- レビューはデバッグ作業ではない
- レビューは丁寧にWhat/Why/Howを心がける
- レビュワーもレビュイーも
- 良い点はなるべく褒める
- レビュイーのモチベーションを高める
- テストは必ず行う
- 自動テストがPR単位のCI実行があると良い
- 自動テスト(unit/e2e等)がない場合は手動テストを行う
- 手動テストをした場合はその工程や結果を共有する
- コーディング規約などはlintやformatterなどで自動化する
- 自分でない誰かがメンテすることを意識する
- Issueやwikiなどのドキュメントを残す
- コードやIssueは後追いできるように丁寧に書く
- 個人の責任ではなくチームの責任である
- 個人を責めない
- 再発防止策を考える
- エンジニア全員が全コードに対して責任を持つ
- クライアント/サーバエンジニア関係なく双方のロジックを理解する
- インフラの仕組みも極力理解する
Last active
December 21, 2020 02:16
-
-
Save oppai/6f2c7cb0e504de8fde66a7169366090c to your computer and use it in GitHub Desktop.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment