logo标签列表

如果一个开发者不测试他的代码，你会怎么做？

testingproject-managementsoftware-quality
27

我们的一位开发人员经常将未经测试的代码写入版本控制系统。由此导致我们的代码质量受到影响。

除了解雇这位开发人员，我该如何解决这个问题？

编辑：

我已经多次与他谈过，并给他发了书面警告。

3
哇，我是唯一一个对没有阅读“我已经和他谈过”这句话的人数量感到震惊的吗？我也是唯一一个对建议的负面技术数量感到震惊的人吗？请给那些关于代码审查和测试的建议点赞！ - Alan Hensel
2
有些人天生擅长创新和处理“大想法”，但不太擅长测试和低级细节。他对团队的贡献是否超过了损失？如果他值得留下，那么让测试对他和团队都有价值--不仅仅是指出它应该做什么。 - Kevin Fairchild
1
你和他谈过了吗？他说了什么？他是不是工作过度？还是无能为力？他是否认为自己是个天才，他的代码没必要测试就能工作？对于这些情况，最好的回应可能并不相同。 - Niki
49个回答
43

如果您能进行代码审查-那是捕捉问题的完美地方。

我们要求在合并到迭代主干之前进行审查，因此通常在那时会抓住所有问题。

在阅读了您原始问题的编辑后，代码审查成为仅剩的几个选项之一。 - Ian P
这可能是我们店里最大的改进之一。无论它是否有助于这个人，它都会对你的店有所帮助。 - Konrad
我发现代码审查是无价的。通过向其他人解释代码，您可以发现大量错误。您也可以从中学到很多东西。 - ya23
5
代码审查并不能取代测试，你应该同时做好两者。 - slim
但是那个人将会通过CR学到一些东西。 - helios
虽然它不能替代测试，但对于问题开发人员来说，这可能是一个启示，让他真正审视自己的工作，当90%的问题都是由他引起时。否则，他将一无所获，你需要解雇他。 - mynameiscoffey
34

如果在允许开发人员提交代码之前，您有规律地进行代码审查，那么，您的问题大多数已经解决了。但这似乎不是您的情况，所以我建议：

  • 与开发人员交谈。 讨论团队中其他人的后果。大多数开发人员希望得到同行的认可，所以这可能足够了。还要指出，在您头脑中新鲜的代码中修复错误要容易得多，而不是几周前的代码。如果您有某种形式的代码所有权，则此部分是有意义的。
  • 如果一段时间后仍然不起作用，请尝试制定政策，使提交有缺陷的代码对作者不利。一种受欢迎的方法是，让破坏构建的人负责创建下一个构建的琐事。如果您的构建过程完全自动化，请寻找另一个琐碎的任务来处理。这种方法的附加好处是不会具体指出任何人，这样对每个人都更容易接受。
  • 使用纪律措施。根据团队和公司的大小，这些措施可以采取许多形式。
  • 解雇开发人员。 保留不良因素是有成本的。当您走到这一步时，开发人员已经不关心他的同行开发人员了，而且您已经面临着一个人员问题。如果工作环境变得恶劣，您可能会失去更多 - 在生产力和人员方面 - 而不仅仅是一个不良的开发人员。
让不太好的开发人员“看守”构建的好处在于，他们花费在编写代码上的时间比观察构建的时间少，这为每个人实现了性能提升。 - Adam Davis
1
纪律措施是暂时的无直接提交访问。这就是OpenBSD开源项目所做的。在发布之前，所有具有提交访问权限的开发人员必须花一些时间测试所有内容。如果他们不这样做，通常会被拒绝提交访问权限，因此他们想要做的任何事情都必须由其他人检查。如果这段时间内仍然行不通，那么我认为应该解雇他们。 - Earlz
14
作为一名不常测试自己代码的开发者，我可以告诉你一个使我逐渐改变行为的因素...
可见性
如果环境允许推送代码并等待用户发现问题，然后在修改代码后实质上询问“现在怎么样了？”，那么就没有真正的动力来测试自己的东西。
代码审查和协作能够更鼓励你将精力投入到打造优质产品上，而不是只交付“小部件X”，而你的同事则分别开展“小部件Y”和“小部件Z”的工作。
你的工作越容易被看到，你就越关心它的运行情况。
11

