プルリクエストはジュニアをトレーニングする場所です

マスターへのプルリクエストのすべてのコードは、本番環境で使用できるようにする必要があるという概念があります。これは理にかなっており、私の意見では公正な声明です。

ここでの考え方は、PRを作成したら、これをマスターにしたと述べているが、一部のレビュアーがあなたと単に「同意」して、見逃したことを見つけて欲しいということです。

私たちは人間なので、間違いを犯し、他のレビュアーがユニットテストでは見つけられなかった項目を見つけることを期待しています-スペルミス、誤ったjavadocなど。

しかし、プルリクエストは、開発者に何らかのレベルの支援/トレーニングを提供する必要がある場所ですか、そうであれば、どのレベルまでですか？

新しい変更をプッシュするたびに、レビュー担当者は変更を再レビューする必要があります。これは、開発時間からかかり、変更の再レビューを引き起こします。

それでは、プルリクエストではどのくらいのトレーニングが予想され、許可されるべきですか？私の一部は、それがジュニアからシニアまで変化すると感じます。しかし、それはジュニアにとってさえ、膨大な量の問題を見つけるための場所ではないはずだとも感じています。

開発者に「私のプルリクエストは本番環境で使用できるようにする」という目標を達成させるために苦労している人はいますか？

いいえ。プルリクエストはトレーニングの場所ではありません。あなたのチームは正しい考えを持っています。PRは、「行ってよかったと思います。何かを見逃した場合に備えて、これに2つ目の目を向けてもらえますか。結局、私は人間です。」そして、それがまさにあなたの見習いがしていることだと思います。彼らは正直に行くのが良いと思っています。

これは極端なアイデアです（しゃれが意図されています）。あなたに胸焼けを与えている見習いとペアプログラム。より上級のチームメンバーとして、彼らを持ち上げて生産的にするのはあなたの仕事です。

チームのコアデザイン原則または標準に違反するコードがプルリクエストステージに到達した場合は、そのコードで間違いなく対処する必要があります。また、コードレビューは、チームの標準と設計プラクティスを伝達するための優れた手段となります。

しかし、それは最高の場所ですか？私がそうしないと思う理由はいくつかあります：

1. 基本的な設計上の欠陥や大規模な問題に対処するためにコードレビューを何度か繰り返す必要がある場合は、レビューの締め切りや一般的な枯渇により、上記のより小さな問題を見落とす強い誘惑が生じます。理想的には、チームはこの誘惑に抵抗するのに十分な回復力を備えているでしょうが、それを引き起こすような状況を作らないことがおそらく最善です。
2. 多数のコメントを含むコードレビューを受け取ることは、ジュニア/新入社員の開発者にとっては素晴らしい経験ではありません。はい、フィードバックに応答することは開発に必要なスキルですが、開発者が必ずしも好きではないコードに巧みに対応することに長けているわけではないことも事実です。

より大規模なフィードバックを行うには、ペアプログラミングとデザインレビューが望ましい場所です。

とはいえ、コードレビュー中にコードへの対処が「間違っている」ことを恐れてコードを通過させることはさらに悪いことであり、これが可能な最善の状況（たとえばリモートチーム）があるかもしれません。その場合は、コードレビューで問題に対処し、開発プロセスでこれまでに得た問題にも対処してください。

プルリクエスト中に問題を見つけることは理想的ではないかもしれませんが、テストや本番の問題よりも確かに優れています。

プルリクエストだけが人々を訓練する唯一の場所ではないので、私はそれをもっと言います。また、プルリクエストでトレーニングが必要になるのは、ジュニア開発者だけではありません。請負業者、オープンソースの貢献者、ローカルのコードや標準に不慣れな他の部門の開発者、そしてベテランのプログラマーでさえ、満足するときは時々通知が必要です。

しばらくプルリクエストを開いたままにしておくコストはほとんどありません。好きなだけ多くの人が好きなだけフィードバックを提供し、マージの準備ができたと著者が再度通知するまでそのままにしておきます。プルリクエストは、コードの変更案が完全に準備されているか、多くの作業が必要かを問わず、提案されたコードの変更について連絡するための優れた中心的なツールです。

一部のプルリクエストのレビューはゴム印に過ぎませんが、チームへの外部からの提出であるものは、1か月前後かかる場合があります。最初の種類は入手できればいいのですが、それは、2番目の種類が価値がないという意味ではありません。常に完璧なプルリクエストを送信してもらうことは、誰にとっても苛立たしいことです。

私は常に、優れたリードの特徴の1つは、各開発サイクル中に必要に応じて追加のトレーニングを提供する人物であると感じていました。私にとって、それは自分でコーディングしたりコードをレビューしたりするだけでなく、より若い開発者たちと一緒にプログラミングを組み合わせて、私が踏んだような地雷を回避できるようにすることを意味します。

