今日の学び #9 2024-05-28

ルールズ・オブ・プログラミング

ルール6

バグが発見されるケース（頻度の多い順）

• レビュー前に自分のコードを見直して見つけるバグ

• レビュアーに説明する中で自分で気付くバグ

• レビュイーが見落としたバグ

つまりレビュアーが発見するバグは稀
むしろ、バグの発見はコードレビューを行う理由の1つに過ぎない
➔トリッキーな実装をしようとしていた場合、「今後このコードを触るかもしれない誰かがもしかすると苦労するかもしれない」よりも、「あのレビュアーなら難色を示すかもしれない」という明確な誰かの意見をイメージして判断材料にできる
プロダクトコードに詳しい人をシニア、詳しくない人をジュニアとした場合、1対1のレビューでは、4通りの組み合わせになる。

コードレビューの目的は、知識の共有

ジュニアがレビュアーとなりシニアがレビュイーとなる場合でも、バグの発見は減るが、レビュー中の質問を通して、ジュニアはコード理解が早くなる。
かつ、その例を通して正しい書き方、またチーム内の規則を学ぶことができる。
➔これは、ジュニアが実際にコードを書くよりも効率的にコード理解が進むと思う。
一番バグが発見できるのはシニア対シニアのコードレビュー

禁断のコードレビュー

ジュニア同士の組み合わせは、上記のメリットが全て無く、中途半端な意見が行き交い、何となく納得するとそれがチームの方針のように思えてしまう。
その結果、変なパラダイムが負債として残る

コードレビューの真価

健全な同調圧力として「仲間に喜んで見せたり誇れたりする仕事をしなきゃいけない」という意識が働く

コードレビューとは内在的に、社会的交流を含むもの

コードレビューが全部論争になってしまうなら、やり方を間違えている！

プロジェクトの方向性やチームの規則や哲学について議論する場じゃない。そういう問題はチームで解決するべきだ。

健全なコードレビューってものは、コードレースを強化すると同時に、チームの絆も深める。