コードレビューの思い出
ふた昔(苦笑）ぐらい前にも、コードレビューという文化がありました。
キャリアの最初のころを思い出してみると、確かにコードレビューをした覚えがあります。
当時は、ソースコードをプロジェクターを使ってスクリーンに映し、メンバーが集まってあーでもないこーでもないと議論するというような方法が主流だったようなのですが、私のいた会社ではそういう設備はなく、全部ソースコードを紙に印刷して、印刷したソースコードにペン入れして修正してました。
しかも、修正のたびに印刷しなおしていたので、紙の消費量が半端なく、何とも非効率でSDGsなんて糞くらえな方法でした(笑）
まぁ、コードレビューというのはプログラミングというテクノロジーが生まれたと同時に存在していたようで、プリンターがディスプレイ代わりだった時代もあり、件の方はそういう世代の方だったので、紙ベースから脱却できなかったのかな？と思います。
ちょうどそのころに、ペーパーレス化しようというような議論が流行していたと記憶しています。
さて、その次の会社は、特にコードレビューというものはなく、作ったものを上司やチームリーダーがみてOKならよし。NGならリーダーが修正することもある…という感じだったのですが、基本的に修正されることはほとんどなく、それよりも、”テスト”が重視されていました。テストが通らなければ通るように修正するという感じで、テスト駆動開発っていう言葉が当時からあったかは不明ですが、割とそれに近いことをやっていたとおもいます。
昔を思い出してみても、あまりコードレビューが話題になることがなかったように思います。廃れた大きな理由は、やはり、あまりにも時間がかかりすぎ、非効率すぎる。という点に尽きると思います。
ですが近年(ここ5年以内）では、GitとWebサービス(GitHubとかGitlabとか）を使って手軽にコードレビューができるので、コードレビューを採用している企業も多いようです。
ですが、この新しいコードレビューについて、いろいろな意見がありますし、ルールや方法についても様々な議論があります。
どうしたらより良い方向でレビューができるかについて調べてみたいと思います。
コードレビューをほぼほぼ全否定する派
まずは、コードレビュー否定派の人の意見
コードレビューの是非はともかく、一度でもコードレビューの経験がある人であれば、”あるある”と思うことは多いのではないでしょうか？
リンク先にも、いくつかリンクがありますし、ネットを検索しても出てきますが、コードレビューに対して
怖い
つらい
めんどくさい
イライラ
など、ネガティブな印象を持つ人が多いのがわかります。
略語について
レビューについて語っていく前に、略語について。これも、一般的にコードレビューでよく使われるようで、LGMTは結構有名かと思いますが、ほかにもたくさんあります。
特にレビューにおいて、文章だと、”絶対直してほしい”のか”こっちのほうがいいかも？”など、ニュアンスや温度が伝わらないことがありますが、こういった略語を頭につけておくととても明確になります。
ということで、これらの略語も使っていきながら語っていきます。
[must] 絶対やってはいけないアンチパターン
まず紹介するのはこちら
ここでは5つのパターンとその解決策が示されていますが、かなりありがちです。
1のコメントが怖いとか、３の誹謗中傷というのは、レビューでなくても、リモート勤務でチャットベースでのコミュニケーションが主体の現場では発生することがあります。
文字ベースではニュアンスが伝わらず、文章も事務的になりやすいので冷たい印象を受ける恐れがありますので、十分注意して書くべきですが、こういったことを理解しない無頓着な人が一人でもいると、メンバーの作業効率ややる気、メンタルの低下を招き、最終的には
チームは崩壊します。
２の理由がないに関して、
コードレビューをする目的の一つとして、レビューイの教育ということが挙げられますが、指示のみで理由がないければ、なぜそうなったのわからないため、教育という目的を果たせません。理由がわからなければまた同じ間違いをする可能性があります。
そのぐらいだったら、コードレビューなんてやめて黙って修正した方が時間と労力の節約になります。
もっと酷いのは、指示すら書いてないもの。これは、もはやただの誹謗中傷です。
これらも、レビューだけでなくリモート勤務でもありがちな事例です。
４の大量コメントと５の長大な議論は本質的には同じものです。
[imho]基本的に”エビデンスを残す”という意味合いで、テキスト化しておくのは良いことだと思います。特に、商談などの対顧客、ビジネスレベルでの話の場合、口頭でやり取りすると言った言わないの議論になってしまうことがあるので、証拠を残しておくというのは重要です。
ですが、コードレビューもそうですが、商談でも込み入った内容、人によって意見が分かれるような内容で、議論が始まった場合は、説明する事項があまりにも多い場合は、迷わずボイスチャットを使いましょう。
テキストベースで議論や長文を入力するのは、感情的になりやすく危険であり、入力や返答にも時間がかかるため、心理的安全性や時間的コストの面で最悪です。
長々1時間かけて説明した内容も、実はボイチャで話せば5分で済む…なんてことはざらですので。
エビデンスを残すという目的で、あえてテキストチャット使うという理屈もわかりますが、たとえば録画、録音するとか議事録を取りながら行うなどをすれば十分なのではないでしょうか？
また、このブログを書いた方は、Team Geekという本をお薦めしていますが、これは良さそうですね。ちょっと古めの本なので入手困難ですが、入手できたら書評してみようかなと思います。
コードレビューの原則
次にコードレビューの方法論について２つ紹介します
こちらはGoogle
こちらはクックパッド
こういった企業で行われている方法を参考に、チームの状況にあった方法を模索していくとよいかと思います。