代码审查。每个星期一早上，将所有开发人员聚集在一个房间里，并要求他们携带上一周最引以为豪的基于代码的成就参加会议。

让他们成为焦点并兴奋地解释他们所做的事情。让他们携带代码副本，以便其他开发人员可以看到他们正在谈论的内容。

我们几个月前开始了这个流程，惊人的是，这个过程中进行了大量的无意识质量检查。毕竟，如果只是要求开发人员谈论他们最感兴趣的事情，他们将非常乐意向人展示他们的代码。然后，其他开发人员将看到质量错误，并公开讨论为什么他们是错误的，以及应该如何编写代码。

如果这不能促使你的开发人员写出优质的代码，那么他可能不适合你的团队。

（十年后...）我真的很喜欢这个想法，即使开发人员从未在演示者的代码中挑出漏洞。基于积极强化和让团队资深成员的实践得到关注的原则，这似乎是一种很好的方式，在避免有毒的负面情绪的同时获得一些好处。 - Matt
10

将其纳入他的年度审查目标。如果他未能实现它，就不给加薪。

但有时你必须接受某人并不适合你的团队/环境，这应该是最后的选择，而且可能很难处理，但如果你已经尝试了所有其他选项，从长远来看可能是最好的事情。

看起来除了将“生产/现场缺陷数量”这一指标纳入您衡量他绩效的指标之外，似乎没有其他选择。确保他知道自己正在被测量，并且这将影响他的绩效评估。 :) - jop
没有获得加薪将不会激励编写高质量的代码。这会令人不满意，但他将不知道如何做得更好。 - helios
9
告诉开发者，在2周内希望看到他们改变做事的方式，否则你将开始公司的纪律程序。尽可能提供帮助和支持，但如果你无法改变这个人，那么他就不适合你的公司。
9
使用Cruise Control或类似工具，您可以使检入自动触发构建和单元测试。您仍需要确保为任何新功能添加单元测试，您可以通过查看他的检入来完成。 然而，这是一个人类问题，因此技术解决方案只能做到有限程度上的帮助。
我知道有一家公司，他们在屏幕上展示那些最常破坏构建的开发人员的照片。这可能是一种激励措施。 - Torsten Marek
如果他一开始就编写了单元测试，这个方法本来是可行的。开发人员所要做的就是不编写高质量的测试，仍然可以逃避这种行为。 - Konrad
我们使用CCMenu、Growl和MacMini来发出非常响亮的失败声音 - 然后每个人都停止工作，尝试修复构建。当警报响起时，通常也会指责别人。 - Paul Shannon
如果其他开发人员编写了高覆盖率的质量测试，他将很难通过筛网添加新功能。 - Paul Shannon
8
为什么不直接和他谈？他可能不会真的咬你。
如果你已经尝试过了，那就炒了他吧......他可能会明白这对他未来的工作有好处！ - pmlarocque
我已经多次与他谈过，并给了他书面警告。 - Charles Faiga
在这种情况下，您可能需要将事情提升到下一个级别并联系人力资源部门。 - Phil Wright
我同意，明确告诉他的工作岌岌可危。如果你能说服他开始测试，那么你就是在帮他一个忙。如果只有失业的威胁才能起到作用，那就这样吧。 - Adam Bellaire
8

  • 让他“看管”构建过程，成为构建经理。这将减少他开发代码的时间（从而提高所有人的绩效），并教会他为什么良好的构建是如此必要。

  • 强制执行测试用例 - 不能提交没有单元测试用例的代码。修改构建系统，以便如果测试用例无法正确编译和运行或不存在，则拒绝整个任务的提交。

-Adam

我发现人们总是可以颠覆系统。如果员工不能在没有单元测试的情况下提交他的工作，他会写等价于assert(1==1)或者最基本且可能非常死板的测试。 - Nathan Koop
没错，这最终会被发现，证明他没有按照公司的政策/标准进行开发。 - Adam Davis
7

发布每个开发者的测试代码覆盖率统计数据，在与他交谈后进行。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接