単に十分なテストを書かないジュニアプログラマーがいます。
私は2時間ごとに彼をしつこくしなければなりません、「あなたはテストを書きましたか？」
私たちは試しました：
私の仕事には最高品質の安定したコードが必要であり、通常は誰もが「それを取得」し、テストをプッシュする必要はありません。私たちは彼にテストを書かせることができることを知っていますが、有用なテストはあなたがそれに興味を持っているときに書かれたものであることを私たちは皆知っています。
もっと動機を知っていますか？
これは、最も難しいことの1 つです。人々にそれを理解してもらう。
ジュニア レベルのプログラマーが上級者から適切なテクニックを習得できるようにする最善の方法の 1 つは、ペア プログラミングを少し行うことです。
これを試してみてください: 今後のプロジェクトでは、後輩をあなた自身または別の上級プログラマーとペアにします。彼らは交代で「運転」（キーボードでタイプする人）と「コーチング」（ドライバーの肩越しに見て、提案や間違いなどを指摘する）を交互に行う必要があります。リソースの無駄に思えるかもしれませんが、次のことがわかります。
あなたのグループの誰かにKate Rhodes によるUnit Testing 101のプレゼンテーションを行ってもらうこともできます。うまく提供できれば、人々をテストに興奮させる素晴らしい方法だと思います。
あなたができるもう 1 つのことは、ジュニア開発者にボウリング ゲームのカタを練習させることです。これは、テスト駆動開発の学習に役立ちます。これは Java ですが、どの言語にも簡単に適応できます。
すべてのコミットの前にコードレビューを行い（1分間の「この変数名を変更しました」であっても）、コードレビューの一環として、単体テストをレビューします。
テストが実施されるまで、コミットを承認しないでください。
（また、彼の作品がテストされていない場合、そもそもなぜ本番ビルドに含まれていたのですか？テストされていない場合は、入れないでください。週末に作業する必要はありません）
私自身、見つけて修正したすべてのバグをテストとして表現するように主張し始めました。
私は何かを叩きながらもこれをやろうとしますが、部分的なテストスイートがすでに配置されているだけで、ほぼ同じ時間で完了します。
(私は商用プログラミング環境に住んでおらず、特定のプロジェクトに取り組んでいる唯一のコーダーであることがよくあります。)
想像してみてください、私が名前を付けられたモック プログラマーです... マルコ。私が学校を卒業したのはそれほど前ではなく、実際にテストを書く必要がなかったと想像してみてください。私が実際にこれを強制したり要求したりしない会社で働いていると想像してみてください。わかった？良い！ここで、会社がテストの使用に切り替えており、彼らが私をこれに同調させようとしていると想像してみてください。これまでに言及された項目に対して、私はこれについて何も調査していないかのように、やや皮肉な反応を示します。
作成者から始めましょう。
デザインがよりシンプルになっていることを示しています。
どうすればもっと書くことができ、物事をより簡単にすることができますか。私は今、より多くのケースを取得するなどを監視する必要があります.これは、あなたが私に尋ねると、より複雑になります. 確かな詳細を教えてください。
見せることで不具合を防ぎます。
そんなこと知ってる。これがテストと呼ばれる理由です。私のコードは良好で、問題がないかチェックしたので、これらのテストがどこで役立つかわかりません。
悪いプログラマーだけがそうしないと言うエゴのことです。
ああ、あなたは私があまり使用されたテストをしていないという理由だけで、私が悪いプログラマーだと思っています. 私はあなたに侮辱され、積極的に腹を立てています。ことわざよりも支援とサポートが欲しいです。
@ Justin Standard : 新しいプロジェクトの開始時に、ジュニアの男性を自分または別のシニア プログラマーとペアにします。
ああ、これは非常に重要なので、リソースが費やされて、物事がどのように行われるかを確認し、物事がどのように行われるかを支援してもらいます. これは役に立ちます。もっとやり始めるかもしれません。
@ Justin Standard : Kate Rhodes によるUnit Testing 101プレゼンテーションを読んでください。
ああ、それは興味深いプレゼンテーションで、テストについて考えさせられました。それは私が考慮すべきいくつかの点を打ち出しました、そしてそれは私の見解を少し揺るがしたかもしれません.
もっと説得力のある記事や、これが物事を行う正しい方法であると考えるのに役立つ他のツールを見たいと思っています.
@ Dominic Cooney : 時間を割いて、テスト テクニックを共有してください。
ああ、これはテクニックに関して私に何が期待されているかを理解するのに役立ちます。また、知識の袋にもっと多くのアイテムを入れて、再び使用できるようにします.
@ Dominic Cooney : 質問、例、書籍に回答します。
質問に答えてくれるポイント パーソン (人) がいることは役に立ちます。良い例は素晴らしいものであり、目指すべきものや参考になるものを与えてくれます。これに直接関係する本は大変参考になります。
@ Adam Hayle : サプライズ レビュー。
何を言っても、あなたは私がまったく準備ができていない何かを生み出しました。不快な思いもしますが、頑張ってください。私は今、これが再び起こることを恐れ、少し心配しています、ありがとう. ただし、怖がらせる戦術はうまくいったかもしれませんが、代償が伴います。ただし、他に何も機能しない場合は、これが必要なプッシュに過ぎない可能性があります。
@ Rytmis : テスト ケースがある場合にのみ、項目は完了したと見なされます。
おお、興味深い。私は本当に今これをしなければならないことがわかりました。そうしないと、何も完了しません。意味あり。
@ jmorris : 取り除く/犠牲にする。
まぶしさ、まぶしさ、まぶしさ - 私が学ぶ可能性があり、サポートと支援があれば、私はチームの非常に重要で機能的な部分になることができます. これは今の私のハンディキャップの 1 つですが、そう長くは続かないでしょう。ただ、わからない場合は、行くことを理解しています。私はそれを得ると思います。
最後に、私のチームのサポートがこれらすべてに大きな役割を果たしています。誰かに時間を割いて手伝ってもらい、良い習慣を身につけてもらうことはいつでも大歓迎です。あとは、サポートネットが充実しているといいですね。レビュー自体ではなく、友好的な訪問として、誰かが後で数回来て、コードを調べて、すべてがどのように流れているかを確認することを常に歓迎します.
推論、準備、指導、フォローアップ、サポート。
多くのプログラマーが合理的なレベルでテストすることの価値を理解していることに気づきました。「ええ、私はこれをテストする必要があることは知っていますが、私は本当にこれを迅速に行う必要があります」のようなことを聞いたなら、あなたは私が何を意味するかを知っています。しかし、感情的なレベルでは、彼らは実際のコードを書いているときにのみ何かが成し遂げられると感じています。
したがって、目標は、テストが実際に何かが「完了」したときを測定する唯一の方法であることをどうにかして理解させ、テストを作成する本質的な動機を与えることです。
でも、それは本来よりもずっと難しいのではないかと思います。「私は本当に急いでいます。後でこれを書き直し/リファクタリングしてからテストを追加します」という言い訳をたくさん耳にします。もちろん、驚くべきことに、フォローアップは決して行われません。来週も同じように忙しいです。
これが私がすることです：
初めて... 「私たちはこのプロジェクトを共同で行うつもりです。私はテストを書き、あなたはコードを書きます。私がテストを書く方法に注意してください.この辺りで、それが私があなたに期待することです。」
それに続いて... 「終わりましたか? 素晴らしいです! まず、開発を促進しているテストを見てみましょう. ああ、テストはありませんか? それが終わったら教えてください。コードを見てスケジュールを変更します.テストを策定するのに助けが必要な場合は、お知らせください。お手伝いします。」
彼はすでにこれをやっています。本当。彼はそれを書き留めていません。納得できませんか？彼が標準的な開発サイクルを行っている様子をご覧ください。
ステップ 3 はテストです。彼はすでにテストを行っていますが、手動で行っているだけです。彼に次の質問をしてみてください。彼はこう答えます。
質問: 「来週はどうですか?」
彼が答えを持っていないときは、次のように尋ねてください。
それが自動単体テストのすべてです。
ジュニア プログラマーとして、私はまだテストを書く習慣をつけようとしています。もちろん、新しい習慣を身につけるのは簡単ではありませんが、これが私にとってどのように機能するかを考えて、コードレビューとコーチング/ペアプログラミングに関するコメントを+1する必要があります.
また、テストの長期的な目的を強調する価値があるかもしれません。つまり、昨日機能したものが今日、来週、翌月も機能することを確認することです。答えをざっと読んでも、それが言及されているのを見なかったからです。
コード レビューを行う場合 (そうすることにした場合)、若い開発者が、彼を失望させるためではなく、コードをより良くするためのものであることを認識してください。そうすれば、彼の自信が損なわれる可能性が低くなるからです。そして、それは重要です。一方、自分の知識がどれほど少ないかを知ることも同様です。
もちろん、私は何も知りません。でも、その言葉が役に立てば幸いです。
編集：[ジャスティンスタンダード]
落ち込まないでください。あなたの言うことはほとんど正しいのです。
コード レビューに関するあなたのポイントについて: 後輩の開発者だけでなく、レビュー担当者もプロセスで学習することがわかります。コード レビューを共同プロセスにすれば、全員が学習します。
率直に言って、彼に何かをさせるためにそれだけの努力をしなければならないなら、あなたは彼がチームにぴったりではないかもしれない、そして行く必要があるかもしれないという考えに同意しなければならないかもしれません。さて、これは必ずしも彼を解雇することを意味するわけではありません...それは彼のスキルがより適している会社の他の場所を見つけることを意味するかもしれません。しかし、他に場所がない場合...あなたは何をすべきかを知っています。
彼もかなり新入社員（<1年）で、おそらく最近学校を卒業していると思います...その場合、彼は企業環境での仕組みに慣れていない可能性があります。私たちのほとんどが大学で逃げることができるようなもの。
この場合、私がうまくいったことの1つは、一種の「サプライズ新入社員レビュー」を行うことです。あなたが前にそれをしたことがないかどうかは関係ありません...彼はそれを知りません。彼を座らせて、彼のパフォーマンスを調べて実際の数字を見せてくれると伝えてください...通常のレビューシートを取り（正式なレビュープロセスはありますか？）、必要に応じて見出しを変更して、見た目が良くなるようにします。公式で、彼が立っている場所を見せてください。非常にフォーマルな設定で、テストを行わないことがパフォーマンス評価に悪影響を及ぼしていることを示すと、彼はそれについて単に「しつこく」するのではなく、うまくいけばポイントを得ることができます。あなたは彼の行動が実際に彼に影響を与えることを彼に示さなければなりません。
公式ではないので、これをやめたほうがいいかもしれません...しかし、あなたはそれを行うのに十分な理由があると思います。おそらく、彼を解雇して新しい人を採用するよりもはるかに安くなるでしょう。
私自身ジュニアプログラマーとして、あなたのジュニア開発者と同じような状況に陥ったときの様子を明らかにしたいと思いました.
大学を出たばかりのとき、現実の世界に対処するための準備ができていないことに気づきました。はい、私はいくつかの Java の基本といくつかの哲学を知っていました (質問しないでください) が、それだけでした。初めて就職したときは、控えめに言っても少し気が遠くなりました。私はおそらく最大のカウボーイの 1 人でした。コメント、テスト、ドキュメントなしで、小さなバグ修正/アルゴリズムを一緒にハックして、ドアの外に出荷していました。
私は親切で非常に忍耐強いシニア プログラマーの監督下にいることができて幸運でした。私にとって幸運なことに、彼は私と一緒に座って、私の非常にハッキングされた一緒のコードを 1 ～ 2 週間かけて調べることにしました。彼は私がどこで間違ったのか、c とポインターの細かい点を説明してくれました (少年はそれで私を混乱させました!)。約 1 週間でかなりまともなクラス/モジュールを作成することができました。私が言えることは、上級開発者が正しい道に沿って私を助けるために時間を割いてくれなかったら、おそらく私は長続きしなかっただろうということです.
幸いなことに、2 年後には、同僚の何人かが私を平均的なプログラマーと見なしてくれることを願っています。
お持ち帰りポイント
それがあなたの懸念である場合は、「最高品質の安定したコード」を必要としないプロジェクトにそれらを割り当て、ジュニアに任せてください。開発者は失敗します。バグを修正するために「週末に来て」もらいます。たくさん昼食をとり、ソフトウェア開発の実践について話します (講義ではなくディスカッション)。やがて、割り当てられたタスクを実行するためのベスト プラクティスを習得し、開発します。
彼らは、あなたのチームが現在使用しているテクニックよりも優れた方法を思い付くかもしれません。
ジュニアプログラマー、または誰かがテストの価値を理解していない場合、彼らにそれを実行させるのは難しいでしょう...期間。
バグを修正するために、ジュニアプログラマーに週末を犠牲にしてもらいました。彼の行動（またはその欠如）は彼に直接影響を与えていません。また、テストのスキルを向上させなければ、進歩や給与の増加は見られないことを明確にしてください。
結局、あなたのすべての助け、励まし、メンタリングがあっても、彼はあなたのチームに適していないかもしれないので、彼を行かせて、それを手に入れる誰かを探してください。
私は、すべてのコミットをレビューするコードについてのRodeoClownのコメントを2番目にしています。彼がそれをかなりの回数行ったら、彼はものをテストする習慣を身につけるでしょう。
ただし、そのようなコミットをブロックする必要があるかどうかはわかりません。私の職場では、誰もがすべてに自由にコミットでき、すべてのSVNコミットメッセージ（差分付き）がチームに電子メールで送信されます。
注：これを行う予定がある場合は、サンダーバードのcolored-diffsアドオンが本当に必要です。
上司または私（2人の「シニア」コーダー）がコミットを読み上げることになります。「単体テストを追加するのを忘れた」などの問題がある場合は、メールをフリックするか、その人とチャットして、理由を説明します。ユニットテストなどが必要でした。何が起こっているかを確認するのに最適な方法であるため、他のすべての人もコミットを読むことをお勧めしますが、ジュニア開発者はあまりコメントしません。
「ねえ、ボブ、今朝私がやったコミットを見ましたか、何とか何でもできるこの巧妙なトリックを見つけました。コミットを読んで見てください。使い方！"
注意：2人の「シニア」開発者と3人のジュニア開発者がいます。これは拡張できない場合があります。または、より多くの開発者でプロセスを少し調整する必要がある場合があります。
たくさんの心理学と役立つ「メンタリング」テクニックがありますが、正直なところ、これは「明日、まだ仕事をしたいのなら、テストを書く」ということです。
あなたはそれをあなたが適切だと思うどんな言葉でも、過酷であろうと柔らかくであろうと、それをソファに置くことができます、それは問題ではありません。しかし、実際には、プログラマーはコードをまとめてチェックインするだけで報酬を得るわけではありません。コードを慎重にまとめ、テストをまとめ、コードをテストしてから、すべてをチェックインすることで報酬を得ることができます（少なくともあなたの説明からすると、それはどのように聞こえるかです。）
したがって、誰かが仕事を拒否する場合は、明日家にいることができることを説明してください。そうすれば、仕事をする人を雇うことになります。
繰り返しになりますが、必要だと思うなら、これらすべてを穏やかに行うことができますが、多くの人は、Life In The Real Worldの大きなハードスラップを必要とし、それを彼らに与えることによって彼らに恩恵を与えるでしょう。
幸運を。
彼/彼女に教えるのはメンターの責任です。どのようにテストする方法を彼/彼女に教えていますか。あなたは彼とペアプログラミングをしていますか？ジュニアは、xyz の適切なテストを設定する方法を知らない可能性が高いです。
学校を卒業したばかりのジュニアとして、彼は多くの概念を知っています。とあるテクニック。いくつかの経験。しかし、結局のところ、すべてのジュニアは潜在的です。彼らが取り組んでいるほぼすべての機能には、これまでにない何か新しいものがあります。確かに、ジュニアはクラスのプロジェクトで「ドア」を開閉する単純な状態パターンを作成した可能性がありますが、そのパターンを実際に適用したことはありません。
彼/彼女はあなたがどれだけ上手に教えているかだけで上手になります。もし彼らが「ジャスト・ゲット・イット」できたなら、彼らはそもそもジュニアのポジションを取っていたと思いますか?
私の経験では、ジュニアはシニアとほぼ同じ責任を負って採用されますが、給与は低く、彼らが動揺し始めると無視されます。私が苦いように見えたら許してください、それは私がいるからです。
しばらくの間、彼の職務内容を、テストの作成とテストの保守だけに変更します。多くの企業が、新人未経験者に対して、入社時からしばらくの間、これを行っていると聞いています。
さらに、彼がその役割を担っている間に課題を発行します。a) 現在のコードで失敗する a) ソフトウェアの要件を満たすテストを作成します。願わくば、それによって彼がいくつかのしっかりした完全なテストを作成し (プロジェクトを改善する)、コア開発に再統合するときのテストをより上手に書けるようになることを願っています。
edit> ソフトウェアの要件を満たしているということは、コードがそのテスト ケースを考慮に入れようと意図したり必要としなかった場合に、意図的にコードを壊すためのテストを書いているだけではないということです。
まず第一に、ここでほとんどの回答者が指摘しているように、その人がテストの価値を理解していない場合、それに対してできることはあまりなく、その人をクビにすることはできないとすでに指摘しています。ただし、ここでは失敗は許されません。
組織が 6 人以上の開発者を抱えるほど大きい場合は、品質保証部門を設置することを強くお勧めします (開始するのは 1 人であっても)。理想的には、1 人のテスターと 3 ～ 5 人の開発者の比率が必要です。プログラマーに関することは...彼らはプログラマーであり、テスターではありません。適切な QA テクニックを正式に教えられたプログラマーにまだインタビューしたことがありません。
ほとんどの組織は、テストの役割を、コードに触れる機会が最も少ない新入社員に割り当てるという致命的な欠陥を犯しています。 、そして（願わくば）コードの匂いと発生する可能性のある障害点に対する第六感を発達させました。
さらに、間違いを犯したプログラマーは、おそらく構文エラーではなく (コンパイル時に検出される) 論理エラーであるため、おそらく欠陥を見つけることはできません。コードを書くときと同じようにテストします。コードを開発した人にそのコードをテストさせないでください -- 彼らは他の誰よりも少ないバグを見つけます。
あなたの場合、リダイレクトされた作業を行う余裕がある場合は、この新しい人を QA チームの最初のメンバーにします。彼に「実世界でのソフトウェア テスト: プロセスの改善」を読んでもらいます。彼は明らかに新しい役割でトレーニングを受ける必要があるからです。彼がそれを気に入らなければ、彼は辞めてしまい、あなたの問題は解決されます。
少し復讐心の少ないアプローチは、この人に自分の得意なことをさせて (この人は仕事のプログラミング部分で実際に有能であるため、この人を雇ったと仮定しています)、テスターを 1 人か 2 人雇ってテストを行います (大学生は多くの場合、実習または「協力」条件を持ち、露出が大好きで、安価です）
補足: 最終的には、QA チームが QA ディレクターに報告するか、少なくともソフトウェア開発マネージャーに報告しないようにする必要があります。興味。
組織が 6 人未満の場合、または新しいチームを作成することができない場合は、ペア プログラミング (PP) をお勧めします。私はすべての極端なプログラミング手法を完全に改宗したわけではありませんが、ペアプログラミングの信奉者であることは間違いありません。ただし、ペアになったプログラミング チームの両方のメンバーが献身的でなければなりません。そうしないと、うまくいきません。彼らは 2 つのルールに従わなければなりません。インスペクターは、画面上でコード化されている内容を完全に理解するか、コーダーに説明を求める必要があります。コーダーは自分が説明できることしかコーディングできません。「見てみろよ」とか「私を信じて」とか、手を振ることは許されません。
テストのように、いくら応援したり脅したりしても、自我に満ちた内向的な人が一緒に仕事をすることに抵抗がある場合、彼らを説得することはできないからです。ただし、詳細な機能仕様を記述し、コード レビューを行うか、ペア プログラミングを行うかを選択すると、通常は PP が勝ちます。
PP があなたに向いていない場合は、TDD が最善の策ですが、文字通りに解釈される場合に限ります。テスト駆動開発とは、最初にテストを作成し、テストを実行して実際に失敗することを証明し、それを機能させるための最も単純なコードを作成することを意味します。トレードオフは、何千ものテストのコレクションを持っている (べきである) ことです。これはコードでもあり、本番コードと同じようにバグが含まれる可能性があります。正直なところ、私は主にこのような理由で TDD の大ファンではありませんが、テスト ケース ドキュメントよりもテスト スクリプトを作成したい多くの開発者にとって TDD は有効です。TDD と PP を組み合わせて、テスト カバレッジの可能性を高め、スクリプトのバグを減らします。
他のすべてが失敗した場合は、プログラマーに誓いの瓶と同等のものを用意してもらいます-プログラマーがビルドを壊すたびに、20ドル、50ドル、100ドル(スタッフにとって適度に苦痛なもの)をお気に入りの瓶に入れなければなりません(登録済み!) 慈善団体。彼らが支払うまで、彼らを避けてください:)
冗談はさておき、プログラマーにテストを書かせる最善の方法は、プログラマーにプログラムさせないことです。プログラマーが必要な場合はプログラマーを雇う -- テストが必要な場合はテスターを雇う。私は 12 年前にジュニア プログラマーとしてテストを始めましたが、それが私のキャリア パスになりました。適切に育成され、ソフトウェアを改善する権限と権限を与えられた堅実な QA 部門は、最初にソフトウェアを作成する開発者と同じくらい価値があります。
あなたの同僚がテストを書いた経験がない場合、単純な状況を超えてテストするのに苦労している可能性があり、それはテストが不十分であることを示しています。これが私が試すことです：
私は恥/罪悪感の要因を特に強調しません. テストは広く採用されている優れたプラクティスであり、優れたテストを作成して維持することは専門家としての礼儀であるため、チーム メイトは週末を仕事に費やす必要がないことを指摘する価値はありますが、その点については詳しく説明しません。
本当に「タフになる」必要がある場合は、公平なシステムを導入してください。自分が選ばれているように感じたくない人はいません。たとえば、チームは、特定のレベルのテスト カバレッジを維持するためにコードを必要とする場合があります (ゲームは可能ですが、少なくとも自動化は可能です)。テストを行うには新しいコードが必要です。コード レビューを行う際に、レビュアーにテストの品質を考慮するよう要求します。等々。そのシステムの制定は、チームのコンセンサスに基づいている必要があります。議論を慎重にモデレートすると、同僚のテストが期待したものではない他の根本的な理由が明らかになるかもしれません。
@ jsmorris
私はかつて、上級開発者と「アーキテクト」に、私とテスター (大学を出た最初の仕事でした) が、遅刻せずに前の晩にそのような「簡単な」タスクを完了したことをメールで非難してもらいました。私たちは一日中そこにいて、午後 7 時にやめると言いました。私はその日の昼食前の午前 11 時からスラッシングしていて、チームのすべてのメンバーに少なくとも 2 回助けを求めていました。
私は返信し、チームに次のように CC しました。申し訳ありませんが、ほぼすべてが依存している 12 個のパラメーター、800 行のメソッドをデバッグできませんでした。」
コーヒー ショップで 1 時間冷やした後、私はオフィスに戻り、がらくたをつかんで去りました。数日後、彼らは私が来るかどうかを尋ねる電話をしました。
「それで、辞めますか？」
ソース リポジトリで: 各コミットの前にフックを使用します (たとえば、SVN の pre-commit フック)
そのフックで、メソッドごとに少なくとも 1 つのユース ケースが存在するかどうかを確認します。pre-commit フックを介して簡単に適用できる単体テスト編成の規則を使用します。
統合サーバーですべてをコンパイルし、テスト カバレッジ ツールを使用してテスト カバレッジを定期的にチェックします。コードのテスト カバレッジが 100% でない場合は、開発者のコミットをブロックします。彼は、コードの 100% をカバーするテスト ケースを送信する必要があります。
プロジェクトで適切にスケーリングできるのは、自動チェックのみです。すべてを手で確認することはできません。
開発者は、自分のテスト ケースがコードの 100% をカバーしているかどうかを確認する手段を持つ必要があります。そうすれば、彼が 100% テスト済みのコードをコミットしない場合、それは彼自身の責任であり、「忘れてすみません」の責任ではありません。
覚えておいてください：人々はあなたが期待することを決してしません。彼らは常にあなたが検査したことをします。
ジュニア エンジニア/プログラマーがテスト スクリプトの設計と実行に多くの時間を費やさない主な理由は、ほとんどの CS 認定ではこれがあまり必要とされないためです。そのため、エンジニアリングの他の領域は、デザイン パターンなどの大学のプログラムでさらにカバーされます。
私の経験では、経験の浅い専門家に習慣を身に付ける最善の方法は、明示的にプロセスの一部にすることです。つまり、反復にかかる時間を見積もる場合、ケースの設計、作成、および/または実行の時間をこの時間見積もりに組み込む必要があります。
最後に、テスト スクリプトの設計のレビューは設計レビューの一部である必要があり、実際のコードはコード レビューでレビューする必要があります。これにより、プログラマーは自分が書いたコードの各行の適切なテストを行う責任があり、上級エンジニアや同僚は、コードと書かれたテストに関するフィードバックとガイダンスを提供する責任があります。
「デザインがよりシンプルになることを示す」というコメントから、TDDを実践していると推測されます。事後にコードレビューを行うのはうまくいきません。TDD の本質は、それが設計であり、テストの哲学ではないということです。彼が設計の一部としてテストを作成しなかった場合、事後にテストを作成しても、特にジュニア開発者から多くの利益を得ることはできません。彼は多くのまれなケースを見逃すことになり、彼のコードは依然としてお粗末なままです。
あなたの最善の策は、非常に辛抱強い上級開発者に同席してもらい、ペアプログラミングを行うことです。そして、彼が学ぶまでそれを続けてください. または、学習しない場合は、実際の開発者をイライラさせるだけなので、彼により適したタスクに彼を再割り当てする必要があります.
誰もが同じレベルの才能やモチベーションを持っているわけではありません。開発チームは、アジャイル チームであっても、「A チーム」と「B チーム」のメンバーで構成されています。A-Team のメンバーは、ソリューションを設計し、すべての重要な製品コードを記述し、ビジネス オーナーと通信するなど、既成概念にとらわれずに考える必要があるすべての作業を担当します。B チームは、構成管理、スクリプトの作成、不完全なバグの修正、保守作業などを処理します。すべての作業には、失敗の影響が小さい厳密な手順が含まれます。
これは少し冷酷かもしれませんが、状況を説明する方法は、この男をクビにする必要があるように思えます。または、少なくとも明確にしておきます: 自社開発の慣行 (テストの作成を含む) に従うことを拒否し、他の人がクリーンアップしなければならないバグのあるコードをチェックインすると、最終的に解雇されます。