ジュニアプログラマーは、シニアプログラマーのプロジェクトにコードレビューアとして関与すべきですか？

私のチームメンバーの1人であるジュニアプログラマーは、彼の経験レベルに対して優れたプログラミングスキルを持っています。

また、コードのレビュー中に、間違いを指摘するのではなく、学習を重視することを信じています。

しかし、若いプログラマーは、より上級のプログラマーのコードレビューに関与すべきでしょうか？または、コードレビューには、対応する経験を持つプログラマーのみが参加する必要がありますか？

コードレビューの主な目的は、欠陥または潜在的な問題を見つけることです。レビューに必要な参加者は、肩書きや年功に関係なく、これらの問題を特定するのに最も適した人でなければなりません。

例として、アプリケーションがPythonで開発されており、ジュニアエンジニアがコードを書いたシニアエンジニアよりもPython言語の経験が豊富な場合、それらは何かをするための代替方法を指摘する貴重な資産かもしれませんが、システム全体の知識が少ない場合もあります。

ツールとテクノロジの経験に加えて、アプリケーションドメインの経験も考慮してください。20年の経験があるが金融業界で1つか2人しかいない人は、金融業界で5年しか経験していない経験の浅い開発者に仕事をレビューしてもらえるかもしれません。

経験の浅いスタッフができる限りコードレビュープロセスを観察し、参加するように招待することは、コードレビューを行うだけでなく、コードベースを学び、質問をし、彼らに期待されることを学ぶのに役立つかもしれません彼らが生成するコード。ただし、プロセスに関与する人が多すぎないようにする必要があります（代わりに、コードレビューとその目的を完全にサポートできる人に焦点を合わせます）。

これは本当に、あらゆる種類のレビューに当てはまります-要件、設計、コード...

ジュニアプログラマーは、シニアプログラマーのプロジェクトのコードレビューアとして関与すべきですか？

はい、そうすべきです。他の人のコードを読むことは良い学習経験です。（そして、それは良いコードと悪いコードの両方に当てはまります。上級開発者のコ​​ードが悪くないことを願っていますが...）

明らかに、ジュニアのみがコードレビューを行うのは賢明ではありません。そして、彼らが見つけることができるという点でジュニアにあまりにも高い期待をかけるのは賢明ではありません。ただし、ジュニアプログラマーがテーブルにもたらすことができる新鮮な洞察に驚かれるかもしれません。

別の回答では、ジュニアは/脅迫されていると感じています。これは、コードのレビューがレビュー対象者また​​はレビュー担当者のどちらにとっても重要なことではありません。それが起こっている場合、あなたのグループはコードレビューを行う方法を変更する必要があります...そして恐らく脅迫者を列に入れる必要があります。

「ジュニア」プログラマーが高齢者のコードを理解できない場合、それ自体がコードの適切な尺度であると付け加えます。誰でも理解できるコードを書くことができない場合もあるかもしれませんが、うまくいけばそれらは例外です-コードを理解できるのが1人か2人だけなら、その人が利用できず、問題がある場合はどうなりますかそれ？

人々に新たな挑戦を与えることは、彼らの成長を助けます。また、コードをレビューするために全員がカットされるわけではないかもしれませんが、誰かがレビューを支援する資格を得る前に、タイトル（HRの政治とゲームによって決定される）を主張することは独断的に思えます。

他の人が指摘したように、コードレビューは双方向のプロセスになる可能性があります。それは誰もがコードベースを理解するのに役立つので、知識を共有し、後輩が高齢者から新しいより良い方法と技術を学ぶのに役立ち、高齢者が理解を磨き、誰もがあなたがより多くの目を持つことができるコードに従うことができるように書くことによって役立ちますミスをキャッチします。

コードレビューの目的は、保守性の問題やコーナーケースなど、テストでは検出できない問題を検出することです。私は多くの点で、ジュニアプログラマーがその目的により適していると主張します。

• 一般的に、より多くの時間を利用できます。
• 彼らはコードを理解するために不必要にゆっくりと、一行ずつそれを取る可能性が高いです。
• コードを保守可能にするということは、トッププログラマだけでなく、社内の全員が意味します。つまり、ジュニアプログラマーは、保守可能と宣言するためにコードを理解できる必要があります。
• 彼らはしばしば、悪い仮定をする可能性が低く、何かが機能するはずであると想定する方法で機能すると信じています。
• プログラミング言語での彼らの教育は最近のものであり、別の言語での長年の経験と一緒に混乱する可能性は低いです。たとえば、シニアは、C ++から選んだ習慣を誤って使用する場合があります。この習慣は、コンパイルされますが、Javaでは微妙に動作が異なります。ジュニアは、これらの種類のエラーをより簡単に拾います。
• コードレビューアは問題を特定するだけでよく、必ずしもより良い解決策を提案する必要はありません。多くの場合、「どうすればもっとうまくやれるかわかりませんが、この部分は繰り返しのせいで本当に紛らわしいです」という線に沿ってコメントをします。経験のあるプログラマであれば、最初は問題に気付いていなくても、簡単に改善できます。

