コードレビューを徐々に導入する方法は？
私は半ダースの上級エンジニアとチームを率いています。標準的な理由でコードレビューを行うことは非常に有益だと私は信じています。必ずしもすべての変更ではありませんが、少なくともバックグラウンドレビューの安定した流れ。したがって、人々は少なくとも他人の変化を見て、それらについて話し始めます。
レビューを紹介する良い方法はありますか？あと1つやるだけなので、チームには大きな抵抗があり、会話が面倒になることがあります。少なくとも最初のステップとして、すべての変更を確認することは重要ではありません。量を増やす前に、まず低周波でレビューを行うリズムと実践に慣れてほしい。
誰かがコードレビューを徐々にうまく導入しましたか？どうやって？私は「ホット」なファイルやライブラリのレビューを要求することについて考えています。またはランダムに選択します。または、「選択」する必要のあるレビューの変更を選択します。または思い切ってすべての変更を行うことが唯一の方法ですか？
これは、ツールやプロセスの問題ではありません。文化についてです。あなたは、批判に敏感で自分の仕事を保護する人々で構成されるチームについて説明します。 veryは非常に一般的です。しかし、それは専門家ではありません。
私のアドバイスは、模範を示すことから始めることです。確認のためにコミットを提供します。人々があなたのアプローチの問題を強調するように要求することについてオープンであること。フィードバックを受け入れる。防御的な態度をとらず、代わりにフィードバックの背後にある理由を探り、チームとしての行動に同意します。開かれた対話の雰囲気を奨励します。これを喜んで行うチャンピオンをチームで1人または2人見つけます。
それは大変な仕事だ。
最初のステップは、誰かに近づいて「コードを確認してくれませんか？」と言うことです。組織で見たい変化を作りましょう。あなたがそうする意志のある個人を見つけることができない場合、あなたはチーム全体を説得することができません。 2人がある程度成功した場合は、チームに報告してください。
あなたのコードをレビューする人を見つけたら、あなたがtheirコードのいくつかをレビューしてもよいかどうか尋ねてください。 themがコードを改善する機会ではなく、yoの学習機会としてそれをフレーズしてください。
チームリーダーとして、コードレビュープロセスから得られる最大の価値はawarenessで何が行われているのかです。開発者に変更や提案がない場合でも、すべての変更セットを見る機会を得たいと思います。私はこれらを「アウェアネスレビュー」と呼んでいます。ボトルネックが発生しないように、30分以内で向きを変えることができます。
それらから始めることをお勧めします。コードレビューの提出プロセスを定義し（TFSを使用する場合はかなり削減され、乾燥します）、チェックインの前に全員（およびあなたのみ）にチェンジセットの提出を依頼してください。それは認識のためだけであり、誰も彼らのコードを批判するつもりはないことを伝えます。
アウェアネスレビューを1、2回繰り返した後、チームの他のメンバーを招待して、お互いのコードをレビューしてもらいます。信じられないかもしれませんが、これだけでも、チームの結束とコードの統一に役立ちます。
チーム全体を関与させると、おそらく、開発者はお互いのコードについて提案することに抵抗できなくなるでしょう。それは自然にそして有機的に起こります（エンジニアは自分自身を助けることはできません！）チームにこれについて話し合ってもらい、お互いに建設的なフィードバックを提供するためのガイドラインを考えさせます。次に、それらに設定します。おめでとうございます。これで完全なコードレビューモードになりました！
レビューを紹介する良い方法はありますか？
チームやレビューから得たいと思っているメリットに応じて、おそらくいくつかの良い方法がありますが、どのアプローチにもいくつかの共通の機能があります。
期待することを説明してください：これはチームの新しいプロセス、または少なくとも既存のプロセスへの変更なので、変更を導入する理由、方法をチームに知らせるのは公正ですチームの利益を期待し、それが機能しているかどうかをどのように知るか。
プロセスを定義する：コードのレビュー、変更のディスカッションなどのためにフォローしてもらいたいプロセスを人々に説明し、チームの全員が方法を理解できるようにします続行します。
基準を定義します：改善が必要であると人々が指摘する必要がある、またはすべきでない変更の種類をレイアウトします。たとえば、バグやパフォーマンスの大幅な改善は指摘に値します。コーディング標準、可読性、保守性の問題に注意する必要がありますが、詳しく説明する必要はありません。個人的な好みやスタイルの問題は放っておいてください。
ディスカッションの動作：目標はコードを改善し、誰もが困惑したり、スコアを解決したりするのではなく、チーム全体でより良いコードを書くのに役立つ共通の理解を育むことであることを指摘します。批評は客観的である必要があります建設的な、決して個人的なものではありません。いくつかの基本ルールを定めることは、コードをレビューしてもらうことについての不安を和らげるのに役立ちます。
自分を最初にホットシートに配置する：個別のレビューでもグループレビューでも、最初のいくつかをグループとして検討することをお勧めします。最初のレビューは独自のコードで行う必要があります。これにより、他のチームメンバーがプロセスがそれほど悪くなく、自分で進んで進んでいくことがわかるようになります。
上記のすべてを説明し、チームメンバーの懸念に対処するキックオフミーティングを開くことから始めます。プロセスを文書化した電子メールでフォローアップします。
あと1つやるだけなので、チームには大きな抵抗があり、会話が辛くなることもあります。
これらは2つの明確な懸念事項です。レビューが役立つと思われる場合は、スケジュールに時間を組み込んでレビューを行う必要があります。チームメンバーは、レビューが他のタスクと同じように機能することを理解していることを確認してください。同じ速度で他のタスクを完了している間に行う必要がある追加のことではありません。
グループレビューミーティングは、進行中のディスカッションを続け、ミーティングの長さを制限し、建設的なものを維持するファシリテーターが主導する必要があります。それは苦痛な会話を避けるための長い道のりになるはずです。個別のレビューを開始する準備ができているときまでに、チームは自分で物事を建設的に保つのに役立つ行動を採用しているはずです。
また、レビュープロセスを時々レビューする必要があります。チームが頻繁に集まり、プロセスについて話し合う：プロセスがどの程度うまく機能しているか、どのように改善できるか、どのプラクティスを放棄する必要があるかなど。チームにプロセスの所有権と新しいことに挑戦する自由を与える。