ジュニア開発者にコードレビューへの参加を促す方法は？

私は現在、3人の下級者と一緒に上級開発者として働いており、コードレビュープロセスを導入して、生産に入るコードの品質を管理しました。

私たち全員がお互いの作業をレビューすることは非常に有益であると感じていますが、約5週間のプロセスの後、ツール（BitBucket）でコメントをするのは私だけです。

職場には一部文化的な問題があり、コメントが間違っている場合にはおそらく自然な抵抗がありますが、何らかの方法がありますか？

私にとって、ここでの質問は「コードレビューから抜け出すために、ジュニア開発者に何を求めていますか？」です。私にとって潜在的に最も重要なことは、ジュニア開発者がうまくいけば良いコードを見ることで学ぶことです。コードで問題が見つかった場合、それはボーナスです。

コードレビューから学ぶためにジュニアスタッフを探している場合、あなたがしなければならない最も重要なことは、時間の無駄とは見なされず、学習が重視される環境を作ることです。これはいくつかのことを意味します。

• ばかな質問のようなものはありません。誰かが少しのコード、特定のパターンを使用した理由などを理解していない場合、彼らはあなたや他の開発者の時間を無駄にしていると感じることなく、気軽に尋ねる必要があります。
• 学習に費やした時間はよく費やした時間です。後輩の開発者がコードを見て、そこから学ぶことに時間を費やすことを望んでいます。それは将来、彼らをより良く、より生産的なスタッフにするでしょう。今すぐレビューする必要のある重大な修正でない限り、コードレビューに費やす時間を短くするのではなく、増やすように促してください。
• シニアスタッフは常に正しいとは限らない。長い間これをやってきたからといって、あなたが正しいというわけではありません。バグを見つけたと思うなら、おそらく正しいでしょう。このコードに別のデザインパターンが適切であると考えている場合、ネガティブフィードバックを受け取らずに自由にそう言う必要があります。

毎週設定された時間に、コードレビュー会議を直接開催します。私はこれを次のようにチームメイトに売りました（実際、私たちは両方とも上級開発者ですが、何でも）

「コードレビューは部分的にありますので、コードをもう少しよく知り、いつかトラックにぶつかった場合にあなたの側で何が起こっているかを知ることができます。スプリントを終了するように命じられます。そこにあなたのコードを他の誰かに説明するためにあります、あなたがそれをするとき、それはあなたの脳の異なる部分に関与し、しばしば彼らへのあなたの説明、および/または彼らの質問またはコメントはあなたがあなたが忘れた何かを覚えさせるかもしれないのでコード内で実行したり、読みやすくしたり、より適切に設計したりするためのより良い方法を実現する可能性があります。これにより、コードがより美しくなります。」

私はそれをショーアンドテルと考えるのが好きです。人々は自分の仕事を仲間に見せびらかします。それはあなたの同僚があなたの仕事で間違ったことを見つけたということではなく、誰もその気持ちが好きではありません。それはあなたの素晴らしいコードで仲間に感銘を与えることであり、誰もが感じているものです。

しかし、人間との対話、部屋での会議、ホワイトボードがない場所でコードレビューツールを使用すると思います。そのようなツールがあってはならないというわけではありませんが、コードレビュー会議中に、コードの特定のセクションのより詳細なレビューが必要な場合があることに気付いた場合は、これらのツールを使用する必要があります。その後、特定の領域で他の開発者のコ​​ードをレビューするために、ジュニア開発者の1人を割り当てることができます。

良い例を設定することで支援できます。誰かがあなたの過ちを指摘するとき、あなたは防御的になれない 独自のコードでコードレビューを行い、改善点に注意してください。これをチームと共有してください。最終的に、彼らはこれが奨励され、誰もコードにバグを持っていることでoneられることはないことを知るでしょう。

仕事をするということは、あなたの仕事に責任と誇りを持つことを意味します。コードレビューがその一部である場合、コードレビューへの参加を評価に含める必要があります。オンラインディスカッションに参加することがグレードの一部であるオンラインクラスを受講しました。コメントについて詳しく説明する必要があります。「同意する」は受け入れられません。

コードレビューはコードを改善するはずです。状況に応じて、社内で使用するコードを記述した場合、販売数、ユーザーの苦情、またはその他の評価によって測定できます。実際には、コードは何らかの目的を果たしており、チームはその目的をどれだけうまく果たしているかによって測定されるべきです。あなたが決定したものは成功に貢献し、報酬に比例して共有するようになります。

品質の高いコードのリリースに焦点を当てます。目標は、誰もがバグから遠ざかることによって自分自身について気分を良くすることではありません。悪いコードを書きます。悪いコードを修正する必要があります。それが仕事と人生です。私はバグを修正するのが嫌いなので、バグを避けようとします。私は自分の仕事に誇りを持っているので、コードが機能しないと気になります。これらのことを指摘するのに時間をかけなければならないユーザーや他の人にとっては気分が悪く、それを修正したいと思うようになります。

サイドノートとして、建設的な批判を誰も与えたり受け入れたりできない環境がある場合、問題が生じます。

プロセス：誰かが変更をコミットしたい。誰かがレビュー担当者として割り当てられ、変更をレビューします。その後、レビューおよび修正された変更はテストに進みます。

テストで変更で導入されたバグが見つかった場合、作成者と校閲者も同様に責任を負います。

そのため、コメントなしでレビューを行うと、コードが完璧でなければ問題が発生します。