ジュニア開発者からの「ほぼ良い」コードに対処する方法は？[閉まっている]

チームの管理について質問がありました。現在、私はコーディング工場からリモートで作業しているジュニア開発者を扱っています。その男は批判に対して寛容であり、学ぶことをいとわないが、どれだけのものをプッシュすべきか疑問を抱いた。

現在、何かがまっすぐで明白な場合、グッドプラクティスの違反です。SRP、Godオブジェクト、メソッドまたは変数の意味のない名前の違反など。私は彼が修正しなければならないことを指摘し、それが間違っている理由を説明しようとします。

私の質問は次のとおりです。間違った言語の変数名（以前のチームがスペイン語と英語を混ぜて、それを修正しようとしています）のようなコーディングスタイルのマイナーな違反がある場合、またはいくつかのマイナーな構造上の問題がある場合、私は手放します空き時間があるか、問題のあるクラスを変更する必要があります。これはチームの士気に良いと感じているので、初心者には些細なことのように見えるかもしれませんが、コードを常に押し戻そうとはしていません。何かをする方法を学ぶことから。

男を教えることと絶え間ない批判で彼を焼き払わないことの間のバランスをどのように取るのですか？後輩にとっては、目が効いているものをやり直すように言ったらイライラするかもしれません。

マージする前にコードを修正する必要があると思われる場合は、コメントを作成してください。開発者が学習できるように、「理由」を付けてください。

コードは、書かれているよりもはるかに頻繁に読み取られることに注意してください。したがって、「マイナー」と思われるものは実際には非常に重要です（たとえば変数名）。

ただし、面倒なコメントを作成している場合は、次のことを検討してください。

• CIプロセスでこれらをキャッチする必要がありますか？
• 参照できる明確な「開発者ガイド」はありますか（またはすべてが頭の中に文書化されていますか）？
• これらのコメントは実際にコードの品質に貢献していますか？

多くの人々は、プロセスまたは完璧の祭壇で生産性を犠牲にします。これをしないように注意してください。

可能であれば、同僚に直接会ってみてください。または、ビデオ通話を使用します。関係を構築することで、批判（コードレビューも含む）の管理が容易になります。

コードの一部に問題の前後が多すぎることがわかった場合は、小さなコードの一部についてレビューをリクエストしてください。漸進的な変更は、定義により小さいため、重要な設計上の問題のいくつかを回避する可能性が高くなります。

しかし、絶対にないではないものをマージして、戻って、それを修正。これは受動的で積極的であり、開発者があなたにこれをしていることに気付いた場合、あなたは彼らの士気を殺します。

作家ではなくコードを批判する。

制作された作品には、本質的に感情的な愛着があります。できる限りライターからコードを分離することでこれを緩和することを検討してください。コードの品質は、あなたとあなたとの間の摩擦点ではなく、あなたとあなたが共に直面する相互の目標として一貫して確立されるべきです。

これを達成する1つの方法は、言葉を賢く選択することです。STEM個人は自分自身を非常に論理的であると考えるのが好きですが、感情は人間性の一部です。使用される言い回しは、傷ついた感情とspareれた感情の違いです。「この関数名は英語である場合、慣習とより整合性があります」と言う方が「この関数名を間違って書いたので、英語である必要があります。」後者はまだ飼いならされており、単独で問題ないように見えますが、前者と比較してその欠点は明白になります-直接、またはメールで言うことを準備するとき、あなたのコンテキスト、言葉、フォーカスが問題ではなく問題にあるかどうかを調べます人。

ボディランゲージ

言葉は重要ですが、ほとんどのコミュニケーションは非言語的です。ボディランゲージに注意を払います。たとえば、オリエンテーションマターなどの些細な微妙な点まで注意してください。たとえば、多くのシニアジュニアインタラクションは顔を合わせて行われますが、サイドバイサイドアプローチは望ましい結果をもたらします。

正直な正のフィードバックを与える

多くの研究は、悪い行動を罰するよりも良い行動に報いる方が、情報がより迅速に学習され、より良く保持されることを示しています。単純な「良い仕事」またはより具体的な「最近、あなたのスタイルが私たちの基準に合ったティーになっていることに気付いた素晴らしい仕事！」でパフォーマンスが改善されたことに注意するだけです。この改善の認識を補完することで、修正した問題について他の人にアドバイスすることで、後輩開発者と彼の仕事にすべての違いをもたらすことができます。

その男は批判に対して寛容であり、学ぶことをいとわないが、どれだけのものをプッシュすべきか疑問を抱いた。

あなたができるすべてを押してください。男が学習していて、彼のコードをレビューするのがあなたの仕事である場合、彼が良い仕事をすれば、あなたは両方とも多くを得ることができます。

