何年も経った今でも悪いコードを書いている従業員に固執すべきでしょうか？[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 私はこの質問を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回限りのスリップではありません。非常に多くのレベルで概念全体が間違っています。 これが完全な初心者から来た場合、私はより多くの理解を感じるでしょう。しかし、この男は長年にわたってこれを行っており、過去数か月にわたって非常に集中的なトレーニングとアドバイスを行ってきました。彼はほとんどの時間、メンタリングやピアレビューなしで働いてきましたが、彼は変わらないと感じ始めています。だから私の質問は、そのような明らかに悪いコードを書いている人に固執しますか？