ジュニアプログラマーは、シニアプログラマーのプロジェクトのコードレビューアとして関与する必要がありますか？
私のチームメンバーの1人であるジュニアプログラマーは、彼のレベルの経験に対して印象的なプログラミングスキルを持っています。
そして、コードレビューの間、私は間違いを指摘するのではなく、学習を強調することを信じています。
しかし、ジュニアプログラマーは、より上級のプログラマーのコードレビューに関与すべきでしょうか。または、コードレビューは、対応する経験を持つプログラマーのみが参加する必要がありますか？
コードレビューの主な目的は、欠陥や潜在的な問題を見つけることです。レビューに必要な参加者は、肩書きや年功序列に関係なく、これらの問題を特定するのに最適な人物である必要があります。
例として、アプリケーションがPython=で開発されており、ジュニアエンジニアがコードを書いたシニアエンジニアよりもPython言語での経験が豊富な場合、そうすると、何かを行う別の方法を指摘するうえで貴重な資産になる可能性がありますが、システム全体についての知識が少なくなる可能性もあります。
ツールとテクノロジーの経験に加えて、アプリケーションドメインの経験も考慮してください。 20年の経験があるが、金融業界で1つか2つしかない人は、金融業界ですべて5年の経験しかない経験の浅い開発者に自分の仕事をレビューしてもらうとよいでしょう。
コードレビュープロセスは、経験の浅いスタッフメンバーを可能な限り観察して参加するように招待することで、コードベースを学習し、質問をして、コードレビューだけでなく、コードレビューで彼らに何が期待されているのかを知るのにも役立ちます。それらが生成するコード。ただし、プロセスにあまり多くの人が関与したくない（コードレビューとその目的を完全にサポートできる人に焦点を当てた）ことはおそらくありません。
これは実際にあらゆる種類のレビューに適用されます-要件、設計、コード...
ジュニアプログラマーは、シニアプログラマーのプロジェクトのコードレビューアとして関与する必要がありますか？
はい、そうすべきです。他の人のコードを読むのは良い学習経験です。 （そしてそれは良いコードと悪いコードの両方に当てはまります。上級開発者のコードが悪くないことを願っていますが...）
onlyの後輩にコードレビューを依頼するのは賢明ではありません。そして、後輩たちに何を見つけることができるかという点で後輩にあまりにも大きな期待をかけるのは賢明ではありません。ただし、ジュニアプログラマーがテーブルにもたらすことができる新鮮な洞察に驚くこともあります。
別の回答は、ジュニアが脅迫されている/感じていると述べました。これは、レビュー対象またはレビュー担当者のどちらにとっても、コードレビューの対象ではありません。それが起こっている場合、あなたのグループはそのコードレビューを行う方法を変更する必要があります...そして恐らく脅迫者を列に入れる必要があります。
「ジュニア」プログラマーが先輩のコードをnot理解できれば、それ自体がコードの優れた尺度になると付け加えます。 OK誰もが理解できるコードを書くことがまったくできない場合があるかもしれませんが、うまくいけばそれらは例外です-1人か2人しかコードを理解できない場合、それらの人が利用できず、問題が発生するとどうなりますか？それ？
人々に新しい挑戦を与えることは彼らが成長するのを助けます。また、誰もがコードをレビューするために切り取られているわけではないかもしれませんが、誰かが（人事部の政治とゲームによって決定されたタイトル）を前に主張することは独断的なようです彼らはレビューを手助けする資格があります。
他の人が指摘したように、コードレビューは双方向のプロセスになる可能性があります。それは誰もがコードベースを理解するのに役立ちますので、知識を共有し、後輩が先輩から新しいより良い方法とテクニックを学ぶのを助けます間違いを見つけます。
コードレビューの目的は、保守性の問題やコーナーケースなど、テストで検出できない問題を検出することです。ジュニアプログラマーは多くの点でbetterがその目的に適していると主張します。
- 彼らは一般的に利用可能なより多くの時間を持っています。
- 彼らは、コードを理解する必要性から、それを行ごとにゆっくりと受け取る可能性が高くなります。
- コードが保守可能であることについて話すとき、それはあなたのトッププログラマーだけでなく、社内の全員が意味することです。つまり、後輩のプログラマーは、コードを保守可能であると宣言するために、コードを理解できる必要があります。
- 彼らはしばしば、悪い仮定をする可能性が低くなり、何かが彼らが機能するはずであると想定する方法で機能すると信頼します。
- プログラミング言語での彼らの教育はより最近のものであり、他の言語での長年の経験と混同される可能性は低いです。たとえば、上級者は、C++から習得した習慣を誤って使用する可能性があります。この習慣は、Javaでは動作がわずかに異なります。ジュニアはこの種のエラーをより簡単に認識します。
- コードレビューアはidentify問題のみを必要とし、必ずしもより良いソリューションを提案する必要はありません。彼らはしばしば「私はそれをより良くする方法を本当に理解することはできませんが、この部分はすべての繰り返しのために本当に混乱しています」という言葉に沿ってコメントをします。経験豊富なプログラマであれば、最初は問題に気づかなかったとしても、簡単に改善できます。
上級プログラマーがレビューを行うのに適している方法は他にないということではありませんが、チームの多様性を十分に活用していない場合、あなたは不満を抱いていると私は言います。
ジュニアはコードを維持するようにしばしば求められます、彼らがそれを理解できることが重要です。
シニア開発者のコードをレビューできるのは、ジュニアだけです。シニアの上司が休暇中なので、コードはQAに行くのを待つ必要がありますか（コードレビューなしでは開発から何もプッシュしないで、このタイプのコードレビューも想定しています）。
私はまた、ジュニアが別のクライアントのために同様のことをすぐに行うとわかっている場合、または彼らが同様の何かに取り組んでいること、または特定のスキルセットを持っていることを知っていた場合、コードレビューを特にジュニアに依頼しました。
コードがかなり単純である場合、私はしばしばジュニアにレビューを依頼します。後輩が仕事をするのに十分な能力を持っているのに、なぜ高齢者の時間を無駄にするのですか？後輩が先輩のコードをレビューすることに脅かされていると感じた場合は、最初に簡単な部分を見てもらいます。結局、怖がる気がなくなるまで、ジュニアになることはできません。
理解できないジュニアにコードを説明しなければならない場合、私が（通常は想定内で）行ったエラーが表示され、コードが実行されるため、経験豊富なコードレビューアーがキャッチしなかったことがよくあります。しかし、意図したとおりには実行されません。そのため、物事を説明するという行為だけで、開発者はコードレビューアーが気付かないうちに問題を見つけることができます。経験豊富な人はコードを一歩一歩進めないことが多いため、これらの種類の事柄は、後輩がレビューをするときに、より簡単に見つけられます。
レビューにジュニアを参加させることには、いくつかの良い効果があることがわかりました。まず、彼らが高齢者のコードを理解できるとき、彼らは彼らをより自信があります。彼らがそのコードのバグを見つけることができるとき、それは彼らをさらに自信にさせます。
それは、彼らを彼ら自身の外の思考プロセスにさらし、物事を処理する他の方法を彼らに見せます。高齢者でさえ、これは私に起こりました-問題を解決する別の方法を見ることは、新しい可能性への目を開くことができます。
それは彼らが他の人のコードを読むことを学ぶのを助け、それが彼らにまだ作者の心の中で新鮮な間にコードが何をしているかを尋ねる機会を与えます。それは、6か月後、作者が長い間行っていないか、別のプロジェクトで忙しくて質問の時間がないときに物事を維持する必要があるよりもはるかに優れています。
質問は、後輩が弱くてメンタリングが必要な潜在的な領域（彼らがより多くの責任を取ることができ、他のタイプのタスクを実行するためにより多くの時間を与えることができる）またはコードが単に明確ではない領域を明らかにするので、それは高齢者にとっては良いことです。著者以外のすべての人（つまり、変更する必要がある場合、1年後の時点で著者にはっきりと分からないこともあります）。それはまた、後輩たちが彼らが存在することについて彼らに信用を与えているよりも賢いかもしれないことを高齢者が認識するのを助けます。それは誰もが専門的な基盤を維持するのに役立ちます。結局のところ、ジュニアを除外した場合、ジュニアが心理的に不幸なコードを理解できるとは思わないことを明らかに暗示しています。
ジュニアがシニアコードをレビューすることで、組織でより専門的な尊敬を生み出すことができます。先輩は後輩を過小評価していることに気づくかもしれません、そして、後輩は先輩が彼らが彼らに与えた以上のものを知っていることに気付くかもしれません。ジュニアは時々彼らが持っているよりも優れたスキルを持っていると思います。彼らが書くことができないコードにさらされていることは、学ぶべきことがたくさんあることに気づき始めるので、これらの人々にとっては良いことです。また、スキルを習得するために彼らの最高のものを刺激します。学校では、Bの生徒は、誰かがAレベルの仕事のサンプルを見せてくれるまで、なぜAをもらえなかったのか理解できないことがあります。コードレビューで後輩から先輩まで同じ。
私の答えはときどきです。プログラマーによって、そしてタスクごとに異なります。
対象：
- これらのジュニアに効果的なコードレビューの方法を学びたい場合は、シニアがそれをどのように行うかを彼らが確認するのが最善の方法です。
- ジュニアプログラマーは、特定の言語/ドメインなどでシニアプログラマーよりも多くの経験を持っている場合があります。
- 後輩に先輩のコードを評価させることによって、彼らは必然的に物事を学ぶつもりです。ジュニアプログラミングの質問はすぐに答えが得られるため、ペアプログラミングはより効果的な方法です。
- 誰のコードも神聖なものではありませんし、コードがレビューされるべきではないほど優秀な人もいません。これを行わない場合、誰があなたのトップガイのコードをレビューしますか？
- すべての後輩が同じであるわけではなく、すべての先輩が同じであるとは限りません。時々ギャップがあまりない場合があるので、役職にこだわらないでください。
反対：
- 後輩からの非問題でレビューが行き詰まるリスクがあります。
- 必要な知識/スキルのレベルは、単にジュニアの能力を超えているかもしれません。これは彼らの時間を浪費するだけでなく、おそらく彼らも士気を低下させるでしょう。
チームの全員がコードレビューの両側に関与するべきだと私は強く信じています。ジュニアはシニアコードを確認し、逆も同様です。なぜ両方？通常、コードが「問題を解決する」かどうかだけが問題ではないためです。コードの一部を誰かに説明しなければならなかった回数を説明できず、突然、説明の終わりまでに、より優れた方法を思いついた。コードレビューはおそらく3つの目的を果たします：
- コードが正しいことを確認してください
- 他の人が自分のコードをどのように見るかについてライターに考えさせる
- 改善できる点と一般的な2つ目の目についての読者のフィードバックを得る
私はジュニアであり、私は一般的にシニアが書いたコードをレビューします。これは、「すべてが誰かによってコードがレビューされる」という会社の一般的なポリシーです。これらのコードをレビューし、なぜ物事が特定の方法で行われるのかについて質問する機会があることから、私は多くを学びます。そして時々、私は特定のコードなどを行うためのより明確な方法を提案します。コードを改善する方法を教えてくれる人よりもはるかにまれですが、少なくとも1回は発生しました。
また、コードレビューがいかに正式であるかが重要です。私たちのものは非常に非公式であり、キュービクル全体またはプライベートIRCチャネルで言われている「ちょっと私のコードを見てください」で構成されています。より正式な設定でコードをレビューすると、後輩はおそらく、先輩のコードを見直すことについてはるかに恐れ入ります。
ジュニアプログラマーは、上級の同僚のためにコードレビューを絶対に行う必要があります！
ただし、それらが唯一のレビュアーであってはなりません。コードレビューごとに、経験豊富な開発者とペアを組んでください。
無数のメリットがあります。
作者は彼らのコードの詳細を説明することを余儀なくされます。あなたのコードを話すことは 最良の方法の1つ 問題を見つけることですそれで、またはそれを行うためのより良い方法。
作者はコードに弱点を見つけるでしょう。ジュニア開発者は、より高度なチャンクのいくつかによって混乱する可能性が高くなります。多くの場合、これらはそれ自体が「トリッキーすぎる」ため、単純化することでメリットが得られる可能性があります。
ジュニア開発者は、より優れたコーディングプラクティスを学びます。コードレビューは、例として教える機会です。
ジュニア開発者はより効果的なコードレビューアになります。コードレビューはhardです。誰もがコードレビューに精通しているほど、コードレビューはより速く、より効果的になります。
ジュニア開発者は、コードベースの深い知識を持っています。利己的です！ジュニア開発者を早く引き抜くことで、より早く彼らにそれを渡すことができます。
ジュニア開発者は、より関与しているように感じます。ジュニア開発者は、「シニア」コード（およびその同僚）を外国人ではなく、威圧的ではないと見なし始めます。これは、コードレビューの大きな見逃されがちなメリットです。
ジュニア開発者は新鮮な目です。長期間コードベースに取り組んでいる人ほど知識が豊富ではありません。 。ジュニア開発者は、質問をするときに、達成するためのさまざまな方法を指摘する可能性が高くなります。 少なくともいくつかの考慮なしに彼らのワイルドなコメントをすくめてはいけません！
上級開発者は説明責任を負います。私は、上級開発者がお互いのコード（信頼、怠惰など）を覆いがちになる状況をよく見ました。目の追加のセットは、それを思いとどまらせるのを助けます。
考慮すべき欠点は、関係するすべての関係者がコードレビューの実行にかなりの時間を費やすことです。したがって、それは経営者への販売が少し難しい場合があります。ただし、メリットは遅いペースを完全に上回ります。
絶対に、ジュニアエンジニアは、少なくともある程度は、シニアエンジニアのコードを確認する必要があります。
私の経験では、1対1のコードレビューのレビュー担当者が、レビュー担当者が上級または後輩であるかどうかにかかわらず、元のコーダーが実際に見落としているエラーを実際に目にすることは非常にまれです。レビュアー 人間である必要はありません 。一方、元のコーダーがコードを説明しようとしているときに間違いを認識していることは非常に一般的であり、レビュアーが若いほど、説明の深さが必要であるため、そうなる可能性が高くなります。
私の意見では、コードレビューの見落とされがちな利点のいくつかは、エラーをキャッチすることよりも長期的には重要である可能性があります。
- コードベースで実際に何が行われているのかについての知識の共有-「ちょっと、BillはXを実行するクラスを持っていたと思うので、新しいクラスを書く必要はありません。」
- 優れたテクニックとプログラミングスタイルの知識を共有する。
これらの側面の両方で、ジュニアレビューアーはシニアレビューアーよりも多くの利益を得る傾向があります。
コードレビューは、学習用ではなくコードのレビュー用に作成されます。私がジュニアプログラマだったとしたら、私はシニアのコードを復習することを恐れます。
一方、シニアがすべての質問に答えることができる場合、シニアのコードを読むことは学習の素晴らしい方法です。
次の2つの選択肢があります。
- ジュニアにコードレビューミーティングに参加してもらい、すべてのアテンダントが教育/学習の議論に参加できるようにする
- ペアプログラミングの練習