これは、今後レビューするコードが少なくなることを意味し、チームに雇用目標を与える可能性があります。

また、あなたが手放すなら、あなたは助けではなく、ひいきになります。

質問をここに投稿し、やりすぎかどうかを尋ねるという事実によって、この特定のアドバイスは必要ないことを既に署名しますが、他の人にとっては、ここに来ます：ジャークであること。

メンターになるのは簡単なことではありません。また、彼がミスをして自分で修正するためのスペースを確保する必要があります。実際にダメージを与えない場所で彼がそれを行うようにしてください。

あなたの説明に基づいて、「これは良いことです。別の方法でやったことはいくつかありますが、それらはあまり重要ではありません。」

あなたが把握しているように、批判にはコストがかかり、細部の微調整に多くの時間を費やす場合、それは士気の問題になります。理想的には、すべてのコーディング標準が自動的にチェックされ、それらに従わない限りビルドできません。これは非常に時間を節約でき、ビジネスに取りかかることができます。「重要なもの」に対する批評を保留する場合、あなたのアドバイスはより大きな影響を与え、あなたは大切なメンターとみなされます。良くないこととそうでないことを区別することは本当に重要です。

私は教えられる瞬間の概念を信じています。開発者が十分な精神的能力を持っている場合、（s）彼はあなたがどう違うかについての詳細を尋ねるかもしれません。（S）彼はそうしないかもしれないし、それは大丈夫です。人々は燃え尽きてしまい、キャリアの早い段階で、後で簡単に思えることを達成するために多くの精神的なエネルギーが必要になる場合があります。

私は彼の作品が完全ではなく、受け入れられるときに受け入れることを検討します。そして、次のタスクは、ディスカッションの後、すぐにリファクタリングすることです。必要な小さな重要な変更をすべて行います。

仕事が最初に受け入れられるとき、あなたのメッセージはそれが悪くなかったということであり、いくつかの場所はそれを十分に受け入れたでしょう-しかし、あなたは彼の貿易を適切に学びたいジュニア開発者としてなりたい場所ではありませんでした。

ですから、「あなたの仕事は十分ではないので、私はあなたの仕事を拒否します」とは言わない あなたは（a）「十分に良いのであなたの仕事を受け入れます」、そして（b）「しかし私はそれをもっと良くしたい」と言います。

かなり未解決の質問ですが、ここにいくつかのアイデアがあります。

1. ピアレビュー（ジュニア開発者による）

   誰かが「正しい」方法を学ぶための最良の方法は、他の人がそれをするのを見ることです。すべての開発者がコードレビューを実施していますか？ジュニア開発者にもそれらを実行させるのは悪い考えではないかもしれません（ただし、シニア開発者にも少なくとも1回はレビューを要求する必要があります）。そうすれば、彼は優れたコーダーが動作しているのを見ることになります。さらに、自分以外のエンジニアに向けられたレビューコメントがあることに気付くでしょう。

2. 早期のフィードバック/タスクのレビュー

   開発者が自分のタスクの内訳に参加できるようにします。タスクノートに意図した設計を記録し、変更セットなしでタスクだけで「コードレビュー」を送信してもらいます。そうすれば、1行のコードを作成する前に彼の計画を確認できます。タスクがレビューされると、コーディングを開始できます（その後、別のコードレビューを送信します）。これにより、開発者が大量のものを作成し、それを書き換えるように彼に指示する必要があるという、士気を低下させる状況を回避できます。

コードが記述された明確な標準に客観的に違反している場合は、すべての問題が修正されるまで押し続ける必要があると思います。確かに、最初の数回のコミットは開発者にとって少し面倒かもしれませんが、評価者はすぐにガイドラインを学ぶことができます。

また、あちこちで標準の違反をいくつか許可すると、悪い先例が設定されます - 壊れたウィンドウの理論を参照してください。また、コードベースに既に一貫して適用されている場合は、標準に従うことを覚えておくのがはるかに簡単です。本当に、問題のジュニア開発者を含め、誰もが勝ちです。

コーディング標準が書かれている限り、士気は大きな問題ではないと思います。開発者のアプローチも同じように有効である可能性があるため、より主観的な「まあ、私はそれを別の方法で行っていた」領域に入る場合にのみ、心配する必要があります。

開発者がGithub Pull RequestsやPhabricator Diffusionなどのツールにコミットの提案を投稿し、変更を共有マスターブランチにランディングする前にピアサインオフを取得するコードレビューワークフローの採用を検討してください。

このように、過去にさかのぼって批判したり、既に行われたことをやり直すように誰かに頼んだりするのではなく、ピアレビューに合格するまで作業はまだ完了していません。ピアとのやり取りは、コンパイラとのやり取りと同じくらいソフトウェアエンジニアリングプロセスの一部です。

