我们的一位开发人员不断编写代码并将其放入版本控制中，而无需对其进行测试。因此，我们的代码质量受到了影响。
除了摆脱开发者，我该如何解决这个问题？
编辑
我和他谈过很多次，甚至给了他书面警告
【问题讨论】：
标签： testing project-management software-quality
如果您真诚地与他交谈，并且您已为他提供他需要的所有支持和培训以了解为什么这很重要，那么我会看看摆脱他（如何运作取决于你在世界的哪个地方）。我知道你说过除了解雇他之外你还想要一些别的东西，但有时问题没有“好的”解决方案。
没有苛刻的程序员总是谈论离开不认真对待软件开发的公司。
如果这是合理的，那么公司为什么要容忍一个已经获得了所有合理机会但显然仍然没有认真对待软件开发的开发人员？
【讨论】：
如果您设置了自动构建，请确保失败通知既明显又烦人。开发公共区域中的墙板或音频通知是一个好的开始。然后，确保一个构建被破坏，确保在犯罪者解决问题之前没有人签入代码。
当然，这只会在他的代码破坏构建时才会发现，但他不断受到关注的同行压力将成为大多数人的动力。如果这没有帮助，请通过您的人力资源部门采取下一个纪律处分措施。你已经和他谈过了，你已经给出了书面通知 - 找出下一步是什么。走自己的路的开发人员要么是有远见的，要么不是团队合作者——在这方面，我个人从未有过与有远见的人一起工作的乐趣。
【讨论】：
你试过和他们谈谈吗？可能不是一个糟糕的第一步。如果问题仍然存在，它还可能会为您提供一些线索，说明第 2 步应该是什么。
【讨论】：
测试你的拼写！我认为您的意思是“他们的代码”。
【讨论】：
NCover + Cruise Control，发送自动报告，然后可以证明他检查代码覆盖率下降。
【讨论】：
代码审查和单元测试。
作为（像许多人一样）检查微不足道的更改并破坏事物的人，我可以告诉您，单元测试消除了不测试的任何借口，如果它们已设置好，那么您可以快速运行整个系统，并且他们帮助确定谁破坏了代码（假设一个不错的 VCS）。当然，通过非正式的代码审查，我已经检查了由资深（和称职的）同事审查过的琐碎代码，但仍然破坏了代码库。
【讨论】：
如果和他谈话没有用，而且你不能解雇他，那么他要么是懒惰的，要么是不讲道理的。如果你不能走大路并与那个人讲道理，那就打他的痛处并开始扣他的工资。或者如果你真的想惩罚他，让他维护代码。
【讨论】：
引入代码覆盖工具，并从构建服务器生成单元测试未覆盖的所有代码的自动报告。他的名字将在董事会的底部。
板应该每周打印出来并贴在每个人都能看到的地方。
在他的覆盖率达到 85% 之前，不要再给他任何新的东西了
给董事会顶端的人最有趣的工作。
将您的下一个书面警告与某个代码覆盖率要求联系起来 - 如果他失败了，您就有明确的解雇理由。
【讨论】：
告诉他，他将被重新分配到质量团队，在那里他将只做文档。对于我领导的团队来说，这不止一次对我有用……如果这不起作用，请找其他人来测试他的代码！ ..等等，那是蹩脚的......哦，是的..解雇他！！！
【讨论】：
视情况而定。
他的代码有效吗？ 他是你团队中效率最高还是效率最低的成员？ 代码比其他代码错误吗？ 他/她的贡献有多大价值？
如果他是一个出色的表演者，可以产生高质量的代码，那么谁在乎。另一方面，如果他/她正在编写漏洞百出的代码，那么请让那个人坐下来，与他们交谈，列出后果，然后他们要么加入，要么不加入
【讨论】：
您提到与开发人员交谈，但我很想知道您是否向他们询问过他们的测试程序。如果他们来自另一家公司，那么他们可能习惯于编写所有代码，签入，然后进行测试，然后签入代码的最终版本。如果他们将签到视为另一种保存工作的方式。
但是，如果他们已经在您的公司工作了很长一段时间（比如至少六个月），那么他们应该习惯于您做事的方式，而这在更长时间内就不是一个非常有效的借口了。
【讨论】：
简单。让开发人员负责验证报告的错误并修复重现的错误。不要让这个人开发新功能。
如果这个人有半个大脑，他们很快就会因非单元测试代码导致的脑筋急转弯而产生一定程度的挫败感。此外，此人的整体技能可能会显着提高。
【讨论】：
如果他的代码的代码审查不起作用，也许给他一个任务来审查他可能与自己的问题相关的一些其他“精彩”（;））代码，并要求他将他的代码与那段糟糕的代码。
通常，这类人的问题是自我实现，所以无论你如何试图让他理解他自己的代码的问题；除非他自己没有意识到，否则它是行不通的。这当然是，如果你没有选择解雇他，事实上想培养他。
【讨论】：
听起来你已经向他明确表示，这对你、公司和团队都很重要。
我认为你需要找出他行为背后的原因 - 他只是没有听到你在说什么吗？也许你需要找到另一种表达方式。
也许他不相信 - 可能有很多原因 - 找到根本原因并处理那个。
【讨论】：
如果谈话不起作用，请制定一项政策，将没有附带测试的签入代码简单地从存储库中撤出。在他们必须重写他们的代码几次之后，他们可能会收到消息。
【讨论】：
我会建议（和其他人一样）：
【讨论】：
您可以告诉您的版本控制系统，该用户无权上传任何内容，因此他必须请人为他上传。那应该教他。
【讨论】：
在团队内部就将要测试的内容、测试方式以及测试时间（签入前、推送前、合并到主干前）达成一致。
然后，当签入不符合团队商定的代码应符合的标准集时，只需将其回滚，并要求开发人员进行修复。回滚签入是一种非常有效的方法，既可以在面对低质量签入时保持代码库的质量，又可以作为一种轻量级的方式向人们表明他们的代码不符合团队设定的标准.
关于回滚的好处在于，重新签入代码非常容易 - 只需回滚回滚，修复任何问题，然后再次检查更改。
我会小心谨慎地以非常客观的方式进行，不会向任何人发出信号。这意味着将其应用于整个团队，而不仅仅是您的问题成员，并专注于使其更多地关注代码的质量，并使签入的代码符合团队彼此设定的标准，而不是作为一种惩罚.
【讨论】：
你说他不测试他的代码。这是否意味着他不创建单元测试？或者他根本不测试他的代码？
如果他根本不测试他的代码，那么这就是他开发的根本问题。测试您编写的代码是工作的一部分。不测试其代码的开发人员是不可接受的，并且会减慢您的项目速度。测试是开发人员（甚至是所谓的明星）工作描述的一部分。
但是，如果他正在测试他的代码，但没有创建“正确”数量的自动化单元测试，那么这是一个不同的问题，需要不同的解决方案。正如其他人所说，您需要找出原因并修复它。代码审查是发现这些问题的好方法。但听起来你已经知道问题所在了。
【讨论】：