コードレビューの心がけ

個人的な方針ですが、チームに共有するための資料を作りました。

今よりも少し良いコードを求める

完璧なコードは存在しません。コードを書いた人、レビューする人の価値観によって完璧は違います。もし全ての人の価値観が同じだったとしても、何が完璧かを追求するのは困難です。なぜなら、どのようなコードにも、パフォーマンス、拡張性、可読性などのトレードオフがあります。納期、組織の構成、メンバーの熟練度といった様々な要因に左右されます。仮に現時点の完璧が見つかったとしても、将来は陳腐化しているかもしれません。

コードの良し悪しを議論するときは、最善が何かということを固執せず「今あるコードが、改善するかどうか」を考えましょう。60点のコードを70点にする方法を議論しましょう。私たちには100点を探し求める時間はありません。

コードと人を分けよう

あなたが書いたコードは、あなた自身ではありません。プログラムを書くことは創造的な活動です。生み出したコードを、我が子のように大切に思っている人もいるでしょう。それでも、過保護にならないでください。自分の書いたコードが批判を受けた時、一呼吸置いてから、より良い選択肢はどれなのか考えてください。自分の書いたコードが意図しない修正を受けた時、台無しにされたと嘆く前に、より良い設計について考えてください。

人の書いたコードを議論するときは、書いた人と切り離して考えるようにしてください。書いた人が誰であっても、同じようにコードは批判し、改修しましょう。誰かの思いや好みを汲み取ろうとする必要はありませんが、リスペクトを持つようにしてください。感情的に断定したり、根拠のない批判をしないでください。

事実と技術的用語を使おう

良いコードとは何かというメンタルモデルを持つようにしましょう。 たとえば、同じことを実現できるなら、わかりやすいコードは良いコードです。 「わかりやすい」というのは主観的な言葉ですが、事実や技術的用語を用いて、より客観的に説明することもできます。

  • (感想) このメソッドは A と比べて B の方がわかりやすい
  • (事実) このメソッドは A と比べて B の方が一時変数を省略でき、行数が少ない
  • (用語) このクラスは設計 A と比べて B の方が単一責任の原則を満たしている

必ずしも技術的用語を暗記して使う必要はありません。 しかし、適切な用語はコニュニケーションを簡潔にします。

  • (用語がない) メソッド A が2回以上呼び出されています。初めて呼び出された時にインスタンス変数に入れておき、2回目以移行は計算を省略するのはどうですか？
  • (用語がある) メソッド A をメモ化してみるのはどうですか？

参考