testing - 自分のコードをテストしない開発者をどうしますか?

Question

私たちの開発者の 1 人は、継続的にコードを書き、それをテストせずにバージョン管理に入れています。その結果、コードの品質が低下しています。

開発者を取り除く以外に、どうすればこの問題を解決できますか?

編集

私はそれについて何度も彼に話し、彼に書面による警告さえしました

score 43 · Accepted Answer

コードレビューを行うことができれば、それを把握するのに最適な場所です。

イテレーショントランクにマージする前にレビューが必要なため、通常はその時点ですべてがキャッチされます。

score 33 · Accepted Answer

開発者にコードのコミットを許可する前に体系的にコードレビューを実行すると、問題はほぼ解決されます。しかし、これはあなたのケースではないようですので、これが私がお勧めするものです：

開発者に相談してください。チームの他のメンバーへの影響について話し合います。ほとんどの開発者は同僚に認識されることを望んでいるので、これで十分かもしれません。また、数週間前のコードよりも、頭の中で新鮮なコードのバグを修正する方がはるかに簡単であることも指摘してください。この部分は、何らかの形式のコード所有権が設定されている場合に意味があります。
しばらく経ってもこれが機能しない場合は、バグのあるコードを作成者にとって不快なものにするポリシーを設定してみてください。一般的な方法の1つは、ビルドを壊した人に、次のビルドを作成する雑用の責任を負わせることです。ビルドプロセスが完全に自動化されている場合は、代わりに別の面倒なタスクを探してください。このアプローチには、特に誰かを特定しないという追加の利点があり、すべての人にとってより受け入れやすくなります。
懲戒処分を使用します。あなたのチームとあなたの会社の規模に応じて、それらは多くの形をとることができます。
開発者を解雇します。悪いリンゴを維持することに関連するコストがあります。ここまで到達すると、開発者は仲間の開発者を気にせず、すでに人の問題を抱えています。作業環境が汚染された場合、この1人の悪い開発者よりも、生産性と人の面ではるかに多くの損失を被る可能性があります。

score 14 · Accepted Answer

自分のコードをめったにテストしない開発者として、私が自分の行動をゆっくりと変えさせた1つのことをあなたに言うことができます...

可視性

環境でコードをプッシュできる場合は、ユーザーが問題を見つけるのを待ってから、基本的に「今はどうですか？」と尋ねます。コードに変更を加えた後は、自分のものをテストする本当のインセンティブはありません。

コードレビューとコラボレーションにより、同僚が「ウィジェットY」と「ウィジェットZ」で作業しているときに「ウィジェットX」を提供する場合よりも、高品質の製品を作成するために取り組むことができます。

あなたの作品が目立つほど、それがどれだけうまく機能するかを気にする可能性が高くなります。

score 10 · Accepted Answer

コードレビュー。毎週月曜日の朝にすべての開発者を部屋に閉じ込め、前週の最も誇りに思っているコードベースの成果を彼らと一緒に会議に持ち込むように依頼します。

彼らにスポットライトを当てて、彼らが何をしたかを説明することに興奮させてください。他の開発者が彼らが話していることを見ることができるように、彼らにコードのコピーを持ってきてもらいます。

私たちは数ヶ月前にこのプロセスを開始しました、そして行われる潜在意識の品質チェックの量を見るのは驚くべきことです。結局のところ、開発者が彼らが最も興奮していることについて話すように単に求められた場合、彼らは人々に彼らのコードを見せることに完全に興奮するでしょう。次に、他の開発者は品質エラーを確認し、それらが間違っている理由と、代わりにコードを実際に作成する方法について公に話し合います。

これで開発者が高品質のコードを記述できない場合、彼はおそらくあなたのチームには適していません。

score 10 · Accepted Answer

それを彼の年次レビューの目標の一部にしてください。達成しなければ昇給なし。

誰かがあなたのチーム/環境にふさわしくないことを受け入れる必要がある場合もありますが、それは最後の手段であり、対処するのが難しい場合がありますが、他のすべてのオプションを使い果たした場合、長期的にはそれが最善の方法である可能性があります.

score 9 · Accepted Answer

