コードレビューは『目標をセンターに入れてスイッチ』ではない

コードレビューはGithubが人気になってから一般的になった文化であるように思う

GithubやGitを使っていなかった時期、自分はsvnでみんなでmasterにpushしまくっていた

それでも一応はうまく行っていたのだが、いつからかコードレビューは必須みたいな風潮になった

しかし今コードレビューそれ自体は少々形骸化しているように思う

そもそもなぜコードレビューが必要なのか？

パッチ（＝PullRequest）を作成した段階でバグや設計面での間違いや複雑さを鳥の目でレビューしてmasterを混乱させないことは、突き詰めるとチーム内のコードに対する理解度を下げないためでもある

複数人で非同期に開発をしているとコードは複雑化・巨大化し、個人のコード全体への理解度が下がってしまう

誰か一人でもコードベース全体を把握している人がいないと、コードレビュー自体も無意味になる

なぜならその変更がなぜ全体に対していいアプローチでないのかの根拠がなくなるからである

同様に使っているライブラリやフレームワークについてもそうで、雰囲気でフレームワークを使っているとコードレビューも根拠なしにやらざるを得なくなる

そういった根拠が希薄になったコードレビューで何が起こるかと言うと、別にレビューしなくてもいいような重箱の隅のつつきあいが始まる

インデントがどうとかセミコロンがどうとかクォーテーションがどうとかスネークケースがどうとか

正直この手の言い合いはきのこたけのこ戦争なので何も産まない

フォーマットが揃ったコードが読みやすく生産性が上がるというのは根拠に乏しい

コードレビューの目的を忘れそうになったら以下のことを思い出すと良い

この変更によってユーザにとってのプロダクトがどう改善されるか？

この変更を入れて自分やチームメンバーのコードベースに対する理解は落ちないか？

パッチ作成者は自身このパッチを理解しているか？またそれに対する実装として自信を持っているか？

逆説的だが、チームの技術レベルが低いと価値のある変更も価値が減じられてしまう

一方で技術レベルが高いだけの変更をどんどん取り入れるとやりたかったことからかけ離れたただ複雑なだけのコードが簡単に生まれるのでそれも避けなくてはならない

コードレビューもエヴァも目標をセンターに入れてスイッチしてると怒られるということでした

余談

現在のGithubのPRツールはよくできていると思うが、ベストではないと思っている

テキストベースのコンテンツの差分を見ながら議論するにはGithubのUIは明らかに足りていない

これをうまく改善できれば天下とれるような気もするのだが、そういう研究はあるのだろうか