2019/8/9「review は質を擔保するものではなく會話の機會である」について
前述のコードレビューのところは、いろいろな前提が無いと健康に運營できないので、そこを內省してみる。
當時の狀況
Kief Morris, 宮下剛輔監訳, 長尾高弘訳 (2017) "Infrastructure as Code", p.263
休日夜に障礙で叩き起こされ聯絡つかず一人でコードを直す時に守るべき merge 手順を作り、それだけを作った。コードレビューに關するところを記憶から抜粹すると、
CI (lint & test) は必ず通す
PULL_REQUEST_TEMPLATEは必ず埋める
空欄ではありえない項目として、「關聯するチケット (無ければ「無し」と明記する)」「槪要 (自明ならpull requestタイトルのコピペでもよいから書く)」「影響範圍・ターゲットユーザ」「變更の確認項目」「マージする際の注意點 (他のリポジトリと同時にmergeしなければならない事が多かったので。無しなら「無し」)」「リリースする際の注意點 (停止メンテ要る? y/N)」があり、これらには「必ず書く」と書いておいた merge前に誰か一人からLGTM (Looks good to me) をもらう事が望ましい
(暗默のルール) 全てのPullRequestを見る事が望ましい。いつでも。merge後や古いものでも
(暗默のルール) いつでも誰でも誰に對してもどんな話題でも發言してよい。それを止めない
これらは前提無く成立しない。
CI
CIは常に意味有る內容で、速く、通る狀態に保たなければならない。保つコストは拂ふ (Elixirは差分compile & parallelで走らせ易いので樂)。一度だけ數時閒壞れ續けた時があり、二個ほど悲しみとともに落ちたままmergeした。
CI が落ちた Pull Request が來たら、コードを見る頃にはもう結果が出てゐる (5 分前後で終ってゐたとおもふ) ので「まず CI を通してください」で濟ませる。困ったらすぐ周圍の空閒に感嘆詞を發聲できたのでこの返答でも孤獨を感じにくい。リモートだとこれはよくない。
今この瞬閒の人閒よりも、過去の人閒たち (自分たちを含む) の疊み込み convolution を信賴する事でもあり、技術といふものはこれができる。
PULL_REQUEST_TEMPLATE
GitHubでPull Requestを作ると自動で入るテンプレート。自明でも書いてゐた。まずたとへtypoを直しただけでもその通りに書けるので「書けない」事は無い。
このPULL_REQUEST_TEMPLATEには3つの意味があった。
コードを書いた人閒が我が身を振り返る
Pull Request をレビューしつつ會話する話題として
後から見返す
であるから、モブプログラミングでできあがった Pull Request でもこれを書く價値がある。「これはつまり…こういふ事ですね」と會話しながら書けるのでむしろ、よい。緊急時に我に返るタイミングはここしか置いてなかったので、傷を廣げないためにも省略できる手順ではなかった。
LGTM
「OK」ではなく「LGTM」なのが大切で、looks good to me、「私は」いいと「思う」。ここが前の記事の「レビューは質を擔保するものではなく」といふところ。質はチームで擔保するものであって個人で擔保するものではないといふ事も前提にはある。個人だけに主體があるのではなく、チームが主體として存在しうるといふ假說も更に前提にはなってゐる。
「レビューは質を擔保するものではなく會話の機會である」について
會話は通常 TCP のやうなものだとみなされ、まず相手を定めセッションを確立する事が會話をする必要條件であると考へられることもある。だがこれは必要條件ではない。UDP ブロードキャストのように會話できる場合がある。これははてなだと珍しくない (やうに見える)。ド社では珍しくなってしまってゐたので、まず UDP ブロードキャストもできるチームを作った。運がよかったので、私がやったのは感嘆詞を發聲する事と人の發話を止めない事だけで、「人は仕事をやってゐるものだ (裁量がある)」といふ事を前提すればこれはできる。發話のハードルを下げる、そして發話する (あと適切に仕事をする) といふのが前提の一つ目であった。
全員がシステムの全體を觸れる狀態を保つ、といふのが二つ目の前提であった。更なる前提を二つ見つけられる。まず常に會話してゐるし、必要な作業はコードに落とし、Pull Requestはわりと全員が見 (これを嚴密に運用してはいけない、それは不信を生產するので)、タスクのアサインを工夫したりモブプログラミングを每週開催するなどで、實際に全員が濃淡はあれどシステム全體を觸れる技能があるといふ事。もう一つは全員が技能があるといふ信賴を全員がもってゐる事 (2 階の共有智識と同じ構造)。信賴は無條件には生產されないのでその條件を工夫する事が要る。そして信賴は集中して配分するのではなく、共有する。 これで先のルールを運用できるのではないかとおもふ。緊急時にはPull Requestをmerge前にレビューする事を保證できないので、保證しない。質は普段の運用で事前に保證するし、リファクタリングを普通のタスクと同時にやり續けるので質は事後にも保證する。リモートワークではなかったので書くパッチはPull Requestになる前に口頭でだいたい衆知のものになってゐた。質は持續して保證し續けるので、レビュー時に集中して保證する必要が無い。
するとレビューとは何か。レビューも通常の活動の一貫なので、質の保證を「排除」するものではない。しかし質の保證は常々にやってゐるので、レビュー時に特別に話題にするものではない (普通にやる)。Pull Requestをレビューする時にはコードは「完成」してゐる、といふのが體驗的な違ひだとおもふ。完成するといふのは全體を俯瞰できることと同義だと考へてゐる (そう考へなければすべてのものは未完であり、この世に「完成」と云ふ槪念が成立しなくなってしまふのではないか)。mergeといふ仕組みによって、Pull Requestをレビューする時にはそのパッチは完成してゐる。そこでレビューはそのパッチを俯瞰できる機會である事になる。これが「レビューは質を擔保するものではなく會話の機會である」といふ文言の意味であった。
といふ事が過去にあった。