何年も経った今でも悪いコードを書いている従業員に固執すべきでしょうか?[閉まっている]


13

私はこの質問をC ++プログラマーに投げかけています。a)C ++プログラマーだけが、例の技術的なメリットを判断できるからです。b)プログラマーだけが、このようなコードを書く他のプログラマーの気質を感じます。

人事部長と取締役は、単に現場で証拠を見ているだけで問題があることを認識しています。問題のプログラマーにより多くの時間を与えるかどうかは私の呼びかけです。エラーの多くは非常に基本的なレベルです-私の質問(プログラマーにとって)は、上級C ++開発者であると公言する人に、現在のコードのサンプルに基づいて疑いの利益を与えるべきかどうかです。非プログラマー-C ++プログラミング以外の人でも-これについて判断することはできません。

背景として、私は定評のある会社の開発者を管理するタスクを割り当てられました。彼らにはすべてのC ++コーディングを専門とする単一の開発者がいます(永遠に)が、作業の質はひどいものです。コードのレビューとテストにより、多くの問題が明らかになりました。最悪の事態の1つはメモリリークです。開発者はコードのリークを一度もテストしたことなく、わずか1分でアプリケーションが多くのMBをリークする可能性があることを発見しました。ユーザーは巨大な減速を報告しており、彼の見解は「それは私とは何の関係もありません-彼らが終了して再起動すれば、それは再び良いことです。」

私は彼にリークを検出して追跡するためのツールを提供し、ツールの使用方法、問題が発生した場所、およびそれらを修正するために何をすべきかを実証するために何時間も座っていました。私たちは6か月後、新しいモジュールを作成するように彼に割り当てました。私たちがより大きなコードベースに統合される前に私はそれをレビューし、以前と同じ悪いコーディングを発見することに落胆しました。私が理解できないと感じるのは、一部のコーディングがアマチュアよりも悪いということです。たとえば、彼は別のクラス(バー)のオブジェクトを作成できるクラス(Foo)が必要でした。彼は、フーがバーへの言及を保持することを決めました、例えば:

class Foo {
public:
    Foo(Bar& bar) : m_bar(bar) {}
private:
    Bar& m_bar;
};

しかし(他の理由で)彼はFooのデフォルトコンストラクターも必要とし、彼の初期設計に疑問を呈するのではなく、このgemを書きました。

Foo::Foo() : m_bar(*(new Bar)) {}

そのため、デフォルトのコンストラクターが呼び出されるたびに、Barがリークされます。さらに悪いことに、Fooはヒープから他の2つのオブジェクトにメモリを割り当てますが、デストラクタやコピーコンストラクタを作成しませんでした。したがって、Fooの割り当てごとに3つの異なるオブジェクトが実際にリークし、Fooがコピーされたときに何が起こったのか想像できます。そして、それは良くなるだけです-彼は他の3つのクラスで同じパターンを繰り返したので、1回限りのスリップではありません。非常に多くのレベルで概念全体が間違っています。

これが完全な初心者から来た場合、私はより多くの理解を感じるでしょう。しかし、この男は長年にわたってこれを行っており、過去数か月にわたって非常に集中的なトレーニングとアドバイスを行ってきました。彼はほとんどの時間、メンタリングやピアレビューなしで働いてきましたが、彼は変わらないと感じ始めています。だから私の質問は、そのような明らかに悪いコードを書いている人に固執しますか?


15
すでに彼が悪いコードを書いているのを見たなら、なぜ彼を監督せずに6ヶ月間彼に彼のたわごとを書かせたのですか?
ビリーマクナゲッツ

4
IMOは、誰かがしばらく悪い仕事をしているのを見たとき、たとえそれがデバッグ/修復だけであっても、あなたが彼を一人で働かせることはできません。彼をあなたの会社に連れて行くことがあなたの意志であるなら、あなたは彼を監督し、彼からまだ悪い結果を得ているかどうかを確認しなければなりません。彼を見ないで6ヶ月間彼を一人で働かせることはIMOの悪い管理です。
ビリーマクナゲッツ

3
@ user94986その後、彼と一緒に時間を過ごし、彼の習慣が悪いと説明した場合、彼に注意を払う必要があります。
ビリーマクナゲッツ

