コードレビューと、コード以外のレビュー
似たようなお話はいろんなところに書いてきたとは思うのだけれど、まだ書く意義がありそうだな〜と感じたので 2019 年 2 月版として書いてみようと思います。
-----
「ピアレビュー」とは、特に同僚同士(peer)による技術的視点に立ったレビューの意味。
さて、現在のぼくの勤務先である GMO ペパボのように GitHub Flow をベースとした開発フローを採用している現場においては、誰しもが息を吸うようにピアレビューの一種である「コードレビュー」を各位の開発に組み込んで活用していることでしょう。ぼくが現場を見渡してみると、昔から在籍している人も最近になって入社してきた人も、当然のようにコードレビューに関わり、そのメリットを享受しています。「コードレビューなんて無視だぜ！デプロイだ！」とぶっちぎって行動する人はぼくは見たことがないので、多かれ少なかれ、みんなコードレビューを実施するという方針を受け入れて暮らしているのだと思います。 ところで、先ほど意図的にコードレビューのことを「ピアレビューの一種である」と書きました。レビューの対象となり得るのは、なにもコードだけではありません。
「チームでコードレビューを実施しているのですが、こんな問題を抱えていて…」と相談を受けることがあります。「それは大変ですね」と詳細な状況を教えてもらうと、コードレビューは実施しているものの、コード以外のレビューをあまりしていないことでコードレビューの負荷が増大する問題が発生しているように思えるケースがちょいちょいあります。 たとえば「設計レビュー」があります。実装作業に入る前に「こういう方針で実装していこうと考えている」を表明し、レビューしてもらい、チームがよりよい設計に到達することを目指します。設計フェーズで軌道修正できればよかった内容を実装フェーズに持ち越すと、コードレビューが大変になります。レビュアーが「そもそも、」から始まるフィードバックをするケースでは、最悪の場合、目の前の実装をすべて捨てて設計からやり直すことになるでしょう。 ソフトウェア開発ですから、一般に、問題の発見がうしろのフェーズになればなるほど、その対応や軌道修正にかかるコストは大きくなります。コードレビュー、つまり実装フェーズのレビューに多大なコストを支払っていると感じるようでしたら、コードレビューに至るまでに過ごすもっと手前のフェーズの時間の使い方を疑ってみるとよいと思います。 -----
GitHub や GitHub Flow が多くの現場で活用されるようになり、我々の業界にコードレビューの文化が根付いたことは、大きな前進だと捉えています。コードレビュー、有益だし便利だし、楽しいですよね。これからもその特性を正しく理解して、現場に効く形で取り入れていきたいものです。 一方で、コードレビューがなにもかもを解決してくれるわけではありませんし、コードレビュー以外の道具を持ち出した方がよっぽどスマートに解決できるタイプの問題もあります。コードレビューを存分に活かせるようになったチームは、一段階だけ抽象化して、今度は「レビューを活かせるチーム」を目指してみるのはいかがでしょうか。 先に挙げた「設計レビュー」もそうですし、動作確認手順やメンテナンスの作業計画書なんかにもレビューのプロセスを噛ませてみると、きっと発見があるはずです。極端な話、ぼくはチームで取り組むプロジェクトにおけるあらゆる成果物は中間成果物も含めてレビューするに越したことはないと思っています。実際は、なにもかもをレビューしているとコストとのバランスが悪くなるのでほどほどになりますが。 チームを強くするには、チームメンバー間のインタラクションを密にすることが重要です。レビューはそのために利用できる便利なアクティビティと言えます。レビューのチャンスをすべて見逃すチームと、適切にレビューのチャンスをものにできるチームでは、後者の方が強いでしょう。 みなさんのチームは、レビューを活用できていますか？試しに「もしかしたら、これもレビューするといいのかも」と考えてみると、気付きがあるかもしれません。
---
ここに書くのが最適か微妙な話：今日いろんな人と話してある程度の確信を得たんだけど、コードレビューが「書いたコードを裁判されるイベント」みたいな扱いをしている人が多いように感じたtokky.icon
確かに、サービスを良くしていくためには良くない部分を指摘するコードレビューは必要だと思うけど、それ以外に「その人が書いた良いコードを褒める瞬間」があると非常に良いのでは？と感じた
サービスを悪くするためにコードを書く人は（恐らくは）いないと思う
コードを書くためには、「ソフトウェアエンジニアリングの知識」「サービスの背景」「その機能に求められる信頼性」の知識が必要だが、コードを書く人間がその全てを熟知しているとは限らない これらの知識を得るためには一定の経験が必要で、その経験を得るための仕組みがそのコミュニティに備わっていないと、コミットしてくれる人間が増えることはない なので、仮に「サービスの質を悪くするようなコードを書く人」がコミットしてきたとして、短絡的に「あなたはこのサービスの質を下げるコードをコミットしているので価値がない」と断じるべきではないと感じている
良くない部分を指摘するのは当然必要だけど、「良い部分の指摘」もしないと釣り合いが保てないtakker.icon
良くない部分の指摘は別にその人物を非難しているわけではないのだが、心理的に非難されていると当人は感じてしまう
良くない部分の指摘が後から言われる、公開される、残るのが苦痛で、その場で言われて消えるのだとそうでもなかったりしてというのをモブプログラミングして感じた。書いている瞬間から直っていくのは別につらくなかった。 niku.icon これを書くにあたって読み返した資料たち