コードレビューで理由を書いているのに受け入れてもらえない

自分はコードレビューにおいて理由を書くようにしている。

「GoにおいてConstructorはMakeUser()よりもNewUser()の方が良いと思います」

これは良いと思う理由が書いていないのでNG。

「GoにおいてConstructorはMakeUser()よりもNewUser()を使用することが多いようです。(https://go.dev/doc/effective_go#composite_literals)」

であればGoらしいコードはNewUser()なんだなというのが伝わる。

このようにコードレビューでは指摘する内容には指摘するだけの理由が必要だと考えている。

(理由が説明できない指摘は好みの可能性があるので指摘しないようにしている。)

(自分でもどちらがよいか迷っているのですが、、、というコメントをすることもある。)

明確に理由を説明している場合、それに対する納得の行く反論があれば、指摘を取り込まないことはレビュイーの自由であると思う。

しかし、納得できる反論なしに取り込まないケースがあったので記しておく。

今までの自分の経験上、受け入れてもらえないパターンには2種類ある

コードレビューを品質向上・学習の場ではなくてマウンティングの場と捉えている
- 格下だと認定した人からの指摘は何であっても受け入れられない人
プロダクトに求められる内容よりも自分の好奇心を優先してしまう
- 思い付いたから実装したい
- 実装してしまったから取り込んで欲しい
  - サンクコストバイアス

仕事における目的を見誤っているのでそういうJerkな人*1に対して時間を割くことが無駄である。

Jerkな人のせいで仕事が円滑に進んでいないという証拠集めのためにSlackやGitHubに証拠が残る形でコミュニケーションを取り、上司や責任者に報告してJerkな人を排除しよう。

排除できない場合は自分がチームもしくは会社を去る法が良い。

職場の同僚と良好な人間関係を築き学びのサイクルを加速させることができないのであれば、よっぽど高待遇でない限りチームに残り続けることはおすすめできない。

チーム異動や転職などで一時的に苦労する可能性はあるが、中長期でキャリアを俯瞰してみたら早く離れる方が得なはずだ。

フリーランスの場合は契約更新時にJerk対応割増をしてもよいかもしれない。

好奇心を優先してしまう現状に対して本人もコントロールできない自覚はあるはずなので、認識を揃えるための時間を取り、丁寧にコミュニケーションしていくと上手く行く事が多い。

プロダクトの目的と中長期で目指す方向性の認識を揃えることができれば、好奇心よりもプロダクトの成長を優先して実装をしてくれるようになり、そのための指摘であればレビューを取り込んでくれるはずだ。

好奇心優先で実装してしまう人は難易度の高いタスクを一気に作り切る「突破力」が高い傾向にあるので、向き先を正すためのサポート的な役割になるとチームとして機能する。

自分がフォワードとしてGoalを決める以外にも試合に勝利する方法はあるのだ。

ただ、自身の成果がわかりやすく見えないようになるので、上司に対しては別途考えを述べる機会は作るようにしたい。

スケジュールはレビューを受け入れない理由として適切なものだと思っている。

コードの品質よりもスケジュールを優先するチームやプロダクトのフェーズというのは存在するのでそれは理由になりうるし、スキル不足でスケジュールが遅れがちというのも立派な理由である。

このとき「改善の余地があることが見えているコードはメソッドに切り出してすぐに消せるようにする」くらいはやって欲しいなーと思ったりはする。

リリース前であれば30分で直せるものが一度リリースしてしまうとリファクタリングに1日かかったりする。

基本的にはシフトレフトの原則に則って気づいたタイミングで直すようにしたいし、それが優先されるチームであって欲しいと思う。

*1:あえてJerkな人という言葉を使う。Brilliant JerkってBrilliantだと本人が思っているだけでBrilliantだったことがないので。