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


95

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

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

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

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


7
彼があなたの期待が何であるかを確実に知るためにどれくらいの時間を費やしましたか?
Blrfl


13
@gnat私はそれが同じケースではないと思う、私の問題は、私たちが見積もりを超えたりコードをやりすぎたりすることではない。実際のところ、私たちは予定より進んでいます。私の質問は、男を教えることと絶え間ない批判で彼を燃やさないこととの間のバランスをどのように取るかです。
ザロモン

4
私はこれを編集して、トピックについてさらに説明しました。これは、リンクされた重複する質問とも異なると思います。
エンダーランド

3
ペアプログラミング-彼がどのように機能し、どのように考えているかについての洞察を獲得し、コードを実行する際にあなたの思考プロセスに彼をさらすかもしれません。彼が得意とする仕事を見つけてください-大規模な機能の仕事に対して、彼に小さなバグの束を投げてより良い結果を得ることがあります。技術設計-コードに触れることなくソフトウェアを設計する最初のきっかけを与えます。これにより、彼は構造とプロセスについて頭を下げてコードをかき回すことについて考えることができます。最後に、幸運を祈ります。予想よりも永続性が必要になることもありますが、生産性が上がると価値があります。
サンディチャップマン

回答:


84

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

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

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

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

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

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

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

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


65
9000 @それは、これらの基準にも...どこにも記載されていないとき、人々は彼らの基準に従って寄与しない人々について不満を感じているどのくらいの頻度驚くべきことだ
enderland

32
変数名は全くコードの意図を説明する際に重要。メソッド/関数名、さらにそう。名前を正しくすることは無用な完璧主義ではなく、保守性のために必要です。
9000

9
@Zalomonは間違いなく彼に言及します。さらに、それを議論に変えてください。ジュニア開発者として、私はいくつかの異なるシニア開発者と仕事をしました。私の最高の経験は、彼のすべての推奨事項について私に話してくれた開発者でした-変数の少し良い名前のような「小さな」ものでも。私は彼からたくさんのことを学んだだけでなく、彼が私の思考プロセスに耳を傾け、議論に私を含めていたので、私は彼が私がより多くを学ぶことができるように私のコードをもっと見直してほしいと思ったほど気持ちが良かった。(続き)
dj18

6
@Zalomon(続き)反対に、私の背中の後ろで変更を行った上級開発者(後で彼に言っても、それはまだ彼の背中の後ろにあります)は完全に意気消沈しました-それは私が独裁者と働いているように感じました喜ばせる方法を見つけなければなりませんでした。
dj18

6
ジュニア開発者を指導する私の(小さな)経験は、開発者に適切な名前を真剣に考えさせ、変数名のデータの目的を表現させることはしばらくの間価値があることを示しています。開発者がコードが何をしているのかを実際に理解するのに役立ちます。これは、従来よりもはるかに少ない手作業で行われます。場合によっては、関係するコードの論理エラー、または物事を表現するためのより良い方法を見つけることになります。(同じことがうまくいきます。違いは、過去に厳格なコードレビュアーがいたため、規律が内部化されていることです。)
9000

19

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

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

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

ボディランゲージ

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

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

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


2
言い回しの点:個人の代名詞を使用する必要がある場合、コードレビューの両側での私の経験では、「あなた」ではなく「私たち」を選択するだけで批評が非個人化されます。
ジョシュキャスウェル

6

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

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

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

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

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

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


5

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

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

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


コードレビューの無限のサイクルを回避する方法の1つは、変更を小さくすることです。有益な変更を行う場合、プルリクエストはばかげて小さくなりません(1文字のPRを共有しました)。小さいほど良い。ジュニア開発者に渡されるチケットの範囲を容赦なくカットし、彼らに物事を成し遂げさせます。読み取り-理解-コード-テスト-レビュー-展開プロセス全体がうまくいけば、範囲を広げることができます。
9000

1
OPが戻って後で変更するのに十分な重要性がある場合、開発者に「それほど重要ではない」と伝えるのは良い考えだとは思いません。
エンダーランド

3
@enderland私の経験では、完璧なコードというものはありません。後でいつでも改善できるので、ここではあまり関係ありません。OPは、これらは「暇があれば修正する」ことだと言います。問題には2種類あります。修正する必要があるものと修正する必要がないもの。後者は修正される場合と修正されない場合があり、これらはそのカテゴリに該当するように聞こえます。それはあるレベルでの判断の呼び出しですが、経験豊富な開発者として、変更する必要があるとして呼び出す価値があるかどうかわからないとしたら、おそらくそうではないと思います。
JimmyJames

5

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

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

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


3
または「(b)そして、あなたはもっとうまくやれることを知っています。」彼が「教えて」と尋ねるなら、あなたは彼が正しい道にいることを知っています。:)
マチャド

1
私の以前のポジションでは、コードレビューツールとしてStash / BitBucketを使用しました。未処理のタスクを設定するか、完全にプル要求を拒否することにより、プル要求をブロックするオプションがありました。これらは必要な変更にのみ使用します。表面的な変更(たとえば、マイナーコードの読みやすさ、データ構造の改善、リファクタリング)があった場合、提案で指摘しますが、ブロッキングタスクを追加しないでください。これにより、マイナーなヒューズの期限を逃すこともなくなります。
手電子食品

4

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

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

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

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

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


3
私はピアレビューのアイデアが好きです。現時点ではチームの2人だけですが、コードをレビューしてもらうことができます。彼が私がしていることを理解し、いくつかの不一致を見つけることができれば、コードの品質と彼の士気の両方に役立ちます。間違いを犯したのは自分だけではないということを私が知っていたときに役立ちました+1
ザロモン

2

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

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

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


2

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

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

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

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


1

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

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


実際のところ、彼は自分が愚かだと言っていました。私はポジティブな面で批判を続けようとしています、そして彼に彼の仕事に満足していることを伝えました。彼の仕事を改善するために、それは間違っています。
ザロモン

2
彼がより良いプログラマーになることを期待していないなら、彼のコードを慎重に批判する時間を無駄にしないことを説明してください。また、「コードを受け入れられるようにするには、これを修正する必要があります」と「次回はもっと良い方法があります」とを区別する際には慎重になってください。洞察に満ちた正確な批判を大量に提供することは、ジュニアプログラマーに与えることができる最大の贈り物です。それを怠ると、彼らはより悪いプログラマーになります。批判は徐々に減少し始めます。すべての間違いを1回、おそらく2回行うだけで済み、間違いは非常に多くあります。
デビッドシュワルツ

1

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

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

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


0

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

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

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

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

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

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

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


-1

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

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


-1

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

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

私の投稿の何が悪いのか知りたいです。ダウン票は不一致の理解できる兆候ですが、投票を削除しますか?!
-BartoszKP
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.