Cruise Controlまたは同様のツールを使用して、チェックインでビルドテストと単体テストを自動的にトリガーすることができます。彼が追加した新しい機能の単体テストがあることを確認する必要があります。これは、彼のチェックインを確認することで実行できます。ただし、これは人間の問題であるため、技術的な解決策はこれまでにしかできません。

score 9 · Accepted Answer

開発者に、2 週間以内に彼らの慣行を変更してほしいと伝えてください。さもなければ、会社の懲戒手続きを開始します。できる限りの支援を提供しますが、この人を変えることができないのであれば、その人はあなたの会社にはふさわしくありません。

score 8 · Accepted Answer

彼にビルドを「子守」させ、ビルドマネージャーになります。これにより、コードを開発する時間が短縮され (その結果、全員のパフォーマンスが向上します)、優れたビルドが必要な理由を学ぶことができます。
テストケースを適用する - 単体テストケースがないとコードを送信できません。テストケースが正しくコンパイルおよび実行されない場合、または存在しない場合は、タスクチェックイン全体が拒否されるように、ビルドシステムを変更します。

-アダム

score 8 · Accepted Answer

彼と話をしてみませんか？彼はおそらく実際にあなたを噛むことはありません.

score 7 · Accepted Answer

ここに海のシャンティからのいくつかのアイデアがあります。

Intro
   What shall we do with a drunken sailor, (3×)
   Early in the morning?
Chorus
   Wey–hey and up she rises, (3×)
   Early in the morning!
Verses
   Stick him in a bag and beat him senseless, (3×)
   Early in the morning!
   Put him in the longboat till he’s sober, (3×)
   Early in the morning!

など。「酔った船乗り」を「ずさんな開発者」に置き換えます。

score 7 · Accepted Answer

開発者ごとのテストコードカバレッジに関する統計を公開します。これは、彼と話した後になります。

score 5 · Accepted Answer

ご存知のとおり、これは彼を選び出すことを避け（私はあなたが彼と話す必要があることに同意しますが）、社内でテストファーストプロセスを実装する絶好の機会です。ルールが明確でなく、期待がすべての人に知られている場合、あなたが説明することはそれほど珍しいことではないことがわかりました。テストファースト開発スキームを実行することは私にとってうまく機能し、コード品質を向上させることがわかりました。

score 5 · Accepted Answer

使用しているバージョン管理システムの種類によっては、チェックインを許可する前にコードが特定の要件を通過するように強制するチェックインポリシーを設定できます。Team Foundation Server のようなシステムを使用している場合は、チェックインのコードカバレッジと単体テストの要件を指定できます。

score 4 · Accepted Answer

彼らは品質よりもスピードに過度に焦点を合わせているかもしれません。

これにより、一部の人々が問題を急いでリストをクリアし、後でバグレポートに何が返ってくるかを確認するように誘惑する可能性があります。

このバランスを修正するには：

問題追跡システムで一度に2、3のアイテムのみを割り当てます。
彼らが「完了」したものをできるだけ早くコードレビューしてテストし、問題が発生した場合はすぐに戻ってくるようにします
アイテムが適切に機能するのにかかる時間についてのあなたの期待について彼らに話してください

score 3 · Accepted Answer

ピアプログラミングは別の可能性です。彼がチームの他の熟練した開発者と一緒にいて、品質基準を満たし、手順を知っている場合、これにはいくつかの利点があります。

経験豊富な開発者と一緒に、彼は自分に期待されていることを学び、自分のコードと期待を満たすコードの違いを確認します。
他の開発者は、テストファーストポリシーを強制することができます。つまり、テストが作成されるまでコードの作成を許可しません。
同様に、他の開発者は、コードがチェックインされる前にコードが標準に準拠していることを確認できるため、不正なチェックインの数を減らすことができます。

もちろん、これらすべては、会社と開発者がこのプロセスを受け入れる必要がありますが、そうでない場合もあります。

score 3 · Accepted Answer

この問題に対して、人々は想像力豊かでずさんな答えをたくさん思いついたようです。しかし、これはゲームではありません。彼を「名指しし恥をかかせる」ために精巧な仲間からの圧力システムを考案しても、問題の根源に到達することはありません。なぜ彼はテストを書かないのですか？

