チームのコードレビューが遅い、厳しすぎるとき、どう回し直しますか

こう聞かれます

• 「レビューが滞って、プルリクエストが何日も止まっていたら、どうしますか」
• 「レビューの指摘がきつくて、メンバーが萎縮していたら」
• 「チームのレビューの決まりを作ったことはありますか」

面接官が見ている点

• 個人の頑張りに頼らず、チームの決まりと仕組みで直そうとしているか
• 感覚で決めつけず、待ち時間などの事実から詰まりを探しているか
• 質を落とさずに速くする方法と、人を傷つけずに厳しく見る方法を分けて考えているか

短い答え

• まず待ち時間とプルリクエストの大きさを数えて、どこで詰まっているかを見ます。
• 「最初の返事はその日のうちに」「1 つのプルリクエストは小さく」のような目安をチームで決め、見る人の当番も決めます。
• 書き方の好みは自動の検査 (整形や静的な検査) に任せ、人の指摘は「必須」と「提案」に分けて、厳しさを和らげます。

少し詳しい答え

よくある間違い

• レビューを無くして、書いた人の判断で取り込めるようにする速くはなりますが、不具合と知識の偏りが増えます
• 遅い人を名指しで注意する原因が仕組みにあるときは、注意しても直りません
• 厳しい人をレビューから外すその人の知識が使えなくなり、質が落ちます
• 気づいた不具合も遠慮して言わない厳しさを和らげることと、指摘を減らすことは別です

深掘りの問い

• 「急ぎの直しもレビューを待つのですか」急ぎのときの流れ (あとから見る、2 人目は省く) も決めておき、例外を例外のまま残す、と答えます
• 「レビューする時間はどこから出すのですか」レビューも仕事の一部として見積もりに入れ、書く仕事より先にする、と答えます
• 「新しい人にレビューを任せますか」詳しい人と組んで見てもらい、知識を広げる機会にする、と答えます

関連するコースと用語

• コードレビューの受け方・出し方
  コース「Git入門」
• Gitのプルリクエストを出す
  コース「Git入門」
• 自動の検査のさわり
  コース「Git入門」

用語集で確かめる言葉は、コードレビュー、プルリクエスト、CI です。