4
メモリリークが問題であると彼が考えていない場合、それらを回避し、これを支援するツールを提供する方法を彼に教える意味はありません。主な問題は、製品の目標と要件を誤って理解していることです。
maxim1000

2
この質問は、私たちがせいぜい提供することが問題となる人事に関する法律上のアドバイスが実質的に何であるかに関するものであるため、トピックから外れているように見えます。
ワールドエンジニア

回答:


22

私のアドバイスは、この特定の例について彼に立ち向かい、彼の言うことを確認することです。彼がコードに悪い点があることを否定するなら、あなたができることはほとんどないのではないかと思う。彼が間違いを犯したことを受け入れた場合(たとえそれについて防御的であっても)、少なくとも改善の余地があります。彼を改善するための時間と労力を受け入れた場合、あなたまたは上級プログラマーは、これらの傾向がすべて平らになるまで、彼と一緒に座って一緒にコーディングする必要があります(この人を少なくとも1か月間捧げる準備をします)。

悪いプログラマー、私は通常一緒に働くことができますが、改善できないプログラマーはできません。


12
「悪いプログラマー、私は通常一緒に働くことができますが、改善できないプログラマー、私はできません。」の

ええ、また、私はそれがかなり深刻であることを男に知らせます。彼は何年も問題があることを知らされていないか、認められていないようです。彼がやるべきではないことの例と、それがアプリの品質にどのように影響したかを示す準備ができた会話に来てください。それでも彼が自分のコードの問題に気が進まないのであれば、おそらく彼を手放すでしょう。そして、もし彼がそうするならば、私は彼に彼の行為をまとめるために多くの時間を与えないでしょう。会社での彼の将来が危機にatしており、彼がC ++開発者にとって非常に重要なスキルに欠けていることを強調する必要があります。
エリックReppen

@ErikReppen私も同意しますが、プログラマーは地球上で最も頑固なタイプの人間になることができると思います。あなたがあまりにも強くプッシュした場合、彼は単に防御的であるために、彼のコードに関する問題を否定するかもしれません。状況の重大さを強調することは重要だと思いますが、私はまだ彼に同情しようと思います。あなたのプログラム?」
ニール

@Neil頑固な壁を抜ける唯一の方法は、お尻を蹴ることです。そして、私はその方程式の頑固なお尻側としての経験から話しています。それはそれは、はい、私は少し柔らかめに行くだろう、彼は彼のコードに問題があることを聞いたことだ最初だ場合、言ったが、彼らは、少なくとも一回前に問題を通信しようとしたようですね
エリックReppen

@ErikReppenたぶん、しかしあなたは彼があなたの尻尾から抜け出すためだけに形を整える危険があります。そのレートで、「シェイプアップ、または解雇されました」と言うこともできます。少なくともこのアプローチは、彼が自分の過ちについて良心的であるかどうかを調べます。
ニール

18

だから私の質問は、そのような明らかに悪いコードを書いている人に固執しますか?

いいえ。メモリ管理の基本的な理解を欠いたプロのC ++開発者を解雇します。

JavaやC#から来ている人、または何かをするなら、私は彼らにいくらかの緯度を与えますが、これは純粋に無能です。


9
この答えがどのように支持されるか理解できません。誰かを解雇することは軽視すべき問題ではありません。
フローリアンマーゲイン

3
@FlorianMargaine-確かに、これは明確なケースのようです。この従業員は、メモリリークやセキュリティの脆弱性のために、売上の損失にどのくらいの費用を会社に負っていますか?このがらくたをテスト/修正するのにどれだけの時間を無駄にしましたか?OPにベビーシッターをさせるにはどのくらいかかりますか?他のプログラマーが彼の単なる存在にどれだけ苦しんでいるのでしょうか?従業員が不合理な量のドメイン知識(または恐black)を持っている場合を除き、それらを交換するコストが高くなる方法はありません。
テラスティン

