我们应该坚持让一名员工在多年后仍在编写糟糕的代码吗？[关闭]

我将这个问题提交给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时发生了什么。而且-只会变得更好-他在其他三个班级上重复了相同的模式，所以这不是一次过的失败。整个概念在很多层面上都是错误的。

如果这是一个新手，我会感到更多的理解。但是这个家伙已经这样做了很多年，并且在过去的几个月中一直非常专注于培训和建议。我知道他大部分时间在没有指导或同行评审的情况下工作，但我开始感到他无法改变。所以我的问题是，您会坚持与正在编写如此明显的不良代码的人吗？

我的建议是就这个具体例子与他面对面，看看他怎么说。如果他否认代码有什么不好的地方，那么恐怕您无能为力了。如果他接受自己犯了一个错误（即使他对此有防御性），那么至少还有改进的余地。如果您接受改善他的时间和精力，那么您或高级程序员将需要与他坐下来一起编码，直到所有这些趋势被消除为止（准备将这个人奉献至少1个月的时间）。

我通常可以和一个糟糕的程序员一起工作，但是不能改进的程序员我却不能。

所以我的问题是，您会坚持与正在编写如此明显的不良代码的人吗？

不。我会解雇任何缺乏对内存管理基本了解的专业C ++开发人员。

如果是来自Java或C＃的人，或者我会给他们一些自由度，但这纯属无能。

我们无法回答您问题的大部分。即，您应该保留还是解雇该员工。解雇员工很困难，但这是在这样的社区的权限范围之外的决定。

您更新了问题，以将答案限制为C ++程序员。对于我的背景/资格：我用C扎根，可以用C ++，C＃和Java进行编码。而且我喜欢追逐线程之间的竞争条件，因为我认为这很有趣。是的，我有点“花哨”。

解决这个你的回答和决策包装：是否有人可以改变取决于个人和，如果他们想改变。

但是，让我们从您的一些问题开始：

1. 您是否问过他有关您提到的代码和示例的信息？他对这次审查有何印象？
2. 在这6个月中，您是否给他提供了有关了解内存操作并确保他的代码没有内存泄漏的详细信息？
3. 在这6个月内，您是否提供了合理的反馈，以表明他是否在进步。
4. 您是否明确指出他的旧编码方式已不再被新代码接受？

您需要确保可以对所有这些问题说“是”。如果不是这样，那么您与他沟通的责任仍然在于举证责任。

他对您最近的评论的回应将是最有说服力的部分。

如果他一直在努力，并且显示出一些进步的迹象，那么也许您需要检查您的指导过程。如果有的话，也许您需要考虑将他与经验更丰富的程序员配对，以便他在制定设计决策时可以立即得到一些反馈。我不喜欢结对编程，但是在这种情况下它可能非常有用。不断派遣他去对旧代码进行越来越多的修订并非总是可行的学习途径。

如果他没有尝试过，那么您需要更好地了解他的动机。他是否不明白自己需要加倍努力？他只是不在乎吗？团队中是否还有其他领域更适合他的技能，而他对此更感兴趣？如果他不愿意尝试，那么您需要了解原因。

从那里，您将知道他是否想要更改以及他是否可以更改。没有改变的欲望就等于不能改变。如果有愿望和一定程度的进步，那么就强烈考虑改变您试图使他康复的方式。

恐怕他的错误代码不是您团队中唯一的问题。

1. 谁在审查他的代码？为什么他在没有警告的情况下溜走而接受带有内存泄漏漏洞的代码？
2. 为什么压力测试没有发现这个问题？你用它们吗？如果是，那么为什么他们不起作用？
3. 他长时间无人值守。为什么？
4. 他没有使用您给他的工具。您是如何激励他开始使用适当的工具的？

您说他已经在公司工作了很长时间。解雇这样的人很少是一个好主意（除非他是沃利式的雇员）。他们对客户需求，您拥有的产品等的了解通常比他们编写的代码更有价值。

解决方案：

• 将他转移到质量检查中，让他了解如何避免
• 与可以指出他的错误的人结对编程
• 对他的代码进行了质量检查工作
• 让他编写压力测试，如果他发现自己的开发机器在创建和销毁10k对象后崩溃了，也许他会学
• 上面的一些/全部：)

做出开除任何人的决定对任何人来说都是艰难的决定。但是，您的情况会受到多种因素的影响：

1. 看来这位开发商已经在公司工作了几年
2. 开发人员编写所有公司的C ++代码
3. 似乎在您之前从未与开发人员讨论过不良代码的程度
4. 作为新经理，您不知道开发人员在公司/公司中了解谁/什么，以及解雇开发人员的政治后果是什么

也就是说，您在过去的6个月中一直向开发人员显示他的方式错误，并且他的新代码尚未改进。

在此阶段，您确实需要开始进行主动管理，以便在3个月内

• 一个体面的C ++程序员，知道他在做什么

要么

• 终止开发人员。

为了做到这一点，尽管您需要与开发人员坐下来，解释在撰写/发送电子邮件时出了什么问题，解释开发人员如何进行改进，并且非常明确地指出，如果没有实现预期的改进，那么他将被终止3几个月。

您还需要非常清楚，从现在开始，他在公司的其余工作将有望得到改善，而不仅仅是三个月！

您还应该通知自己的经理和人事部门（如果有）。

在此过程中，您将必须积极地管理开发人员并每1-2天检查一次任务/代码，并确保它们从头开始，详细说明未完成的任务并说明可以采取哪些措施来改进它们。

您可能不清楚您对他糟糕的做工的重视程度（例如，如果他想改善而不是绝对必要，那么他可能会看到您选择与他在一起的时间），或者他的情况非常糟糕不可持续的态度 如果尚不确定此开发人员正在考虑他在此问题上的立场，则需要说明（假设您的领导同意终止您的权限）。震荡有望带来变化。

雇佣决定的影响远不止这个家伙，您需要考虑对团队的影响。如果允许他的态度蓬勃发展，它可能会引起别人的不满或让别人觉得这种事情也可以。但是从车队的角度来看，必须绝对清楚，如果他离开了，那是出于正确的理由，他有足够的机会进行改进。

我几年前在课程中学习到的一颗宝石是这样一个事实，即具有其他人所不具备的技术知识的人可以带领管理层放松下来。对团队不利。您可能会担心失去唯一的c ++开发人员，但是可以将其替换。如果他对已发布的产品非常了解，显然会存在固有的风险，但是我经常看到那些看似不可替代的产品/技术知识的人比预期的更容易被替换。团队和组织通常可以填补最初似乎很难填补的空白。当然，如果他不具备您认为很难替代的c ++技能或特定于组织的知识，那么问题就少多了！

当然不应该。请记住，这不是慈善机构，您是在为工作兑换金钱。如果他不拒绝交易，那么像任何交易一样，我都将停止支付。

如果您想给他一个机会，请开发一个标准化测试，以收集有关内存泄漏的指标。每周监视他的进度，坚持查看他更改的代码，并寻求改进。如果他此时无法处理，请解散无用的诉求。