Skip to content

Instantly share code, notes, and snippets.

@oppai

oppai/PRREVIEW.md

Last active December 21, 2020 02:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save oppai/6f2c7cb0e504de8fde66a7169366090c to your computer and use it in GitHub Desktop.
Save oppai/6f2c7cb0e504de8fde66a7169366090c to your computer and use it in GitHub Desktop.
Download ZIP
Raw
PRREVIEW.md

PRレビューガイドライン

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