逆に自分のPRを無視してくれるのも全然OK。PRはオプションであるべきだと思う。すべての変更がピアレビューを必要とするわけじゃないし、同僚を信頼するなら、パフォーマンス的なPRに時間を無駄にせずに、自分のブランチをマージできるようにすべきだよ。

それはコードの外で伝えるべきだよね。理想的にはそうだね。ゼロ金利政策の下で10年近く過ごした後、多くの労働者は、自分の意図を文脈の中で意識し続けるインセンティブがなかったように思える。私が一緒に働いた人の半分は、前の文の苦々しさではなく、その長さに気分を害するだろう。実際に機能することと、期待されることの間にはインピーダンスミスマッチがある。これは、文脈や意図を明確にするよりも、むしろ痛々しいシンタックスエラーを引き起こすことが多い。そうなると、コードベースはすべての貢献者の文脈と意図の標準的な表現となり、彼らが最善を尽くしていないときでも、正直なところ、それが悪いことなのか？もしかしたら、コードの中で伝える方が劣った体験になるかもしれない。でも、コードの外でのコミュニケーションが確立できないとき、他に何ができる？こういうコミュニケーションをコードを通じて促進するツールがあれば嬉しいな。例えばGitHubは、そういうことをするのに完璧な位置にいるのに、やってないよね。Git + PR + プロジェクトは、情報の流れが逆になっていて、最近ではその失敗モードについて全体のカンファレンスで話されることもある。

これ、めっちゃ気になるんだよね。仕事では、結構多くの貢献があるコードベースの専門家なんだけど、同僚から「承認して！」みたいなプライベートIMがたくさん来る。100行以上のコードが送られてきて、その中で私に関係あるのは10行くらい（私が専門としているファイルや挙動だから、承認が必要なんだ）。最低限、変更の背景や、なぜこの部分のコードベースに変更が必要だったのか、その考え方を知りたい。たまに、でもあまり頻繁ではないけど、レビューを返してこの情報を求めることもある。私の意見では、多くのソフトウェア開発者は、書くのが速くないから、自分の変更に対する説明を提供するのが大変なんだと思う。あるいは、AIやIDEに従って作業しているだけで、説明を提供できるほどの理解がないこともある。人々が時間をかけないのが、レビューを形式的にしてしまう原因だと思う。

何行かの変更があるPRについて、開発者が自己レビューをしていなかったら、私は全くレビューしない。代わりに、自己レビューをして、文脈を追加してから再レビューをリクエストするようにお願いしてる。さらに、「これらの洞察の中で、コードに直接コメントとして追加する価値があるものはある？」って質問することが多い。9割の確率で、彼らが書いた文脈はコード内の良いコメントになるはず。人々は時々、意図せずにすごく怠けることがある。私たちは、モンキーブレインがより良く機能するためのリントツールが必要だ。gitプラットフォームがこの種のコンプライアンスを強制するためのUXフレンドリーな方法をもっと提供してくれたらいいのに。CI/CDでそれをある程度偽装できるけど、私の意見ではそれだけじゃ不十分だね。

そうそう、コードや変更について考えてもらいたいなら、必要なコンテキストを提供できるようにしないとね。もしそれが分からないなら、自分のコードがみんなが待ってたギフトだと思わないでほしい。自分はそう思ってるかもしれないけど、他の人には何をしたのか分からないから、誰かがその作業をしてくれるまで待つことになる。要するに、追加したコードは作業を生むってこと。だから、せめてその作業を減らすために、自分のコードが何で何じゃないのかを分かりやすくする努力をしよう。どんな変更をしたのか（機能的に）、なぜそれをしたのか、どんな選択をしたのか（あれば）とその理由、PRのコードの状態について自分の意見をまとめてみて。必要な理由や、将来のメンテナンスがどうなるか（理想は低い）についても考えてみて。要するに、誰かがドアをノックして、自分のプロジェクト用のパッチが入ったUSBを渡してきたときに、何を知りたいか自問自答して、その知識を加えてみて。大きな機能については早めにドラフトPRを作成することも考えてみて。そうすれば、誰も望んでいないものをプログラミングしたり、他の誰かがすでに作業していることを避けられるし、メンテナが方向性を示したり、作業を始める前に断ることができる。

よく機能している環境では、逆の相関関係があることが多いよ。物議を醸す変更やバグ修正は小さくてターゲットが明確で、意図しない副作用について深くレビューされる一方で、大きな変更セットは、事前に話し合われた新しい作業で、確立されたパターンに従ってスルーされることが多い。

90%の開発者にこのレベルの履歴手術をやらせるのは難しいよ（ハハ）。実際にできる人（典型的なエンジニアの中のごく一部）でも、正しくやるための忍耐を持っているのはさらに少ないと思う。開発者にこういうことをやらせようとすると、理解できないから目が glazed over したり、余計な作業にイライラしたり、頷いても無関心になるだけ。トップエンジニアの一人がやっても、他の組織がちゃんとしたコミットの衛生を守らないことにフラストレーションを感じるだろうね。自動化で簡単に強制できるものではないから、基本的には達成不可能だと思う。Netflixみたいにトップパフォーマーだけを雇っているなら別だけど、あなたはNetflixじゃないから。

業界の一部では、CRの数やCRごとの修正回数をパフォーマンス指標として追跡してるんだよね。多くの人がこれを利用して、自分の「数字」を良く見せようとする。つまり、CRの数を増やして、CRごとの修正回数を減らすってこと。

コードレビューの議論でよく混乱を招くもう一つの要因は、オープンソースプロジェクトと内部コードベースが一般的にかなり異なる状況にあることだと思う。内部コードベースは、比較的小さな経験豊富なグループによって作業されることが多く、彼らはPRを作成し、レビューも行っている。だから、 - 「この人が何をしているか知っていると仮定してもいいのか？」というベースラインが高い - レビューを早くするために「PRを作成する」プロセスに時間がかかるのは、チーム内の時間のトレードオフに過ぎない - コミットされたコードに問題があれば、そのコードを書いた人がそれを修正するために周りにいる でも、オープンソースプロジェクトでは、「コア」の長期的な開発チームの外からの貢献が多いから、 - 貢献者がコードベースに精通していると仮定できないので、余分な注意が必要 - 変更を提出する人よりもコードレビューを行う人が少ないことが多いので、提出者がレビューアの仕事を楽にするために余分な努力をするプロセスが理にかなっている - コードに問題があれば、提出者がアップストリームに行った後に修正するために利用可能または興味がある保証はないので、微妙な問題を事前にキャッチすることがより重要で、これによりコードレビューのプロセスは「レビューアを楽にするために、たとえそれが提出者にとって余分な作業を必要とする場合でも」という方向に傾くことが多い。