1
@FlorianMargaine、このタイプの従業員は、十分に解雇されず、技術的負債を修正するのが困難なため、会社を不自由にします。それは大きな赤いライトで「彼らは気にしないので、なぜ私たちはそうすべきなのか」と言う。あなたが本当に欲しい従業員が何を言うか知っていますか?「...しかし、私は気にするので、そうする場所に行く必要がある」。悪い人はすでに気にしなかったので、彼らはあなたのオフィスに残ります。生産性を損なう人々は、彼らが貢献する以上に削除しなければなりません。これは軽く取られる選択ではありませんが、実際には明確な行であり、行動しなかったことは明確な行動です。
JMベッカー

13

あなたの質問の広範な部分に答えることはできません。つまり、その従業員を保持または解雇する必要があります。従業員を解雇することは困難ですが、それはこのようなコミュニティの範囲外の決定です。

質問を更新して、C ++プログラマーへの回答を制限しました。私の背景/資格について:私はCで歯を切って、C ++、C#、およびJavaでコーディングできます。スレッド間の競合状態を追いかけるのは楽しいと思うので好きです。はい、少しいじっています。

あなたの答えと決定はこれを取り巻くものです。誰かが変わることができるかどうかは、個人と、彼らは変更したいです。

しかし、あなたのいくつかの質問から始めましょう:

  1. あなたが言及したコードと例について彼に尋ねましたか?レビューに対する彼の印象はどうでしたか?
  2. この6か月の間に、メモリ操作を理解し、コードにメモリリークがないことを確認することについて具体的に説明しましたか?
  3. 彼が進歩しているかどうかを示すために、これらの6か月の間にかなり頻繁にフィードバックを提供していましたか。
  4. 彼の古いコーディング方法は、新しいコードではもはや受け入れられないことを明示的に言いましたか?

これらすべての質問に「はい」と答えることができることを確認する必要があります。そうでない場合、彼と通信するためにあなたの側にまだ証拠の負担があります。

あなたの最近のレビューに対する彼の反応は、最も重要な部分になるでしょう。

彼が試みていて、進行の兆候を示している場合は、メンタリングプロセスを確認する必要があるかもしれません。どちらかといえば、おそらく彼が経験豊富なプログラマーとペアを組むことを検討する必要があります。そうすれば、彼は設計の決定をしている間にすぐにフィードバックを得ることができます。私はペアプログラミングのファンではありませんが、このような場合には非常に役立ちます。古いコードをますます改訂するために彼を絶えず派遣することは、必ずしも学習のための実用的なルートではありません。

彼が試みていない場合は、彼の動機をよりよく理解する必要があります。彼はもっと努力する必要があることを理解していませんでしたか?彼はただ気にしませんか?彼のスキルがより良く適合し、彼がより興味を持っているチームの他の領域はありますか?彼が試してみたくない場合は、その理由を理解する必要があります。

そこから、彼変更したいかどうか、そして彼変更できるかどうかがわかります。変更したくないということは、変更できないことに相当します。欲望とある程度の進歩があれば、あなたが彼をリハビリしようとしている方法を変えることを強く検討してください。


1
+1「古いコードをますます改訂するために彼を送り続けることは、必ずしも学習のための実用的なルートではない」
ビル

最後の段落の+1。誰かによって達成された進歩と努力の対比は、誰かがパフォーマンスの判断に考慮する必要があることを導くことに投資されました。
マルジャンヴェネマ

10

チームの問題は彼の悪いコードだけではないのではないかと思います。

  1. 誰が彼のコードをレビューしますか?メモリリークの脆弱性を持つコードを受け入れるための警告なしに、なぜ彼は逃げたのですか?
  2. ストレステストでこの問題が検出されなかったのはなぜですか?それらを使用しますか?はいの場合、なぜ彼らは働いていないのですか?
  3. 彼は長い間無人で放置されていました。どうして?
  4. 彼はあなたが与えたツールを使用していません。どのようにして適切なツールを使い始めたのですか?

あなたは彼が長期間会社にいたと言います。そのような人を雇うことはめったに良いアイデアではありません(彼がウォーリータイプの従業員でない限り)。クライアントのニーズ、所有する製品などに関する彼らの知識は、多くの場合、彼らが書くコードよりもはるかに価値があります。