直球でいいと思います。あなたが彼と話をしたと言っているのは知っていますが、なぜ彼がテストを書かないのかを調べてみましたか? 明らかにこの時点で、彼は自分がそうすべきであることを知っているので、彼が言われたことをしていないのには何らかの理由があるに違いありません. 怠惰ですか？怠慢？プログラマーはエゴと強い意見で有名です。おそらく彼は、何らかの理由でテストは時間の無駄だとか、自分のコードは常に完璧でテストは必要ないと確信しているのでしょう。彼が未熟なプログラマーである場合、彼は自分の行動の意味を完全には理解していない可能性があります。彼が「成熟しすぎている」場合、彼は自分のやり方に固執しすぎている可能性があります. 理由が何であれ、それに対処してください。

意見の問題になる場合は、自分の個人的な意見は脇に置いて、ルールに従う必要があることを彼に理解させる必要があります. 彼がルールに従うと信頼できない場合、彼は交代することを明確にしてください。彼がまだそうしない場合は、それを行います。

最後にもう 1 つ - 彼の変更の結果として発生した問題とともに、すべての議論を文書化してください。最悪の場合、決定を正当化することを余儀なくされる可能性があります。その場合、文書による証拠は非常に貴重です。

score 2 · Accepted Answer

他のすべてが失敗しない限り、私は通常これを支持しません...

場合によっては、公開されている開発者ごとのバグ数のグラフが、良好な結果を得るのに十分な仲間からの圧力をかけることがあります。

score 2 · Accepted Answer

キャロットを試して、楽しいゲームにしましょう。
例: Hudson の継続的インテグレーションゲームプラグイン
http://wiki.hudson-ci.org/display/HUDSON/The+Continuous+Integration+Game+plugin

score 2 · Accepted Answer

彼を自分の開発ブランチに固定し、完全にテストされていることがわかっている場合にのみ、彼のものをトランクに持ち込みます。これは、GIT や Mercurial などの分散ソース管理ツールが優れている場所かもしれません。SVN では分岐/マージのサポートが強化されていますが、管理にそれほど苦労することはないかもしれません。

編集

これは、あなたが彼を追い払うことができないか、彼のやり方を変えることができない場合にのみです. この振る舞いを (変更または発砲によって) 止めることができない場合は、チームの残りのメンバーを彼のコーディングの悪影響から緩衝することが最善の方法です。

score 2 · Accepted Answer

ポリシーに影響を与えることができる場所にいる場合は、いくつかの変更を加えてください。チェックインの前にコードレビューを行い、テストを開発サイクルの一部にします。

score 2 · Accepted Answer

とてもシンプルに思えます。それを要件にして、それができない場合は、彼を置き換えます。なぜあなたは彼を飼うのですか？

score 1 · Accepted Answer

何かが「完了」したと見なされる前に、実行されたテストケースを成果物の1つにします。

テストケースを実行していない場合、作業は完了していません。文書化されたテストケースを実行する前に期限が過ぎている場合、彼は時間どおりに配達されておらず、結果は彼が行った場合と同じになります。開発が完了していません。

あなたの会社の文化がこれを許さず、正確さよりもスピードを重視している場合、それがおそらく問題の根源であり、開発者は単に実施されているインセンティブに対応しているだけです-彼は多くのことをしたことで報われています正しく少ないものではなく、中途半端なもの。

score 1 · Accepted Answer

機能ごと、バグ修正ごと、開発チームごとなど、いくつかのロジックに基づいて、開発者をコードのブランチに配置します。次に、不正なチェックインがそれらのブランチに分離されます。ビルドを実行し、テストブランチにマージし、問題を見つけて解決し、リリースをメインブランチにマージします。

または、その開発者のコミット権を削除し、コミットする前に、レビューとテストのためにコードを若い開発者に送信してもらいます。それは手順の変更を動機付けるかもしれません。

score 1 · Accepted Answer

そのソフトウェアを担当したプログラマーの名前を使用して、コードで見つかったエラーを含むレポートをまとめることができます。

彼が合理的な人物である場合は、その報告について彼と話し合ってください。

彼が自分の「評判」を気にかけている場合は、レポートを定期的に公開し、すべての同僚が利用できるようにします。

