对于不测试代码的开发人员,您如何处理？

我们的一位开发人员不断编写代码并将其置于版本控制中而不进行测试.因此,我们的代码质量受到了影响.

除了摆脱开发者之外,我该如何解决这个问题呢？

编辑

我和他谈了很多次,甚至还给了他书面警告

1> Ian P..：

---

如果你可以进行代码审查 - 这是一个完美的地方来抓住它.

我们需要在合并到迭代主干之前进行审核,因此通常会捕获所有内容.

---

代码审查不能替代测试.你应该两个都做.

2> 小智..：

---

如果您在允许开发人员提交代码之前系统地执行代码审查,那么您的问题基本上已得到解决.但这似乎不是你的情况,所以这就是我的建议:

与开发人员交谈.讨论团队中其他人的后果.大多数开发人员希望得到他们的同行的认可,所以这可能就足够了.还要指出,修复代码中的错误要比修复数周的代码更容易.如果你有某种形式的代码所有权,这部分是有意义的.

如果这在一段时间后不起作用,请尝试制定一个策略,使提交错误代码对作者不愉快.一种流行的方法是让打破构建的人负责创建下一个的琐事.如果您的构建过程是完全自动化的,那么请寻找另一个需要处理的琐事.这种方法的另一个好处是没有特别指出任何人,使每个人都更容易接受.

使用纪律措施.根据您的团队和公司的规模,这些可以采取多种形式.

解雇开发人员.保持坏苹果需要付出代价.当你走到这一步时,开发人员并不关心他的开发人员,你已经掌握了人的问题.如果工作环境中毒,那么你可能会比这个单一的糟糕开发者失去更多 - 生产力和人性.

3> Kevin Fairch..：

---

作为一个很少测试自己代码的开发人员,我可以告诉你一件事让我慢慢改变了我的行为......

能见度

如果环境允许推出代码,等待用户发现问题,然后基本上问"现在怎么样？" 在对代码进行更改之后,没有真正的动机去测试自己的东西.

代码审查和协作鼓励您努力制作高质量的产品,而不是在您的工友处理'Widget Y'和'Widget Z'时提供'Widget X'

你的工作越明显,你就越有可能关心它的运作方式.

4> Simon Keep..：

---

将其作为年度回顾目标的一部分.如果他没有实现它,就不会加薪.

有时虽然你必须接受某人不适合你的团队/环境,但它应该是最后的手段并且很难处理,但如果你已经用尽所有其他选择,那么从长远来看这可能是最好的选择. .

5> Nick Sergean..：

---

代码审查.每周一早上将你所有的开发人员都放在一个房间里,让他们把他们最引以为傲的代码成就从前一周带到会议中.

让他们成为众人瞩目的焦点,并对解释他们所做的事情感到兴奋.让他们带上代码的副本,以便其他开发人员可以看到他们正在谈论的内容.

几个月前我们开始了这个过程,看到发生的次级质量检查的数量令人惊讶.毕竟,如果简单地要求开发人员谈论他们最为兴奋的事情,那么他们就会完全向人们展示他们的代码.然后,其他开发人员将看到质量错误并公开讨论他们错误的原因以及如何真正编写代码.

如果这不能让你的开发人员编写高质量的代码,那么他可能不适合你的团队.

6> Paul Dixon..：

---

告诉开发人员,您希望在2周内看到他们的实践发生变化,或者您将开始公司的纪律处分程序.提供尽可能多的帮助和帮助,但如果你不能改变这个人,他就不适合你的公司.

7> RossFabrican..：

---

使用Cruise Control或类似工具,您可以使checkins自动触发构建和单元测试.你仍然需要确保对他添加的任何新功能进行单元测试,你可以通过查看他的签到来做.然而,这是一个人为问题,因此技术解决方案只能走到这一步.

8> Phil Wright..：

---

为什么不和他说话？他可能实际上不会咬你.

9> Adam Davis..：

---

让他"保姆"构建,并成为构建经理.这将使他没有多少时间来开发代码(从而提高每个人的表现)并教会他为什么一个好的构建是如此必要.

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

-亚当

10> Paul Whelan..：

---

发布每个开发人员测试代码覆盖率的统计数据,这是在与他交谈之后.

11> Rafał Dowgir..：

---

以下是来自海棚屋的一些想法.

Intro
   What shall we do with a drunken sailor, (3×)
   Early in the morning?
Chorus
   Wey–hey and up she rises, (3×)
   Early in the morning!
Verses
   Stick him in a bag and beat him senseless, (3×)
   Early in the morning!
   Put him in the longboat till he’s sober, (3×)
   Early in the morning!

用"邋developer的开发者"取代"醉酒的水手".

---

我们在开发社区中做得不够.

12> Micah..：

---

根据您使用的版本控制系统的类型,您可以设置签入策略,强制代码在允许签入之前通过某些要求.如果您使用的是Team Foundation Server之类的系统,则可以为签入指定代码覆盖率和单元测试要求.

13> itsmatt..：

---

你知道,这是一个避免单挑他的绝佳机会(尽管我同意你需要与他交谈)并在内部实施测试优先流程.如果规则不明确并且所有人都知道期望,我发现你描述的并不是那么罕见.我发现做测试优先开发方案对我来说效果很好并且提高了代码质量.