コードレビューには読むことが必要だ
(hauleth.dev)- コードレビューはデプロイ前の形式的な手続きではなく、障害・セキュリティ問題・データ削除の責任を一個人からチームの責任へ移すプロセスである
- より良い eval、テスト、機能フラグ、ガードレール、可観測性は、読まれていないコードのデプロイへの不安を減らすための答えになり得るが、レビューの責任分散という目的を見落としたアプローチだという批判である
- 読まずに承認しろという要求は、人に何も考えずボタンを押させるのと同じであり、CI がすべて green のランダムな PR をマージするbutton rouletteという風刺につながる
- コードレビューは大きなコードベースのさまざまな部分をチームメンバーに見せることでbus factorを下げ、新しいメンバーがコードとコード文化を学ぶための学習装置として機能する
- 読まれていないコードをデプロイすることを強いるなら、バグ・セキュリティ問題・ダウンタイムなどに関する書面での責任免除が必要であり、そのような免除を得るのは難しいという結論である
レビューの目的は承認より責任分散
- Charity Majors の記事 “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy” にある「読んでいないコードを本番環境にデプロイしても安心できるようにするには何が必要か」という問いが出発点である
- より良い evals、テスト、機能フラグ、ガードレール、可観測性、依存関係の分離、blast radius の縮小、重要経路外の小さな変更から始めることといった答えは、レビューの核心を外しているものとして扱われる
- レビューの目的は、障害、セキュリティ問題、偶発的なデータ削除に対する負担を一個人に置かず、作成者とレビュー担当者全体のチーム責任として分け合うことにある
- 「読まずに承認」を求めるなら、人に手動でボタンを押させる理由は薄れ、すべての CI が green の割り当て PR のうち 1 つをランダムにマージする
button rouletteという風刺が登場する
読まないレビューが失うもの
- コードレビューは、チームメンバーがコードベースの別の部分を見ることを強制し、あまりに大きなシステムでは全ての部分を常に把握してはいられないという限界を補う
- レビューのプロセスは bus factor を下げ、チームの複数のメンバーがコードベースとコード文化により習熟するのを助ける役割を果たす
- 全員が読まずに承認するようになると、こうした学習効果を失い、bus factor が 1 になるだけでなく、第三者への外部化 という問題も生じる
- 読んでいないコードを本番環境にデプロイせよという要求を受け入れるには、その指示を出した人がバグ・セキュリティ問題・ダウンタイムなどについて書面による責任免除を提供しなければならない、という答えでまとめられている
1件のコメント
Lobste.rs の意見
レビューの目的が責任分散だという主張には強い拒否感がある
main にマージしたコードが本番環境を壊したなら、それは作者の責任であって、私やチーム全体の責任ではない
専門職として自分の署名が入る仕事であり、土木工学の P.E. 免許で押印した橋梁設計が人を死なせたなら、それもまた本人の仕事と責任だ
チームの責任は、開発者でありコードベースの管理者として、誰のコードであっても 本番環境を壊せないようにすること にある
main へのマージは、誰かがレビューし、変更を精査し、設計を議論し、何度も修正したうえで承認したことを意味する
エッフェル塔を一人で建てる人はいないし、職場で個人を責めれば恨みと 有害な文化 しか生まれない
それが反復的な行動パターンなら、HR が扱うべき問題だ
責任が 0 ならレビュアーは役に立たず、わざわざレビューをする理由がない
責任分散は結果に近く、核心的な目的は、一人なら見落としやすいが二人以上なら見落としにくい バグを見つけること だ
ただしソフトウェアではレビューが過剰に使われており、レビューが エンジニアリングの代替 にはなりえないとも思う
「コードを読まずに承認する」を「考えずに承認する」と同一視するのは正確ではないと思う
たとえばプログラムに 正当性の証明 が付いていて、PR で定義と定理を読めて、CI が決定的なツールでプログラムと証明の整合性を確認し、コントラスト比・性能ベンチマーク・テールレイテンシのような非機能要件も検査し、UI 変更についてはプロトタイプを簡単に触れるとしたらどうだろうか
そんな世界でも、コードを一行ずつ読むことに今と同じだけ執着する必要があるのかは疑問だ
今日でも大半の人は SQL を書くとき、クエリプランが正確に意図どおりかを逐一検証したりはしない
元記事は「文字どおりコードを読まなくてもデプロイしてよいと感じられる理想の世界を定義してみよう」に近く、その次に「現在からその世界へどう滑らかに移行できるか」を問う記事として読める
業界や特定の会社・コードベースがその地点からどれだけ遠いかは議論できるが、その理想世界を真剣に想像すれば、たいていの人はいくつかの基準を思い浮かべられるはずだ
現在の業界の流れのせいで「考えずに」と受け取ってしまう気持ちは理解できるが、Charity の記事が言っているのはそれではないと思う
これはテストがどれだけ良くても、コードを読まなければ実現できない
Alice がコードを入れ、Bob がレビューしたあとで Alice が休暇に入ったら、Bob はその部分を十分に理解し、責任感を持って修正や新機能追加ができるべきだ
Bob が正当性証明にただ判を押すだけなら、その後そのコードベースを扱う準備ができていない
コミットの過程に参加していても、知識や 当事者意識 が増えていないなら、実質的には参加していないのと同じだ
ただしコンパイラは決定的だが、LLM は潜在的に疑わしいテストを生成する非決定的なツールだ
私たちはすでに、人が書いた指示やコードを機械が読めるコードまたは中間表現に変換するプログラムを持っており、生成結果が入力とどういう関係にあるかを保証するので、出力物をいちいち検査しなくても信頼できる
最適化のために Godbolt のようなツールでコンパイラ出力を読むことはあるが、それ以外ではたいてい不要だ
非決定的な別の抽象化レベルでこれを試みるともっともらしく見えるかもしれないが、コンパイラが与える正確性保証をまねているにすぎず、結局は問題が起きるだろう
LLM 論争は、より根本的には既存の決定的プログラミング言語が十分に表現力を持たず、ツールも十分に効果的でないという問題の症状だと思う
LLM がその問題を解決すると感じられるかもしれないが、実際の解決策ではなく、制約の強すぎる土台の上にさらに一つの間接層と性能コストを載せるようなものだ
インタプリタの上で、さらにコンパイル済み機械語の上で動く、高価でバグの多い 擬似コンパイラ に近いと思う
だから技術的な袋小路だと考えている
企業にとっては短期的な収益の道になりうるが、ソフトウェアそのものや、人間がソフトウェアを使い作る関係を改善するとは信じていない
ソフトウェアは製品を出荷するための技術以上のものだ
用途ごとに分けて考えると役に立つ
社内アプリケーションの UI 向けに新しい JavaScript を上げる程度なら、CSS まで必ずしも細かく見る必要はないと思う