それは、上級プログラマーがレビューを行うのに適している他の方法がないと言うことではありませんが、私のポイントは、チームの多様性を十分に活用していない場合、あなたは損害を与えているということです。

ジュニアはしばしばコードを維持するように求められますが、彼らがそれを理解できることが重要です。

上級開発者のコ​​ードをレビューできるのは、ジュニアだけである場合があります。シニアの上司が休暇中のため、コードはQAに行くのを待つべきです（コードレビューなしで開発者から何かをプッシュすることはなく、このタイプのコードレビューも想定しています）。

また、他のクライアントのために似たようなことをすぐに行うとわかったとき、または似たようなまたは特定のスキルセットを持っている他の何かに取り組んだことがわかっている場合、ジュニアに何かをコードレビューするように具体的に依頼しました。

コードがかなり単純な場合、私はしばしば下級者にレビューを依頼します。なぜ後輩が仕事をすることができるのであれば、高齢者の時間を無駄にするのでしょうか？ジュニアがシニアのコードをレビューすることで脅迫されていると感じた場合は、最初に簡単な部分を見てもらいます。結局、あなたは、あなたが脅迫されるのをやめるまで、後輩であることを超えて行くことができません。

コードを理解していない後輩にコードを説明しなければならない場合、私が犯したエラーが表示されることがよくあります（通常は仮定で）。しかし、意図したとおりに正確には行いません。そのため、開発者は問題を説明するだけで、コードレビュー担当者がそれを見つけなくても問題を見つけることができます。より経験豊富な人はコードを段階的に理解することはあまりないので、これらのタイプのものは後輩がレビューをするときにもっと簡単に見つけられます。

後輩がレビューに関与することには、いくつかの良い効果があると思います。まず、高齢者のコードを理解できると、自信がつきます。そのコードのバグを見つけることができれば、さらに自信が持てます。

それは彼らに彼ら自身の外側の思考プロセスにさらし、物事を処理する他の方法を見ることができます。高齢者としても、これは私に起こりました-問題を解決する別の方法を見ることは、新しい可能性に目を開かせることができます。

他の人のコードを読むことを学ぶのに役立ち、作成者の心にまだ新しいうちにコードが何をしているのかを尋ねる機会を与えます。作成者がもういなくなったり、別のプロジェクトで忙しくて質問の時間がないときに、6か月後に物を維持するよりもはるかに優れています。

質問は、ジュニアが弱く、メンタリングを必要とする可能性のある領域を明らかにするため（シニアはより多くの責任を負い、他のタイプのタスクを行うためにより多くの時間を与えることができる）、またはコードが単に明確ではない領域著者以外のすべての人（つまり、変更が必要になるのは1年後の著者にとっても明確ではないかもしれません）。それはまた、高齢者が、彼らが存在しているという信用を与えているよりも賢いかもしれないことを認識するのに役立ちます。全員がプロとしての立場を保つのに役立ちます。結局、ジュニアを除外する場合、あなたは彼らが心理的に不幸なコードを理解できるとは思わないことを明確に暗示しています。

シニアコードを確認するジュニアは、組織内でより専門的な敬意を払うことができます。高齢者は、彼らが後輩を過小評価していることに気付くかもしれませんし、後輩は彼らが彼らに信用を与えた以上のことを知っていることに気付くかもしれません。ジュニアは、自分が持っているよりも優れたスキルを持っていると思うことがあります。書くことができないコードにさらされることは、学ぶべきことがもっとあることに気づき始めるので、これらの人々にとって良いことです。また、スキルを習得するために彼らのベストを駆り立てます。学校では、Bの生徒は、誰かがAのレベルの仕事のサンプルを見せない限り、なぜAにならないのか理解できないことがあります。コードレビューのシニアからジュニアまでと同じです。

私の答えは：時々です。プログラマーごとに、そしてタスクごとに異なるでしょう。

ために：

• これらの後輩に効果的なコードレビューを行う方法を学習させたい場合、最良の方法は、先輩がどのようにそれを行うかを確認することです。
• ジュニアプログラマーは、特定の言語/ドメイン/などの上級プログラマーよりも経験が豊富かもしれません。
• 後輩に先輩のコードを評価するように強制することで、彼らは必然的に物事を学びます。しかし、ペアプログラミングはこれを行うためのより効果的な方法になるでしょう。なぜなら、後輩が持っているどんな質問でもすぐに答えを得ることができるからです。
• 誰のコードも神聖ではなく、誰もコードをレビューしてはいけないほど優秀ではありません。これをしないと、誰がトップのコードをレビューするのでしょうか？
• すべての後輩が平等というわけではなく、すべての先輩が平等というわけでもありません。ギャップがあまりない場合があるため、役職にとらわれないでください。

に対して：

• レビューが後輩からの非問題で行き詰まってしまうリスクがあります。
• 必要な知識/スキルのレベルは、単に後輩の能力を超える場合があります。これは時間を浪費するだけでなく、恐らく彼らの士気を低下させます。

