by and for engineers

コードレビューの心構え

コードレビューする人・される人のためのドキュメント

cf. thoughtbot/guides #Code Review

みんなの心構え

  • プログラミングに関する議論を “意見” として受け入れよう！
    • 何を犠牲にして何を得るのか？ 得るものをハッキリさせよう！
    • 自分の好きな書き方は？ 僕は :flags: が好き
    • 議論によって、問題解決までショートカットしよう！
  • とにかく質問しよう！ 変更を要求しないこと
    • :o: 「 :user_id という命名はどう思う？」
  • シンプルになっているか確認しよう
    • :o: 「ちょっと、ココが読めなかった。」「コードの内容を説明してもらえる？」「もっとシンプルにする方法は無いかな？」
  • コードを書いた人を言及する言い回しは避けよう
    • :x: 「僕が書いたコード」「それは私が書いてないコード」
  • 暗に誰かの性格を否定する言葉を避けよう
    • 誰もがクリーンなコードを書きたいと思っている “善意” の結果だ
    • :x: 「クソコード」
  • 相手への配慮しよう！
    • 周りはあなたが思っているほど、あなたの意図を汲み取ってはくれない
  • 謙虚であれ
  • “誇張” や “断定” するのはやめよう
    • :x: 「絶対に」「ありえない」
  • “皮肉” を言わないこと
  • 絵文字や LGTM は強制されるものではない。自分が本当にそう感じた時だけ使おう
  • もし、あまりにもコメントが多い場合は、口頭で話そう
    • ただし、口頭で決めたことは、サマリーをコメントにして共有しよう

コードレビューしてもらう人の心構え

  • コメントくれた人に感謝しよう :bow:
    • 「いいね！そうしよう、コードを修正するよ。」
  • レビューは “あたな” ではなく、 “コード” に対してコメントしている
    • 自分を否定されたと思わないこと
  • コードが必要な理由を説明しよう
    • その変更によって、コードはより明確になっているだろうか？
  • 課題に対して、いくつかの改善やリファクタリングを抽出しよう
  • コードと課題を紐付けよう！
    • GitHub なら #1 が使える
  • ブランチを切り出して、コミットはまとめよう
    • マージの準備ができるまでコミットをまとめないこと
    • レビューする人が初期からの変更履歴を追えるようにすべきだ
  • レビューする人の気持ちを理解しよう
  • すべてのコメントに何か返信しよう！
  • マージする時は、CI が緑になるまで待とう
  • コードに責任が持てるならマージしよう

コードレビューする人の心構え

レビュー前に、そのコードが必要であるかどうか理解しよう。単なるバグ修正？ ユーザ価値を向上するか？ それともリファクタリングか？

  • 良いと思ったアイデアを話し合い、感想をコメントしよう
  • 問題を解決しながら、よりシンプルなコードになる方法を探そう
  • 議論が哲学的、学術的になりすぎたら、TGIF で話そう。代替案を提示して最終決定しよう。
  • 代替案を提案しよう。でも、もしかしたらすでにコードを書いた人は検討済みかもしれない。
    • :o: 「ここで、カスタムバリデーターを使うのはどうでしょうか？」
  • コードを書いた人の意図を頑張って汲み取ろう
  • コードを見たら、「 :+1: 」するか、 “Ready to merge” と署名しよう！

みんなで清く正しくコードレビューしよう！