彼が「権限」だけを聞いている場合は、報告を行い、問題を上司にエスカレーションします。

とにかく、外から見たときの見た目が悪いことに気づいたら、行動が変わるのをよく見かけます。

ねえ、これは私がxkcdで読んだものを思い出させます:)

score 1 · Accepted Answer

チェックイン前に自動ユニットテストまたは手動ユニットテストを作成することを指しますか？

あなたの店が自動化されたテストを書かないなら、機能しないコードの彼のチェックインは無謀です。チームに影響を与えていますか？正式なQA部門はありますか？

自動化された単体テストを作成している場合は、コードレビュープロセスの一部に単体テストも含めることをお勧めします。レビュー中に、コードが標準に従って受け入れられないことが明らかになります。

あなたの質問はかなり広いですが、私はいくつかの方向性を提供したいと思います。

私はフィルに同意します。最初のステップは彼と個別に話し合い、品質の重要性を説明することです。品質の低さは、多くの場合、チーム、部門、および会社の文化に関連している可能性があります。

score 1 · Accepted Answer

あなたはここでいくつかの役に立つ答えを見つけるかもしれません：ジュニアプログラマーにテストを書かせる方法は？

score 1 · Accepted Answer

残念ながら、あなたがすでに彼と何度も話し、書面による警告を与えているなら、私は彼をチームから排除する時が来たと言うでしょう.

score 1 · Accepted Answer

自動ビルドを設定している場合は、失敗の通知ができるだけ明白で煩わしいものであることを確認してください。開発の共通領域にあるウォールボードまたは音声通知は、良い出発点です。次に、ビルドが壊れていることを確認し、違反者が問題を修正するまで誰もコードをチェックインしないようにします。

確かに、これは彼のコードがビルドを壊した場合にのみそれをキャッチしますが、これに対して継続的にスポットライトを当てるようにという仲間の圧力は、ほとんどの人にとってインセンティブになります. これで解決しない場合は、人事部を通じて利用可能な次の懲戒処分を行ってください。あなたはすでに彼と話しました、あなたはすでに書面による通知をしました-次のステップが何であるかを調べてください. 自分の道を行く開発者は、先見の明があるか、チームプレーヤーではないかのどちらかです。私は個人的に、その点で先見の明のある人と一緒に仕事をする喜びを味わったことがありません。

score 1 · Accepted Answer

開発者がコンパイルできないものをチェックインするたびに、瓶にいくらかのお金を入れてください。チェックインする前によく考えてください。

score 1 · Accepted Answer

その人にトイレをきれいにさせます。陸軍で働いた。そして、インド料理をたくさん食べる人とグループで仕事をすれば、彼らが列に並ぶのにそれほど時間はかかりません.

しかし、それは私だけです...

score 1 · Accepted Answer

あなたが彼と真剣に話し、なぜこれが大したことなのかを彼が理解するために必要なすべてのサポートとトレーニングを彼に与えたなら、私は彼を追い払うことを検討します（それがどのように機能するかは、あなたが世界のどこにいるかによって異なります.それは）。彼をクビにする以外に何かを望んでいるとおっしゃっていたのは知っていますが、問題に対する「良い」解決策がない場合もあります。

厳しいプログラマーでなくても、ソフトウェア開発を真剣に考えていない会社を去ることについて常に話します。

もしこれが合理的であるなら、企業は、あらゆる合理的な機会を与えられたにもかかわらず、明らかにソフトウェア開発を真剣に考えていない開発者を我慢しなければならないのでしょうか?

score 1 · Accepted Answer

これは少し変わったかもしれないので、あなたが試したことと得られた結果について少し詳しく説明することをお勧めしますが、ここに私の最初の提案があります:

