コードレビューって難しいですよね。機能と無関係な指摘をどこまで対応するか、私も悩んだ経験があります。

以前のプロジェクトで、機能実装のレビューをもらったときに、命名規則とかコメントの書き方とか、動作には全然関係ない指摘が結構多くて。当時は「えっ、これまで対応する必要あるの？」って思ってました。でも後になって気づいたのが、その「無関係」な指摘たちが、実は後々のバグ修正や機能追加のときに、チーム全体の効率に影響してるということ。可読性が高いと、誰かが半年後にそのコード見たときに理解するのが早いんですよ。

今は、自分でレビュー指摘をするときに「これ、なぜ大事なのか」を意識するようにしてます。指摘する側が理由を説明できないなら、それって本当に必要な指摘なのかな、って。逆に言うと、理由を説明できる指摘なら、対応する方も納得できると思うんです。

結局、「機能に直結しない＝対応しなくていい」というより「チーム全体の可読性や保守性にどう効く指摘か」で判断するのがいいのかな、という気がしてます。でも、その判断基準は現場によってかなり違いそうですね。