特定の行にコメントとして懸念を投稿し、それらについての議論をスレッド化できます。彼はあなたのコードに対して同じことをすることができます。議論は、一般的に誰かのパフォーマンスや能力ではなく、提案された特定のコード変更に焦点を当てたままです。

私の会社の優秀なシニアエンジニアでさえ、コードレビューがタイプミスを見つけたり、物事をより明確にするように強制したりすることに感謝しています。新規採用者がより多くの反復を必要とすることは完全に正常です。時間が経つにつれて、差分を投稿する前にコメントを引き付けることがわかっている種類の問題を再帰的に修正し始めます。最初の試行で受け入れられる差分の割合を高くすることは、あなたがどのように改善しているかを知る方法です。

私は初心者にちょっとした詳細のように見えるかもしれないコードを常に押し戻していませんが、それは非常にイライラする可能性がありますが、あまりにも「ソフト」だと、男が何かをする方法を学ぶのを妨げる可能性があることも心配しています。

これらは、本当の可能性と有効な懸念の両方です。開発者にそれについてどう思うか尋ねてください。

プルリクエストまたはコードレビューワークフローがあり、そのように見える場合、「重要ではない」または「優先する」ことに注意することをお勧めします。

あなたが記述しているものと似た状態のPRがあり、いくつかの小さな文体的な問題があるか、重要でないリファクタリングが必要な場合は、コメントを残してください。「将来的には、descriptiveMethodNameのようなものを優先して、このようなメソッド名を避けようとするかもしれません」と言って、変更を強制したり、開発をブロックしたりせずに意見を文書化します。

今、彼らはあなたの好みを知っており、改善しようとしているなら、将来そのような状況に気付くでしょう。また、彼らがあなたに同意し、それが十分に重要であると見れば、その時に実際にそれを変更するドアを開いたままにします。

私は、コーディング工場からリモートで作業しているジュニア開発者を扱っています。

それは、残念なことに、理想的な状況ではありません。地理的に離れた初心者プログラマーを担当する上級プログラマーです。多少の緊張があるのは驚くことではありませんが、格差は緩和できます。

興味がありますが、「コーディングファクトリ」とはどういう意味ですか？私にとって、その用語は、あなたが言及した管理上の問題のいくつかを悪化させているかもしれない厄介な態度を示しています。

…SRP、Godオブジェクト、メソッドまたは変数の意味のない名前の違反。私は彼が修正しなければならないことを指摘し、それが間違っている理由を説明しようとします。

問題は、ジュニア開発者が適切な設計プロセスを経ずにコードを吐き出していることだと思います。これは、管理者およびシニア開発者としてのあなたの側の失敗であり、ガイダンスを提供し、優れたソフトウェア開発習慣を教えません。最初に協力してアウトラインをスケッチする場合、最初に悪いコードが記述されるのを防ぐことができます。これは、効率と士気の両方の観点から、コードが生成された後にコードを批判および書き換えるよりも望ましいでしょう。

おそらく、ワークフローを再調整する必要があります。現在、彼があなたに製品を配達することを期待しているようです。必要なのは、緊密なコラボレーションであり、開発のあらゆる段階でガイダンスを提供できるようにすることです。コーディングを開始する前に、設計とインターフェースについて話します。コーディングが行われている間に、より頻繁にチェックポイントを実行して、問題を早期に発見します。可能であれば、オーディオチャネルとの画面共有を介してペアプログラミングを試してください。

これはすべてあなたの側でより多くの努力を必要としますが、おそらくあなたが現在持っている問題のある関係を考えると、それは価値があるでしょう。

コーディング標準に違反している場合は、それがどこにあるかを見せて、彼/彼女が知っているようにします。あなたが彼/彼女に同じ間違いを見せ続けなければならない場合、あなたはルールに適合できないか、拒否する誰かに問題があるかもしれません。空き時間を使って間違いを修正しないでください。この人は自分でエラーを修正して、再びエラーが発生しないようにする必要があります。

彼らが何を正しくしたか、そして次にどのように改善できるかを常に伝えてください。私たちはいつかどこかで良くなることができます。フィードバックは、何でも良くなるために重要です。

「あまりにも多くの批判」に対処するための別のアイデアは、時々自分でタスクを実行し、ジュニア開発者にコードレビューを行わせることです。これには、少なくとも2つの利点があります。

• 彼らは物事がどのように行われるべきかを学ぶことができます。
• 複数の適切なソリューションまたは変数名がある場合、異なるが（ほぼ？）同様に適切なアプローチの提案を受け入れます。誰かのコメントのために自分のコードを修正するとき、私は彼らが尊敬されていることを人々に示しています。