レビューを依頼する前に、以下を確認する

レビュー前

  • binding.pryは削除したか
  • メモ的なコメントが残ってしまっていないか
  • commitしてはいけないものをcommitしてないか
  • wipなどレビュアーがレビューしにくいコミットが入っていたりしないか?git rebase -i でまとめる
  • マージ先のブランチはそこで良いのか
  • 重複部分がないか?また、重複を修正しない場合は理由を。
  • git pull –rebase origin develop してローカルのdevelopを最新にしてからgit rebase develop して最新のコードを持ってきているか
  • テストは全てパスしているか
  • コミットに機能を詰め込みすぎていないか?コミットが多すぎても、1つにまとめてファイル数が多くなりすぎるのも良くないので、大きな機能を実装した時にはレビュアーが見やすいようになっているか?
  • returnや返り値の無駄な設定をしていないか?
  • その処理で&.は必要?必要ではない?
  • N + 1問題が発生している部分はないか?

レビュー後

  • マージするプルリクエストを間違っていないか
  • approvedされているか
  • 本番で正しく動作確認出来たか

名前の付け方

  • 明確な単語を使う
  • 名前は抽象的な名前を使わない
  • 頭文字や省略形を使う際には新しく入る人が理解出来るかを考える
  • 範囲や限界値などはfirst~last max~min などを使用し、プール値の場合はishas などを使い否定系は使わないようにする。

美しさ

  • 似ている考えをまとめて、他の考えと分ける

コメント

  • 定数の値にまつわる背景をコメントする

制御フロー

  • 条件式は左側に調査対象を、右側に比較対象とする
  • 否定系よりも肯定系を使う

変数と読みやすさ

  • 変数の定義は変数を使う直前で定義する。
  • コードが複数のタスクを行っている場合は、タスクを個別に解決出来るか検討する
0