プルリク事後レビュー会
週1回1時間
他の人のpull requestは
が即日レビューしてさっさとリリース
「とりあえず3ヶ月ぐらいやってみよう」で開始してみたら
現在8ヶ月目
調子良くリリースしている
今年、Cosenseチーム全員合わせて447 pull requestをリリース
以下は2024年1月に書いた、/Nota/2024年からのScrapboxプルリクレビュー方針からのコピペです
結論
もちろん、リリース前にレビューできるならしても良い
週一でが
に、最近リリースしたものを説明する会を開く
とりあえず3ヶ月ぐらいやってみよう
まずは、Scrapboxそのものにある程度詳しくなる必要がある
コードの土地勘は、結局レビューだけしてても得られない（と思う）
自分で書いて動かして壊して、直した部分しかわからない
私のプルリクをコードの細かい所までレビューする必要はない
問題や状況の分析・それに対するコンセプト・ソフトウェアの設計と実装・動作パフォーマンスなど、全てに問題が無い
むしろリリースが遅れて品質が下がる
賽の河原的な作業となり、レビュアーの健康は害される
夜に影を探すようなもの
どういう変更が安全か危険かは、ちゃんと基準があってわかってる
月30〜60件
2023/12は72件だった
これをまじめにレビューすると死ぬ
過去メンバーみんな死んできた
そもそも、他プロダクトでは
みんな月に8〜12件程度しかレビューしていない
Scrapboxの場合
プロダクトに詳しいが作ったものを、プロダクトに詳しくない人が
月50件レビューする事になる
しかも色々同時進行していて、ぱっと見は脈絡が無い
clientの変更の次は、serverの変更のレビュー
bug修正も新機能もある
問い合わせ対応のための突発変更の次は、長い調査を経たデカい文脈がある変更のレビュー
レビューだけで人生が終わる
2つの手順がある
実装→開発チームでのレビュー→リリース
旧来の多人数チームでの開発手法
実装→リリース→開発チームでのレビュー
私のプルリクについては、こっちにしたい
コードの細かい書き方などが気に入らない場合は、気に入らない人が、リリース後に別途pull requestして直せば良い
週2回ぐらい、リリース済みの実装を解説する会を行うのはどうだろう >
2019年ごろはエンジニアお茶会がそういう役割だった
月2回だとこの用途には少なすぎる
週1でもいいかも
いいと思います
そもそもコードレビューの役割とは？
知識の共有
ダブルチェックによる品質向上
インシデント発生時に対応できる人を増やす
結局、レビューだけしててもインシデント対応はできない。こんな物は幻想だ
プロダクトに詳しい人が仕様を決めて、開発者に発注して、成果物を検収して取り込む
これがコードレビューという物だと思う
これまで、Scrapboxはそうではなかった
プロダクトに詳しくない人が検収していた
その作業でbugはほぼ見つからない
400件に1件ぐらい？
詳しくないから
コードレビューの意味が知識共有だけになっている
Scrapboxの場合、さっさとリリースした方がソフトウェアの品質は向上する
正しいソフトウェアとは
実装が正しい
これはコードレビューで担保できる
ユーザーの問題の理解と解決方法が正しい
こっちはコードレビューで担保できない
大量の無料ユーザーが、開発者が考えもつかない使い方をして、フィードバックをくれる
OS × ブラウザ × IMEの組み合わせで25通りぐらいある
Ubuntu + Firefox + mozc
iPad + MS Edge + magickeyboard
用途がいろいろ
エンジニア、法律家、学校の先生、学生
土日や夜しか使わない人がいて、彼らが正解を知っている
対ビジネスユーザーの問い合わせ
第一報で「もう直しました」と返信できるとサポートコストを削減できる
ぶっちゃけ
hotfix的にがどんどんリリースした物でトラブルは起きていない
これまでも、レビューが追いつかないので7日間放置などで時限式にリリースしてきた
コードレビューで致命的なbugが発見された事が無い
少なくとも、最近4年間は思い当たらない
おそらく自己レビューしているおかげ
難しい物は1〜3日置いて考えなおす習慣がある
仕様bugもほぼ発生しない
数ヶ月〜数年かけてscrapbox上で熟考しているから
昔、残業時間が上限突破した月があってそうなった
プロダクトに関わるモチベーションがおかしい
元々趣味でwikiを作っていて、それをNotaでやる事になったので
平日8時間労働できない
7時間ぐらいでやめてる
8割ぐらいの出力で、休日もダラダラ開発する方がやりやすい
2023年12月に完全自己レビューワンオペ作業してみた
結果：72件リリース
大量のbugfix、4つの新機能リリース、開発環境やライブラリの大量更新などができた
やはりトラブルは起きなかった
このとてつもない開発力をプロダクトにぶつけないのは人類の損失