それは何らかのテストですか、それとも総合的なテストですか？やみくもにコーディングしてテストをまったく行わない人もいますが、これはかなりまれです、IME. 通常、いくつかのテストが行われますが、包括的なテストとなるほとんどのケースをカバーするには十分ではありません。
グループダイナミクスが役立つ場合があります。彼はチームの一員であり、チームの見解がここで役立つかもしれないと思います. ある意味で、これは仲間からの圧力を得ようとしていますが、これは通常は悪いことですが、時には良い方法で使用することもできます。
警告はどの程度正確に記載されていましたか? ある意味、これは幼稚に思えるかもしれませんが、あなたがテストとして考えていることは、彼のものと同じではない可能性があります. テストの存在と使用の証拠として、nUnit テスト、Excel スプレッドシート、彼のコンピューターからのログ、またはその他のものが必要ですか? あなたが説明したことから、彼があなたの意図を理解し、テストを使用し、そうすることの証拠を提供しようとしていたことを確認するものは何もありません.
チェックインポリシーに関する質問。私の現在の職場など、頻繁にコミットすることを推奨する場所もあります。これは、テストなしでコードをコミットすることを意味する場合があります。よく知られており、受け入れられ、よく守られているポリシーはありますか? それはここで別の側面です。

score 0 · Accepted Answer

何をテストするか、どのようにテストするか、いつテストするか（チェックイン前、プッシュする前、トランクにマージする前）について、チーム内で合意を確立します。

次に、チェックインが一連の基準を満たしていない場合、チームが合意したコードが満たす必要があり、単にそれをロールバックして、開発者に修正を依頼します。チェックインのロールバックは、チェックインの品質が低い場合でもコードベースの品質を維持するための非常に効果的な方法であり、コードがチームによって設定された基準を満たしていないことを人々に知らせるための軽量な方法でもあります。。

ロールバックの良いところは、コードをチェックインするのが本当に簡単なことです。ロールバックをロールバックし、問題を修正してから、変更をもう一度確認するだけです。

私は、誰にも知らせない非常に客観的な方法でそれを行うように注意します。これは、問題のあるメンバーだけでなく、チーム全体に適用し、コードの品質を重視し、チェックインされるコードを罰としてではなく、チームが設定した基準を満たすことに重点を置くことを意味します。。

score 0 · Accepted Answer

私は（他の人として）提案します：

コードレビュー、
ペアプログラミング、
SCMコミットポリシー。

score 0 · Accepted Answer

NCover + Cruise Control、自動レポートを送信すると、コードカバレッジをチェックインするときにダウンすることを証明できます。

score 0 · Accepted Answer

このユーザーには何もアップロードする権限がないことをバージョン管理システムに伝えることができるため、誰かにアップロードを依頼する必要があります。それは彼に教えるべきです。

score 0 · Accepted Answer

あなたは彼が彼のコードをテストしないと言いました。これは、彼が単体テストを作成しないことを意味しますか？または、彼は自分のコードをまったくテストしていませんか？

彼が自分のコードをまったくテストしない場合、これは彼の開発における根本的な問題です。あなたが書いたコードをテストすることは仕事の一部です。コードをテストしない開発者は受け入れられず、プロジェクトの速度を低下させています。テストは、開発者（いわゆるスターでさえ）の職務記述書の一部です。

ただし、彼がコードをテストしているが、「正しい」数の自動化された単体テストを作成していない場合、これは別の問題であり、別の解決策が必要です。他の人が言っているように、あなたは理由を見つけてそれを修正する必要があります。コードレビューは、これらの問題を見つけるための良い方法です。しかし、あなたはすでに問題を知っているようです。

score 0 · Accepted Answer

開発者と話しているとおっしゃいましたが、テスト手順について尋ねたかどうかを知りたいです。彼らが別の会社から来た場合、すべてのコードを書き、チェックインし、テストし、コードの最終バージョンをチェックインすることに慣れている可能性があります。彼らがチェックインを作業を保存する別の方法と見なしている場合。

ただし、彼らがあなたの会社にかなりの期間 (たとえば、少なくとも 6 か月) 在籍している場合、彼らはあなたのやり方に慣れているはずであり、これはそれほど長くは有効な言い訳にはなりません。

score 0 · Accepted Answer

話し合いがうまくいかない場合は、テストを伴わずにチェックインされたコードが単にリポジトリから取り消されるというポリシーを導入してください。コードを数回書き直す必要があると、メッセージが表示される場合があります。

score 0 · Accepted Answer

単純。開発者の責任で、報告されたバグを検証し、再現するバグを修正します。その人に新機能の作業をさせないでください。