私は、チームの全員がコードレビューの両側に関与すべきだと強く信じています。ジュニアはシニアコードを確認し、逆もまた同様です。なぜ両方？通常、コードが「問題を解決する」かどうかだけではありません。コードを誰かに説明しなければならず、説明の終わりまでに突然より良い方法を思いついた回数をあなたに伝えることはできません。コードレビューは、おそらく3つの目的を果たします。

1. コードが正しいことを確認してください
2. 他の人が自分のコードをどのように見るかを作家に考えさせます
3. 何が改善される可能性があるかについての読者のフィードバックと、一般的な2番目の目を取得する

私はジュニアであり、よく上級の書かれたコードをレビューします。これは一般的な会社のポリシーです。これらのコードをレビューし、特定の方法で物事が行われる理由について質問する機会があることから、私は多くのことを学びます。そして時々、特定のコードなどを実行するよりクリーンな方法を提案します。私のコードを改善する方法を教えてくれる人よりもはるかにまれですが、少なくとも一度は起こりました。

また、コードレビューがいかに正式であるかが重要です。私たちは非常に非公式で、キュービクル間またはプライベートIRCチャンネルで「私のコードを見てくれ」と言われています。もっとフォーマルな設定でコードをレビューすると、ジュニアはおそらくシニアのコードのレビューについてもっと深く考えていると想像できます。

絶対に、ジュニアエンジニアは、少なくとも時々、シニアエンジニアのコードを確認する必要があります。

私の経験では、1対1のコードレビューのレビュー担当者が、レビュー担当者がシニアであるかジュニアであるかに関係なく、元のコーダーが見逃しているエラーを実際に見ることはほとんどありません。レビューアは人間である必要さえありません。一方、非常に一般的なのは、元のコーダーがコードを説明しようとしているときに間違いを認識し、レビュー担当者が後輩であるほど、説明の深さが必要なためです。

私の意見では、エラーをキャッチするよりも長期的にはおそらくより重要なコードレビューの利点を見落としがちです。

• コードベースで実際に行われていることに関する知識を共有します-「待って、ビルはXを実行するクラスを持っていたと思うので、新しいクラスを書く必要はありません」。
• 優れたテクニックとプログラミングスタイルの知識を共有する。

これらの両方の側面において、ジュニアレビュアーはシニアレビュアーよりも利益を得る傾向があります。

ジュニアプログラマーは、上級同僚のために絶対にコードレビューを行うべきです！

ただし、彼らだけがレビューアであってはなりません。コードレビューごとに、経験豊富な開発者とペアにしてください。

無数の利点があります。

• 著者は、コードの詳細を説明することを余儀なくされます。 コードを介して話すことは、それに関する問題を見つけるための最良の方法、またはそれを行うためのより良い方法の1つです。

• 著者は、コードに弱点を見つけるでしょう。 ジュニア開発者は、いくつかのより高度なチャンクによって混乱する可能性が高くなります。多くの場合、これらはそれ自体が「トリッキー」であり、単純化の恩恵を受ける可能性があります。

• ジュニア開発者は、より良いコーディングの実践を学びます。 コードレビューは、例によって教える機会です。

• ジュニア開発者は、より効果的なコードレビューアになります。 コードレビューは難しいです。誰もがコードレビューを経験するほど、コードレビューはより速く、より効果的になります。

• ジュニア開発者は、コードベースのより深い知識を持っています。 わがままです！ジュニア開発者を早期に引き寄せることで、より早く彼らに引き渡すことができます。

• ジュニア開発者はより複雑に感じます。 ジュニア開発者は、「シニア」コード（およびその同僚）を、より異質で威圧的なものとして見始めるでしょう。これは、コードレビューの大きな利点であり、見落とされがちです。

• ジュニア開発者は新鮮な目のセットです。 彼らは長い間コードベースに取り組んでいる人ほど教化されていません。ジュニア開発者は、質問をするときに物事を達成するさまざまな方法を指摘する可能性が高くなります。 少なくともいくつかの考慮なしに、彼らのワイルドなコメントを無視しないでください！

• 上級開発者には説明責任があります。 私は頻繁に、上級開発者がお互いのコード（信頼、怠inessなど）を片付ける傾向がある状況を見てきました。余分な目のセットはそれを落胆させるのに役立ちます。

考慮すべき欠点は、関係者全員がコードレビューの実行にかなりの時間を費やすことです。したがって、それは経営陣にとって少し難しい販売になる可能性があります。ただし、ペースは遅いペースを完全に上回ります。

コードレビューは、学習ではなくコードのレビューのために行われます。私がジュニアプログラマーだった場合、シニアのコードをレビューすることを恐れます。

一方、シニアのコードを読むことは、シニアがすべての質問に答えることができるという条件で、素晴らしい学習方法です。

次の2つの選択肢があります。

• ジュニアはコードレビュー会議に参加し、すべての出席者はいくつかの教育/学習の議論に開放されます
• ペアプログラミングの練習