ジュニア開発者にバイクシェディングを停止させる方法
ジュニアデベロッパーのバイクシェディングPRに問題があります。これらは、1つのリポジトリの主要な承認者です。 PRに1時間または数分かかるはずのものは、往復コメントで数日を費やすことがあります。
昨日の例：ビルドシステムにアーティファクトを追加しました。 1行の変更。なぜ別のものがあるのかを尋ねる3つの往復コメントを取得します。これは2か月間存在していたもので、コードの変更とは無関係です。
他の一般的なセットは、初期でないソリューションのパスにそれらを導く必要があります。あなたはそれがどうであるか知っています。問題アルファがあります。最初の考えはソリューションAです。より深い考えは、問題ゼータのために機能しないことを明らかにします。したがって、ソリューションBが必要です。ソリューションBのPRを提示し、それがそのように実装される理由を詳しく説明します。最初のコメント、「なぜソリューションAではないのですか？」問題ZのためにソリューションAが機能しないといううさぎの穴を案内する必要があります。彼らはそれを理解して同意します。
社会的には、ジュニア開発者はフレンドリーで、私たちは素晴らしく仲良くしています。しかし、このブロッキング動作は多くの作業を妨げています（私は、他のPRが入るのを待つ3週間のPRバックログがありました）。
バイクシェディングのPRを停止するように頼んだとき、彼はバイクシェディングの定義のバイクシェディングを始めました。
ここには2つの異なる問題があります。
1つは、変更を加えることです。レビュー担当者がレビューします。レビュー担当者は、不快かもしれないし、そうでないかもしれないコードを発見しますnear変更とコメントを付け、おそらく変更を要求します。
その答えはthisコードはあなたが行った変更とは何の関係もない、あなたのレビューの間に彼がレビューすべきものではなく、それがあなたの変更の範囲外であるという絶対に堅実な返答です、そして、間違いなくnot変更します。彼がそれを気に入らない場合、彼または彼女は自分の名前を変更要求としてシステムに入れることができます。変更要求は、それを担当する人によって受け入れられるか、受け入れられません。受け入れられた場合、他よりも優先されます仕事、それは変更する誰かに与えられます。その前に、あなたはそれに触れたり、議論したりしていません。
明らかに、これを1回記述し、必要に応じてコピーして貼り付けます。
2番目の問題の場合：明らかであるが実際には機能しない問題のソリューションAがある場合、ソリューションBのコードの先頭に、これを説明するコメントを追加することをお勧めします。今日のレビュアーだけでなく、来年のコードを見ている私や、来年のコードを見ている自分も、「なぜもっと簡単な方法Aを使用しなかったのか？」特に、Aが機能しないことがわかるまでに時間がかかった場合-実際にAの実装に2日間を費やし、Aが機能しないことを確認して破棄したとします。
コードにコメントを追加します。その時点で、レビュー担当者はコードを見ることができ、コードを理解するための十分な能力を期待できます。それを説明するのはあなたの仕事ではありません。
ジュニアプログラマーは、自分のコードや以前のコードを聞きたい、または理解するのに苦労しているだけかもしれません。彼らはあなたよりも長くそのリポジトリに取り組んでいると思います。実装を開始する前に彼らの意見を聞いた場合、開発は迅速でPRも迅速になる可能性があります。そうすれば、シニアとして、ジュニアを実装の意思決定に含めることになります。実装する前に問題と解決策について話し合うと、チームの結束が高まり、PRレビューがスピードアップすることがわかりました。