主に、私たちの主な目標が教育であるという幻想はありません-そうではありません。あなたがシニア、リード、ジュニアのいずれの開発者であっても、目標はあなたの啓発ではありません。目標は常に高品質のコードを顧客に提供することです。できれば、時間通りに、予算通りに、彼らがやりたいことをする。しかし、私がすべての作業を自分で完了することは不可能であることを認識しています。そのため、チームの成功を支援するすべての人を助けるためのリードとして私に責任があります。そして、それは、彼らが自然に現れるときに訓練の機会を認識することを意味します。

したがって、プルリクエストがジュニアのトレーニングの場所であるかどうかについてのあなたの質問に対して、私はこれらの間に教えられる瞬間が発生することは珍しくないと言わざるを得ません。ねえ、あなたはあなたの最初のマージ競合に対処する必要があるでしょう、レビューの後でそれを見てみましょう。ああ、DAOのユニットテストは含まれていません。これらの新しいメソッドをカバーする機会が見つかるまで、レビューを延期します。この財務計算でBigDecimalsよりもダブルプリミティブを使用する方が良いと思いましたか？ええ、それは本当に珍しいことではありません。

ですから、確かにそれは起こり得ると言いますが、それは明らかにプルリクエストの主な目的ではありません。また、プルリクエストのコードが本番環境に対応していることを期待しているとは思いません。多くの場合、そうではありません。

gitflowスタイルの分岐戦略で機能ブランチとリリースブランチを使用している場合、プルリクエストはリリース候補のようなものになります。生産準備はできていませんが、より近似的なものです。あなたはコードがコンパイルされていることを知っており（右）、ユーザーストーリーの目標を満たしていると適切に主張するのに十分なテストcovfefeを持っています。また、開発環境ですでにいくつかの統合テストを実行しているので、PRのレビュー中に変更をデモンストレーションするように求められたら、すぐに使えるデモがあります。

結局のところ、私たちはPRのレビュー中に支援を提供する必要があると感じていますが、その支援は一般的なコーディングに関するものではありません。代わりに、提案されたコードを運用品質のコードの作業ベースに含めるための準備に関連しています。PRは、開発者がPRに含めた各変更の正当化と確実な把握を実証する機会です。そして、それでも-単体テスト、デモ、および大量の質問でそれらを比較検討した後でも-提案された変更が本番環境で準備できているとはまだ予想されていません。

結局、コードは終わりです。しかし、それからQAにそれを拷問させます。

皆の貢献に感謝し、このトピックについて人々が何を言わなければならないかを理解する手助けをしたいと思います。

これは、フィードバックを受け取った後の私の答えであり、受け取った回答とコメントに基づいた私の理解です。みんな、ありがとう。

概要

• コウモリの完全なプルリクエストを期待したり強制したりしないでください。これは関係者全員にとって苛立たしいことになるだけです。
• しかし、引き続き完璧なプルリクエストの目標にします。
• 期待していくつかのプル要求にコラボレーション/アシスト量を。結局のところ、それがプルリクエストを作成することによって基本的に要求することです。
• 設計上の欠陥や実装上の欠陥が原因で多少問題が発生した場合は、その開発者と時間を費やしてペアプログラミングを行い、それらを構築してコードを目標に近づけます。これは、すべての上級開発者の役割です。
• ジュニアは、中間の開発者よりも多くのペアプログラミングセッションが必要になります。したがって、プルリクエストはその要件を反映するものと期待してください。
• プルリクエストで特定されたやり直しを減らすために、コードに触れる前に設計/実装ミーティングを行うことを開発者に奨励します。

テクニカルチームの観点から、会社の文化について詳しく教えてください。開発者がメインラインに統合したいときにコードを本番環境に準備するという考えに苦労している場合、開発者に何を本当に伝えていますか？あなたは彼らの仕事が「完了」したとき、それがうまくいかなくても大丈夫だと彼らに言っていますか？システムが壊れても大丈夫ですか？彼らが技術的負債を追加している場合、それを正当化でき、何をしているのかを認識でき、後で戻ってリファクタリングを実行できることを示していれば、それで問題ないかもしれません。しかし、彼らがなぜ危険なことをしているのか気づいていない場合、何回通過させるつもりですか？

ジュニア開発者の場合、最初のいくつかのプルリクエストには明らかに問題があります。結局、彼らはそれのこつを得るべきです。彼らがまだ問題を抱えていることに気づいたら、あなたは彼らがまだ準備ができていない仕事を彼らに割り当てるかもしれませんか？

または、代わりのジュニアを雇って、それを理解できなかったジュニアを解雇する必要があるかもしれませんか？

私が見たことを知っていますか？有能な開発者ではない人々は、縁故主義のために何年も会社で働き続けます。したがって、もちろん、それらのプルリクエストには複数のレビューが必要です。リーン用語では、それらは「無駄」であり、チームへの抗力であり、最終的には抗力です。

したがって、自分で決める必要があります。後輩がコンピテンシーを示すのにいくつのプルリクエストが必要か、そうでないものを手放す勇気はありますか。