脳が半分しかない人は、単体テストコードが原因で発生する骨の折れるバグによって、すぐに一定レベルのフラストレーションを感じます。さらに、個人の全体的なスキルが大幅に向上する可能性があります。

score 0 · Accepted Answer

コードレビューと単体テスト。

(多くの人と同じように) ささいな変更をチェックインして物事を壊す人だったので、単体テストは、全体をすばやく実行できるように設定されている場合、テストしないという言い訳を取り除くと言えます。誰がコードを壊したか (まともな VCS を想定)。もちろん、非公式のコードレビューでは、年長の (そして有能な) 同僚によってレビューされた簡単なコードをチェックインしましたが、それでもコードベースは壊れています。

score 0 · Accepted Answer

これがあなた、会社、チームにとって重要であることを彼に明確に伝えたようですね。

彼の行動の背後にあるものを見つける必要があると思います - 彼はあなたの言うことを聞いていないだけですか? たぶん、あなたはそれを言う別の方法を見つける必要があります.

多分彼は納得していないでしょう - それにはいくつもの理由があるかもしれません - 根本的な理由を見つけてそれに対処してください.

score 0 · Accepted Answer

彼のコードのコードレビューでさえうまくいかない場合は、別の「素晴らしい」( ;) ) コードをレビューするタスクを彼に与えて、そこから彼自身の問題に関連付けて、彼のコードをそのひどい部分と比較するように依頼してください。コードの。

通常、この種の人々の問題は自己実現にあるため、どのように彼自身のコードの問題を理解させようとしても、問題は解決しません。彼自身が気づかない限り、それはうまくいきません。これはもちろん、彼を解雇するオプションがない場合は、実際に彼を手入れしたい.

score 0 · Accepted Answer

それは依存します。

彼のコードは機能しますか? 彼はあなたのチームで最も生産性の高いメンバーですか、それとも最も生産性の低いメンバーですか? コードは他のコードよりもバグが多いですか? 彼/彼女の貢献はどれほど価値がありますか?

彼が高品質のコードを生成する優れたパフォーマーである場合、誰が気にしますか。一方、彼/彼女がバグの多いコードを作成している場合は、その人を座らせて話し、結果を説明し、彼らが参加するか、参加しないかのどちらかです.

score 0 · Accepted Answer

それについて彼らと話してみましたか？最初の一歩としては悪くないかもしれません。また、問題が解決しない場合の手順 2 についての手がかりが得られる場合もあります。

score 0 · Accepted Answer

あなたのスペルをテストしてください！あなたは「彼らのコード」を意味していたと思います。

彼に話しかける。それが問題であることを彼に知らせてください。
コードの品質について話し合うグループミーティングを行います。
それでも問題が解決しない場合は、チェックインする前にコードをチェックするよう強制します。
それまでに彼がヒントを得られない場合は、彼を手放す必要があります。

score 0 · Accepted Answer

コードカバレッジツールを導入し、単体テストでカバーされていないすべてのコードの自動レポートをビルドサーバーから生成します。彼の名前はボードの一番下になります。

ボードは毎週印刷して、誰もが見られる場所に貼る必要があります。

彼のカバレッジが 85% になるまで、彼に何か新しいことを与えるのをやめる

取締役会のトップにいる人に最も興味深い仕事を与えます。

次の書面による警告を特定のコードカバレッジ要件に関連付けます。そうすれば、彼が失敗した場合に明確な却下理由が得られます。

score 0 · Accepted Answer

彼と話してもうまくいかず、彼を解雇できない場合、彼は怠け者か不合理です。王道を進んでその男を説得できない場合は、彼の痛いところを殴って、彼の給料を減らし始めてください。または、本当に彼を罰したい場合は、彼にコードを維持させます。

score 0 · Accepted Answer

品質チームに再割り当てされ、文書化のみを行うことを彼に伝えます。それは私が率いていたチームで何度もうまくいきました...そしてそれがうまくいかない場合は、彼のコードをテストする誰かを見つけてください! ..待って、それは不自由だ...ああ、そう..彼を解雇!!!

testing - 自分のコードをテストしない開発者をどうしますか?

49 に答える 49

Related

Reference