コードレビューを段階的に導入する方法

私は6人のシニアエンジニアでチームを率いています。私は、すべての標準的な理由でコードレビューを行うことは私たちに大いに役立つと信じています。必ずしもすべての変更ではありませんが、少なくとも背景レビューの着実な流れ。したがって、人々は少なくとも他の人の変更を見て、それらについて話し始めます。

レビューを紹介する良い方法はありますか？チームから大きな不本意を感じています。それはもう1つのことであり、会話が苦痛になる可能性があるからです。少なくとも最初のステップとして、すべての変更をレビューすることは初心者ではないと感じています。量を増やす前に、まず低頻度でレビューを行うリズムと練習を始めてほしい。

誰かがコードレビューを徐々に成功させましたか？どうやって？しかし、「ホットな」ファイルまたはライブラリのレビューを要求することについては考えました。またはランダムに選ぶ。または、「選択」する必要がある変更を確認することを選択します。または、思い切ってすべての変更を行うことが唯一の方法ですか？

これは、ツーリングやプロセスの問題ではありません。それは文化についてです。あなたは自分の仕事を批判し、保護することに敏感な人々で構成されるチームを説明します。それは非常に一般的です。しかし、それはプロではありません。

私のアドバイスは、例によってリードを開始することです。レビューのためにコミットを提供します。あなたのアプローチの問題を人々に強調するように要求することについてオープンになってください。フィードバックを受け入れます。守備するのではなく、フィードバックの背後にある理由を探り、チームとして行動に同意してください。開かれた対話の雰囲気を奨励する。チーム内でこれを行う意思のあるチャンピオンを見つけてください。

それは大変な仕事だ。

最初のステップは、誰かに近づいて、「ちょっと、コードをレビューしてくれませんか？」と言うことです。組織で見たい変化になりましょう。あなたがそれをやろうとする一人の個人を見つけることができないなら、あなたはチーム全体を納得させることができません。2人が成功した場合は、チームに報告してください。

あなたのコードをレビューする誰かを見つけたら、あなたが彼らのコードのいくつかをレビューしてもいいかどうか尋ねてください。以下のための学習機会として、フレーズ、それをあなたとないための機会として、彼らは彼らのコードを改善します。

チームリーダーとして、コードレビュープロセスから得られる最大の価値は、何が起こっているかを認識することです。開発者向けの変更や提案がなくても、すべての変更セットを見る機会を得たいです。これらを「意識レビュー」と呼びます。ボトルネックが発生しないように、30分以内にそれらを好転させることができます。

それらから始めることをお勧めします。コードレビューの提出プロセスを定義し（TFSを使用している場合はかなり乾燥している）、チェックインする前に変更セットの提出に専念します。認識のみを目的としており、コードを批判する人はいないことを伝えます。

認知度レビューを1〜2回繰り返した後、チームの他のメンバーを招待して、互いのコードをレビューします...認知度を高めるためだけに。信じられないかもしれませんが、これだけでもチームの結束とコードの均一性に役立ちます。

チーム全体を関与させると、開発者はお互いのコードについて提案することに抵抗することができないことに気付くでしょう。それは自然かつ有機的に起こります（エンジニアは自分自身を助けることはできません！）チームにこれについて話し合い、建設的なフィードバックを互いに提供するためのガイドラインを考えさせます。次に、それらを設定します。おめでとうございます、これで完全なコードレビューモードになりました！

レビューを紹介する良い方法はありますか？

チームやレビューから得たい利点に応じて、おそらくいくつかの良い方法がありますが、どのアプローチにも共通の機能があります。

• 期待することを説明する：これはチームの新しいプロセス、または少なくとも既存のプロセスの変更であるため、変更を開始する理由、チームに利益をもたらす方法をチームに知らせることは公平です。それが機能しているかどうかを知る方法。

• プロセスの定義：コードの確認、変更の議論などのためにフォローするプロセスを人々に説明し、チームの全員が進め方を理解できるようにします。

• 基準を定義する：改善が必要であると人々が呼びかけるべきではない種類の変更をレイアウトします。たとえば、バグや重要なパフォーマンスの改善は指摘するのに適しています。コーディング標準、可読性、および保守性の問題に注意する必要がありますが、それについては検討しません。個人的な好みやスタイルの問題はそのままにしておくべきです。

• 行動について話し合う：目標はコードを改善し、チームが全面的により良いコードを書くのに役立つ共通の理解を促進することであることを指摘します。いくつかの基本ルールを敷くと、コードをレビューすることに関する不安を和らげるのに役立ちます。

• 一番ホットな席に座りましょう：個々のレビューやグループのレビューを計画するかどうかに関係なく、最初の数人をグループとして体験することをお勧めします。他のチームメンバーがプロセスがそれほど悪くないこと、そしてあなたが自分でそれを進んで進んでいくことができるように、最初のレビューはあなた自身のコードのものでなければなりません。

キックオフミーティングを開催して、上記のすべてを説明し、チームメンバーの懸念に対処します。プロセスを文書化した電子メールでフォローアップします。

チームから大きな不本意を感じています。それはもう1つのことであり、会話が苦痛になる可能性があるからです。

これらは2つの明確な懸念事項です。レビューが役立つと思われる場合は、スケジュールを立ててレビューを行う必要があります。チームメンバーは、レビューが他のタスクと同じように機能することを理解し、同じレートで他のタスクを完了し続ける間に追加の作業を行う必要がないことを確認してください。

グループレビュー会議は、議論を進め、会議の長さを制限し、物事を建設的にするファシリテーターが主導する必要があります。それは痛みを伴う会話の回避に大いに役立つはずです。個々のレビューを開始する準備が整うまでに、チームは物事を建設的に保つのに役立つ行動を採用することを望んでいます。

また、レビュープロセスをときどき確認する必要があります。プロセスを議論するために、チームを頻繁に集めてください。それがどの程度うまく機能しているか、どのように改善できるか、どのプラクティスを放棄すべきかなどです。

その方法の1つは、各スプリントの後にコードレビューセッションを実施し、チームの全員が参加できるようにコードが何らかの大きな画面に投影される全員の変更を通過することです。改善点は技術的な負債としてバックログに追加できます。

このアプローチは機能しますが、完璧ではありません。

最終的な目標は、プルリクエストを使用してコードをマスターにマージするか、コードの各行を確認する必要があるブランチを開発することです。