ソリューション:

  • 避けるべきことを学ぶために彼をQAに移動します
  • エラーを指摘できる人とプログラミングをペアリングする
  • 彼のコードに対するQAの取り組みを拡大
  • 彼にストレステストを書かせてください、彼が彼の開発マシンが10kのオブジェクトを作成して破壊した後にクラッシュするのを見るならば、多分彼は学ぶでしょう
  • 上記のいくつか/すべて:)

3

誰かを解雇するという決定は、誰にとっても難しい決定です。しかし、あなたの状況はいくつかの要因によって悪化します:

  1. この開発者は数年間会社にいたようです
  2. 開発者はすべての企業のC ++コードを記述します
  3. 誰も開発者と貧しいコードのレベルについて議論したことがないようです
  4. 新しいマネージャーとして、開発者が会社の内外で誰について/何を知っているのか、開発者を解雇することの政治的影響についてはまったく知りません

つまり、過去6か月間、開発者に彼のやり方の誤りを見せており、彼の新しいコードはまだ改善されていません。

この段階では、積極的な管理を開始して、3か月以内に

  • 彼が何をしているかを知っているまともなC ++プログラマー

または

  • 開発者を終了しました。

開発者と一緒に座ってこれを行うには、執筆/電子メールの何が悪いのかを説明し、開発者がどのように改善できるかを説明し、予想される改善が実現しない場合は3で終了することを非常に明確に述べますヶ月。

また、この点から、3か月間だけでなく、会社での彼の残りの雇用でも改善が期待されることを非常に明確にする必要があります。

また、あなた自身のマネージャーと人事部(もしあれば)に通知する必要があります。

このプロセスでは、開発者を積極的に管理し、1〜2日ごとにタスク/コードをレビューし、それらが最初から最新のものであることを確認します。


1

あなたが彼の貧弱な出来映えをどれほど真剣に受け止めているかはっきりしていない(つまり、彼が絶対的な必要性ではなく改善したい場合、彼と一緒に過ごした時間を選択肢として見る可能性がある)、または彼は信じられないほど悪い持続不可能な態度。この問題に対する彼の立場を検討していることがこの開発者にまだ明らかでない場合は、それを詳しく説明する必要があります(あなたのリーダーシップは終了する権限で大丈夫だと仮定します)。ショックは変化をもたらすことを期待しています。

ただし、雇用の決定はこの男よりもはるかに広い意味を持ちますが、チームへの影響を考慮する必要があります。彼の態度が繁栄することを許されるなら、それは他者からのresみを提供するか、または他の人にこの種のものも大丈夫だと感じさせることができます。しかし、チームの立場から言うと、もし彼が行けば、それは正しい理由によるものであり、彼には十分な改善の機会があったことは絶対に明確でなければなりません。

何年も前に私が取り上げた宝石の1つは、他の人にはない技術的な知識を持っている人たちが、経営陣に余裕を持たせることができるという事実です。チームにとっては悪いことです。あなたは唯一のC ++開発者を失うことを恐れるかもしれませんが、それらは置き換えることができます。明らかに、彼がリリースされた製品をよく知っている場合、固有のリスクがありますが、しばしば、私は一見かけがえのない製品/技術知識を持つ人々が予想以上に簡単に交換されるのを見てきました。多くの場合、チームや組織は、最初は埋めるのが難しいと思われるギャップを埋めることができます。もちろん、C ++のスキルや、置き換えるのが難しいと思われる組織固有の知識がない場合は、問題ははるかに少なくなります。


1
彼のマネージャーが彼を解雇することを考えていることを知るために、私はこの男が絶対に驚いたと思う。あなたがちょうど板で頭を打ち、平らにならなければならない一部の人々は、彼らが改善しなければならないか、解雇されると彼らに言います。
HLGEM

0

もちろん、そうすべきではありません。これは慈善ではなく、仕事とお金を交換していることを忘れないでください。彼が取引の彼の側を保持していない場合、私は支払いを停止するトランザクションのように。


-1

彼にチャンスを与えたい場合は、メモリリークに関するメトリックを収集する標準化されたテストを開発します。毎週、彼の進捗状況を監視し、変更したコードを確認して、改善を求めます。彼がその時点で管理できない場合、役に立たない悪意のある人を解任します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.