コードレビューの本質は、自動化ツールを超えた場所にある

コードレビューにおいて、自動化ツールによるチェックはあくまで入り口に過ぎません。真のレビューとは、コードの意図を汲み取り、設計の妥当性を議論し、チームの知識を共有するプロセスそのものです。自動化できることは機械に任せ、人間はよりクリエイティブでアーキテクチャの本質に関わる議論に時間を使いましょう。

これってコーディングにも当てはまると思うわ

残念だけど、いわゆる「上」のポジションにいる人たちからのフィードバックって、結局こういうのばかりになりがちだよね。

「ここのインデントが間違ってる」

「コメントはピリオドで終わらせるべき」

結局のところ、こういう指摘が一番簡単だから昔から変わらないんだよ。

最近、コードレビューの目的についてよく議論されるようになったよね。AIの登場でその意義が問われるのも納得。少し前に投稿されたリンクを置いておくよ：https://mathstodon.xyz/@mjd/115096720350507897 (https://mathstodon.xyz/@mjd/115096720350507897)

それを受けて、自分でもコードレビューでチェックすべきことのリストをまとめてみた：

• チケットやPRの説明通りに機能しているか？

• 不要なコードはないか？デバッグ用のprint文やプライベートなAPIキーが残っていないか等...

• 明らかな欠陥はないか？メモリリーク、想定外のエッジケース、セキュリティ上の欠陥、古いAPI呼び出し等...

• もっと分かりやすくできないか？抽象化の調整、変数名やメソッド名の改善、関数型プログラミングへの適不適等...

• コードベースやスタイルガイドと整合性が取れているか？

• 明らかなパフォーマンス改善の余地はあるか？リストではなくHashsetを使う、遅延評価の活用等...

• 十分なテストが書かれているか？

LLMはこのリストのほとんどをそこそここなせるけど、一番最初の「機能が要件を満たしているか」に関しては一番弱いと思うな。

全くその通り。コードレビューはエンジニアリングに欠かせないし、システムの理解を共有したり、持続可能なシステムを構築したりするためには不可欠だよね。

最近みんながなんとなく受け入れてしまった「AIボットによるレビュー」というパラダイムには、何か決定的に欠けているものがある気がする。

だからこそ私は Archme.io を作っているんだ。AI時代のPRレビューのためにね。

この記事のパングラムチェック：この文章の94％はAI製だね。

コードレビューって単なるゲートウェイであって、何を求めるかは自由だし、今や人間がやる「レガシーな作業」になりつつあるよね。基本的には、人間がやりがちなミスをチェックするためのものだったけど、今ならAIのミスを突くための場にもできる。コードレビューのスキル（AIスキル）を磨けば、恐ろしく徹底的なチェックも可能だ。記事で言われているような指摘は、もう「レガシー」なゲートウェイを通す必要はないかもしれないね。状況は変わったんだよ。コードの価値は下がっている。これからは検証、製品としての整合性、ガバナンスをより早い段階で、かつ継続的に行う必要があるんだ。

経験上、自動コードレビューなんてこれまで以上に無意味だと思う。

Linterもテストもあるし、AIがコードを書いてくれる時代に、右手がやったことを左手が「よくやったね」って言いにいくようなもんだよ。PRを出す時には、自分のコードが動くって確信してるしね。

今本当に必要なのは、アーキテクチャの視点や、長期的なビジョン、そしてビジネスへの洞察だよ。