我们应该坚持让一名员工在多年后仍在编写糟糕的代码吗？[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 6年前关闭。 我将这个问题提交给C ++程序员，因为：a）只有C ++程序员才能判断示例的技术优点；b）只有一个程序员才会有另一位这样编写代码的程序员的气质。 人力资源部和董事意识到存在问题仅仅是因为他们看到了现场的证据。我打电话给我们是否给问题程序员更多时间。许多错误都处于非常基本的水平上-我（对程序员）的问题是，是否应该根据自己当前代码的样本，对自称是高级C ++开发人员的人们是否会产生怀疑。非程序员-甚至是C ++编程以外的人-也无法对此做出任何判断。 作为背景知识，我被分配了为一家老牌公司管理开发人员的任务。他们只有一个开发人员，专门研究所有C ++编码（从此以后），但是工作质量却很糟糕。代码审查和测试发现了许多问题，最严重的问题之一是内存泄漏。开发人员从未测试过自己的代码是否泄漏，而且我发现应用程序在使用一分钟后可能会泄漏许多MB。用户正在报告巨大的速度下降，而他的看法是：“与我无关，如果他们退出并重新启动，那一切都很好。” 我给他提供了检测和跟踪泄漏的工具，并与他坐了许多小时，以演示如何使用这些工具，出现问题的位置以及如何解决这些问题。我们已经走了6个月了，我指定他编写一个新模块。在将其集成到更大的代码库中之前，我进行了审查，并且很沮丧地发现与以前相同的不良编码。我无法理解的部分是，某些编码比业余编码差。例如，他想要一个可以填充另一个类（Bar）的对象的类（Foo）。他决定Foo将保留对Bar的引用，例如： class Foo { public: Foo(Bar& bar) : m_bar(bar) {} private: Bar& m_bar; }; 但是（出于其他原因）他还需要Foo的默认构造函数，并且他没有质疑他的最初设计，而是写了这个gem： Foo::Foo() : m_bar(*(new Bar)) {} 因此，每次调用默认构造函数时，都会泄漏Bar。更糟的是，Foo从堆中为其他两个对象分配了内存，但他没有编写析构函数或复制构造函数。因此，每个Foo分配实际上都会泄漏3个不同的对象，您可以想象复制Foo时发生了什么。而且-只会变得更好-他在其他三个班级上重复了相同的模式，所以这不是一次过的失败。整个概念在很多层面上都是错误的。 如果这是一个新手，我会感到更多的理解。但是这个家伙已经这样做了很多年，并且在过去的几个月中一直非常专注于培训和建议。我知道他大部分时间在没有指导或同行评审的情况下工作，但我开始感到他无法改变。所以我的问题是，您会坚持与正在编写如此明显的不良代码的人吗？