19章 GoogleのコードレビューツールCritique
Critiqueは、Googleで利用されている唯一のコードレビューツールというわけではないが、2位以下に大差をつけて最も人気のあるコードレビューツールだ
別のツールがある?
GitHubに社内VCSのPiperをミラーしているとか?
コード変更の「スコア付け」に関する節で論じる
なにこれすごい。本当にChatGPT以前のツールなのかと思ってしまうな。。。
19.1 コードレビュー用ツール環境の原則
単純さ、信頼の基礎、汎用コミュニケーション、ワークフロー統合っていい原則だなぁ。。。スクラムっぽい。。。
Critiqueは(中略)望むことをコメント内で詳しく説明するようユーザーに促したり、あるいは編集提案をいくつか出しさえする
ちょっと信じられない。Copilot並の機能を実現していたとすればオーパーツと呼んで差し支えないレベルでは
ほんとそれです。やばい。論文で書いてあった夢の技術がGPTなしに実装されているのやばいな。
静的解析と検索?
バグに対するパッチを紐づけてサジェストさせているのでは
単純さ&ワークフロー統合
UNIX哲学だ
まさにー!
他の社内ツールでもこの方針が維持されてそう
単純であるが、やっつけでなく機能自体はきちんと磨かれている
主眼をコードレビューに留めておくことをあえて決めた
プロダクトをシンプルに保つ姿勢がいいなー
19.2 コードレビューのフロー
ユーザーはそうしたイベント通知を受け取るChrome拡張機能†2をインストール可能である。コード変更がユーザーの注目を要する場合、例えばコード変更をレビューする順番が回ってきたり、何らかのリポジトリー提出前処理が失敗した場合、このChrome拡張機能は、直接コード変更へ移動するか通知を止めるかするためのボタンの付いたChrome通知†3を表示する。
Chrome拡張機能で該当箇所への通知がくるとかもふくめてやっぱり細かいUXへの配慮がすばらしい。。。
静的解析もそうだけど、ブラウザ通知はブラウザで開きたい箇所へのこういったリンクをどんどん出せるのがいいよなぁとあらためておもった。
現代だと通知の役割をチャットに集約するという話になる?
それは逆で、対象の人にだけ通知が来る仕組み&対象箇所にいきなりジャンプできるほうがUXが優れているのでは
無視する際のUXはチャットでもそんな変わらないので、すぐ取り掛かれる際のUXはこちらの方が上
19.3 第1段階:コード変更を作成する
Critiqueはレビューツール内でコード変更に軽微な修正を加えることもサポート
エディタで見るのとレビューツールで見るのとで見え方が違ったり、pushした瞬間にミスに気付いたりするのはあるあるなのでこれはありがたい
人の認知に文脈依存性がある以上は防げない現象
軽微な修正のプロセスがおそらく軽いのは、VCSが中央管理型であることのメリットかも
GitHubなどでも画面から変更を積めるが、仕組み上その変更をコミットとして積まないといけないので、そこで1プロセス増える
それが面倒で結局エディタからやってしまう
19.4 第2段階:レビューをリクエストする
レビュアーをサジェストするの神機能だ。。。
PRのdescription?にもルールを強制できるのもすごいいいな。GitHubではテンプレートを適用するのは簡単だけど、ルールを強制するのってできたっけ?
Googleの静的解析への情熱がわかる
19.5 第3段階と第4段階:コード変更の理解と、コード変更へのコメント付加
change list searchみたいなダッシュボードを高速に表示できるようにきっとつくってあるのかな?こういうところもGoogleが普段使っている技術がいきていそう。
コメントするという行動は、Critiqueでユーザーが行う行動の中で、コードの変更の閲覧に次いで2番目によく起こるものだ。
何で自作のツールがこんなに沢山あるんだろうかと考えた時に、勿論自分達で使いやすいように拡張できるということの他にも、どういう風に開発者ツールが使われているかデータが取れるというメリットがGoogleにとってとても大きいんだろうなと思った
図19-8 ダッシュボード画面
Size
これめっちゃ大事、コードレビューが止まる原因の1つは着手への心理的ハードル
小さいなら今から見るかとなるし、大きいなら「分けてくれ」と伝えるか時間を確保する行動が取れる
19.6 第5段階:コード変更の承認(コード変更のスコア付け)
レビュアーはコメントに未解決という印を付けることもでき
これすごく良い。対応は不要だけど気になった点や、実装意図を確認するコメントがしやすい
☑ Action Required という表記が図19-7にある
承認だけではなくてLGTMも必須で未解決コメントがないっていうルールめっちゃうまくいきそう。
トラッキングされていてランキングすることもできそうだし、ほんとうによくわかっているなーっていう感じがする。
これ、承認とLGTMを分けている理由なんなんでしょうね?承認⊃LGTMに見える(基準を満たしていなければコードベースへのコミットは許可されないはず)ので、承認だけでも良いような気もする
あえてLGTMの方をゆるくして、非同期に進めやすくしている?
レビュアー側の心理的障壁を下げるため?→承認 or Notの2択でなく、LGTMで一度フィードバックできるようにしている。レビュアー以外でもつけられるようにしている。あくまで「To Me」なので意見を集めやすい
19.7 第6段階:コード変更のコミット
gerritめっちゃなつかしい。以前に使おうかどうか悩んで結構プライベートで触った記憶がある。
19.8 結論
コードレビューツールを使う場合には、いくつもの暗黙のトレードオフが存在する
恥ずかしながら基本的にGitlabばかり使っているので、トレードオフがあると考えたことなかった
コードレビューは価値があるっていうだけじゃなくて、価値が高いからもっといいものにしようとか、その価値を文化にするためにもエンジニアリングでサポートしているのがほんとうにすばらしいなー。
こういうのって、1. トレーニングで解決 2.評価で解決くらいの優先順位で実施されていると思うけど、ツール化するところまでもっていっているのがほんとうにいい。
コードレビューに費やされる時間は、コードを書くのに費やされている時間というわけではないため、レビュープロセスの最適化はどんなものであれ、生産性の面で企業の得になりうる。
上期レビューに使う時間が多すぎて自分の開発作業を圧迫したので、これを見て改めてレビュープロセスの見直ししないと…ってなってます。
19.9 要約
注意セットの話はまぢ共感
今の自社の運用が「誰が対処しているのか理解するために、レビュアーとコード作者の間でチャットを行う」で対処していて、レビュアー側に依頼が溜まると「摩擦」が…
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
テキストのパースみたいなちょっと難しそうな処理が多いとか?一方で一般的なワークフローエンジンと似たようなところもあってそういうのをコードレビューにもちゃんと持ち込もうとするっていうのは、ある種の当たり前を疑う力みたいなのがありそう。それも、スケールさせるためっていう大きな目標があるからできるのかもしれない。
コードレビューのツールに投資して自社ツール使っていこうってなかなか判断できることじゃない
エンジニアリングを俯瞰で見て、ここがコスパいいとか、ここのデータ取れたらもっとツールを改良して使えるよねとかそういうハックする思考ができないと
今となっては、ほとんどの機能をGitHub/Gitlabが実現してしまった
シンタックスハイライト、差分の参照、移動検知、コメント、レビューのランダムアサイン、Approve、ファイルごとのレビュー済チェック、コメントへの解決マーク
オンラインIDEやコード検索(これは弱い)も取り込み、静的解析、ビルド&デプロイ、カバレッジ検出も他アプリとの連携をサポートしている
現場でどこまでできているか?
既存のツールでいいから導入しようっていうのはできているとおもう。
一方でコード以外にもレビューって全般的にめっちゃ効率がいいので、他の部分でもできているかといわれると怪しい。
よくよく考えると、コードレビュー意外にも実はツール化するとよさそうなものはたくさんありそう。
車輪の再発明はやめようとか、テックジャイアントに乗っかろうって話はするけど、ここまで投資するのは無理。。。
一方で自分達が普段使っているツール(gitlab,slack,box)で取れるメトリクスを有効にマネジメントに活用できているかと問われると出来てないなと自省
注意リストもどきが毎朝Slackに流れるようにしている
openされていてレビュアーがアサインされているMR(Gitlab使ってます)と、アサインからの経過時間
毎日朝会で確認して、アサインの偏りと経過時間を見て調整や催促をしています
確かにレビュワーへの偏りって見えないのでよさそう
この本があるのになぜ実践する企業はすくないのか?
コードレビューツールの実装みたいな話だとそこまで大きい企業はないっていうのはありそう。
MSだってGithub買収しているし、自社でイチからってのはなかなかないのでは
それの乗り越え方はなにか?
自社の製品?アウトプット?の品質を高めて手戻りを減らすために有効なレビューとはなにでそれを効率的におこなうためのツールやデータ収集方法は何かを考えるのはやりやすそう?
バリューストリームを見て、やっぱりコードレビューって大事だから今あるツールのメトリクスを使ってもっと良くしようというマインドかなぁ
ステップを小さくするとしたらどうできそうか?
手戻りがおおいワークフロー?業務?を議論してみるとか?
GitHubという巨人の肩に乗る
GitHubの想定しているワークフローを理解し、それに依拠することで高速にレビューを回す
注意リストを実装する