我们的一位开发人员不断地编写代码并将其放入版本控制中，而无需对其进行测试。我们的代码质量因此受到影响。
除了摆脱开发人员，我该如何解决这个问题？
编辑
我和他谈过很多次，甚至给了他书面警告
CharlesF
问问题
5920 次
49 回答
43
如果您可以进行代码审查 - 这是一个完美的地方。
我们需要在合并到迭代主干之前进行审查，因此通常会在那时捕获所有内容。
于 2008-09-26T12:49:21.177 回答
33
如果您在允许开发人员提交代码之前系统地执行代码审查，那么您的问题基本上就解决了。但这似乎不是你的情况，所以这是我推荐的：
- 与开发商交谈。讨论对团队中其他人的后果。大多数开发人员都希望得到同行的认可，所以这可能就足够了。还要指出，修复你脑海中新鲜的代码中的错误比修复几周前的代码要容易得多。如果你有某种形式的代码所有权，这部分是有意义的。
- 如果这在一段时间后不起作用，请尝试制定一项政策，让提交有缺陷的代码对作者来说是不愉快的。一种流行的方法是让破坏构建的人负责创建下一个构建的琐事。如果您的构建过程是完全自动化的，请寻找其他琐碎的任务来代替。这种方法还有一个额外的好处，就是不会特别指出任何人，使其更容易被每个人接受。
- 使用纪律措施。根据您的团队和公司的规模，这些可以采取多种形式。
- 解雇开发商。保留坏苹果是有成本的。当你走到这一步时，开发人员并不关心他的开发人员，而且你已经遇到了人员问题。如果工作环境变得毒化，你可能会比这个糟糕的开发人员损失更多——生产力方面和人员方面的损失。
于 2008-09-26T13:03:31.330 回答
14
作为一个很少测试自己代码的开发人员，我可以告诉你一件让我慢慢改变行为的事情......
能见度
如果环境允许将代码推出，等待用户发现问题，然后本质上是问“现在怎么样？” 在对代码进行更改后，没有真正的动力去测试你自己的东西。
代码审查和协作鼓励您努力制作优质产品，而不是仅仅交付“Widget X”而您的同事在“Widget Y”和“Widget Z”上工作
你的工作越显眼，你就越有可能关心它的工作情况。
于 2008-09-26T13:32:13.320 回答
10
使其成为他的年度审查目标的一部分。如果达不到，就不会加薪。
有时，尽管您确实必须接受某人不适合您的团队/环境，但这应该是最后的手段，并且可能很难处理，但是如果您用尽了所有其他选择，从长远来看，这可能是最好的选择.
于 2008-09-26T12:49:42.640 回答
10
代码审查。每周一早上把你所有的开发人员都放在一个房间里，并要求他们将上周最自豪的基于代码的成就与他们一起带到会议上。
让他们成为焦点，对解释他们所做的事情感到兴奋。让他们带来代码副本，以便其他开发人员可以看到他们在说什么。
几个月前我们开始了这个过程，令人惊讶的是，我们在潜意识中进行了大量的质量检查。毕竟，如果只是要求开发人员谈论他们最兴奋的事情，他们会完全兴奋地向人们展示他们的代码。然后，其他开发人员将看到质量错误并公开讨论错误的原因以及应该如何真正编写代码。
如果这不能让您的开发人员编写高质量的代码，那么他可能不适合您的团队。
于 2008-09-26T13:00:09.013 回答
9
告诉开发人员您希望在 2 周内看到他们的做法发生变化，否则您将开始贵公司的纪律处分程序。提供尽可能多的帮助和帮助，但如果你不能改变这个人，他就不适合你的公司。
于 2008-09-26T12:49:13.827 回答
9
使用 Cruise Control 或类似工具，您可以使签入自动触发构建和单元测试。你仍然需要确保他添加的任何新功能都有单元测试，你可以通过查看他的签入来做到这一点。然而，这是一个人的问题，所以技术解决方案只能走这么远。
于 2008-09-26T12:57:47.443 回答
8
为什么不直接跟他说话？他可能不会真的咬你。
于 2008-09-26T12:47:48.043 回答
8
让他“照看”构建，并成为构建经理。这将给他更少的时间来开发代码（从而提高每个人的表现）并教他为什么一个好的构建是如此必要。
强制执行测试用例——没有单元测试用例就不能提交代码。修改构建系统，以便如果测试用例没有正确编译和运行，或者不存在，那么整个任务签入都会被拒绝。
-亚当
于 2008-09-26T14:49:17.487 回答
7
发布每个开发人员测试代码覆盖率的统计数据，这将在与他交谈之后。
于 2008-09-26T12:49:30.987 回答
7
这里有一些来自海上棚户区的想法。
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!
等等。用“草率的开发者”代替“醉酒的水手”。
于 2008-09-26T13:11:02.373 回答
5
根据您使用的版本控制系统的类型，您可以设置签入策略，强制代码在被允许签入之前通过某些要求。如果您使用像 Team Foundation Server 这样的系统，它使您能够为签入指定代码覆盖率和单元测试要求。
于 2008-09-26T12:50:44.793 回答
5
您知道，这是避免将他单独挑出来（尽管我同意您需要与他交谈）并在内部实施测试优先流程的绝佳机会。如果规则不明确并且所有人都知道期望，那么我发现您所描述的并不少见。我发现执行测试优先的开发方案对我来说效果很好，并且可以提高代码质量。
于 2008-09-26T12:52:03.400 回答
4
他们可能过度关注速度而不是质量。
这可能会诱使一些人匆忙解决问题以清除他们的列表并查看稍后在错误报告中返回的内容。
要纠正这种平衡：
- 在您的问题跟踪系统中一次只分配几个项目，
- 代码审查并尽快测试他们“完成”的任何内容，以便在有任何问题时立即回复他们
- 与他们谈谈您对一件物品需要多长时间才能正确完成的期望
于 2008-09-26T13:02:27.760 回答
3
对等编程是另一种可能性。如果他与团队中另一位符合质量标准并了解程序的熟练开发人员在一起，那么这有一些好处：
- 有经验丰富的开发人员支持他，他将了解对他的期望，并了解他的代码与符合期望的代码之间的区别
- 其他开发人员可以强制执行测试优先策略：在为其编写测试之前不允许编写代码
- 同样，其他开发人员可以在签入之前验证代码是否符合标准，从而减少错误签入的次数
当然，所有这些都要求公司和开发人员接受这个他们可能不接受的过程。
于 2008-11-04T06:27:06.870 回答
3
对于这个问题，人们似乎想出了很多富有想象力和曲折的答案。但事实是，这不是游戏。设计复杂的同伴压力系统来“命名和羞辱”他不会找到问题的根源，即。他为什么不写测试？
我觉得你应该直接。我知道你说你和他谈过了，但你有没有试图找出他为什么不写测试？显然在这一点上他知道他应该这样做，所以肯定有一些原因他没有做他被告知要做的事情。是懒惰吗？拖延？程序员以自负和强烈的观点而闻名——也许他出于某种原因相信测试是浪费时间，或者他的代码总是完美的，不需要测试。如果他是一个不成熟的程序员，他可能无法完全理解他的行为的含义。如果他“太成熟”，他可能会太固执己见。不管是什么原因，解决它。
如果它确实归结为意见问题，您需要让他明白他需要将自己的个人意见放在一边，并遵守规则。明确表示，如果不能信任他遵守规则，那么他将被替换。如果他仍然不这样做，就这样做。
最后一件事 - 记录您的所有讨论以及由于他的更改而出现的任何问题。如果遇到最坏的情况，您可能会被迫证明自己的决定是正确的，在这种情况下，拥有书面证据肯定是无价的。
于 2008-11-04T06:30:58.733 回答
2
把他放在他自己的开发分支上，只有在你知道它已经过彻底测试时才把他的东西放进后备箱。这可能是 GIT 或 Mercurial 等分布式源代码控制管理工具擅长的地方。尽管 SVN 中增加了对分支/合并的支持，但管理它可能不会有太多麻烦。
编辑
只有当你无法摆脱他或让他改变自己的方式时。如果您根本无法停止这种行为（通过更改或解雇），那么您能做的最好的事情就是缓冲团队其他成员免受他编码的不良影响。
于 2008-09-26T12:49:14.203 回答
2
如果您所在的地方可以影响政策，请进行一些更改。在签入之前进行代码审查，并将测试作为开发周期的一部分。
于 2008-09-26T12:49:45.323 回答
2
看起来很简单。把它作为一个要求，如果他做不到，就换掉他。你为什么要留着他？
于 2008-09-26T14:43:08.967 回答
2
我通常不提倡这一点，除非一切都失败了......
有时，公开显示的按开发人员统计的错误数图表可以施加足够的同行压力以获得有利的结果。
于 2008-09-29T17:23:59.307 回答
2
试试胡萝卜，让它成为一个有趣的游戏。
例如 Hudson 的持续集成游戏插件
http://wiki.hudson-ci.org/display/HUDSON/The+Continuous+Integration+Game+plugin
于 2010-01-14T14:00:15.630 回答
1
根据某些逻辑，例如每个功能、每个错误修复、每个开发团队等，将您的开发人员放在代码的分支上。然后将错误的签到与这些分支隔离开来。当需要进行构建时，合并到测试分支，发现问题，解决，然后将您的版本合并回主分支。
或者删除该开发人员的提交权限，让他们在提交代码之前将其代码发送给年轻的开发人员进行审查和测试。这可能会促使程序发生变化。
于 2008-09-26T12:52:09.280 回答
1
您可以将代码中发现的错误与负责该软件的程序员的姓名放在一起。
如果他是一个理性的人，请与他讨论报告。
如果他关心自己的“声誉”，请定期发布报告并提供给所有同行。
如果他只听“权威”的话，请报告并将问题上报给他的经理。
无论如何，我经常看到，当人们意识到他们从外面看起来有多糟糕时，他们会改变自己的行为。
嘿，这让我想起了我在 xkcd 上读到的东西:)
于 2008-09-26T12:56:12.580 回答
1
您是指在签入之前编写自动化单元测试还是手动单元测试？
如果您的商店不编写自动化测试，那么他签入不起作用的代码就是鲁莽的。对团队有影响吗？你们有正规的 QA 部门吗？
如果您都在创建自动化单元测试，那么我建议您的代码审查过程的一部分也包括单元测试。很明显，根据您的标准，在您的审查期间代码是不可接受的。
你的问题相当广泛，但我希望我提供了一些方向。
我同意菲尔的观点，第一步是单独与他交谈并解释质量的重要性。质量差往往与团队、部门和公司的文化有关。
于 2008-09-26T12:59:35.037 回答
1
在某些事情被认为“完成”之前，将已执行的测试用例作为可交付成果之一。
如果你没有执行测试用例，那么工作就没有完成，如果截止日期在你有记录的测试用例执行之前就过去了，那么他没有按时交付，后果和他一样未完成开发。
如果您公司的文化不允许这样做，并且它重视速度而不是准确性，那么这可能就是问题的根源，而开发人员只是对现有的激励措施做出回应——他因为做了很多事情而得到了回报事情半途而废，而不是正确的事情更少。
于 2008-09-26T14:16:15.273 回答
1
使人清洁厕所。在军队工作。如果你和吃很多印度菜的人一起工作，他们很快就会排队。
但这只是我...
于 2008-09-26T16:18:16.680 回答
1
每次开发人员检查无法编译的内容时，将一些钱放入罐子中。在那之前你会三思而后行。
于 2008-09-26T16:36:48.243 回答
1
不幸的是，如果您已经与他多次交谈并给了他书面警告，我会说是时候将他从团队中淘汰了。
于 2008-09-29T13:49:12.457 回答
1
您可能会在这里找到一些有用的答案：如何让初级程序员编写测试？
于 2010-01-14T16:42:46.253 回答
1
如果你真的和他谈过，你给了他所有的支持和培训，他需要理解为什么这很重要，那么我会考虑摆脱他（如何运作取决于你在世界的哪个地方是）。我知道你说过除了解雇他之外你还想要一些东西，但有时问题没有“好的”解决方案。
没有苛刻的程序员总是谈论离开不认真对待软件开发的公司。
如果这是合理的，那么公司为什么要容忍一个已经获得了所有合理机会但显然仍然没有认真对待软件开发的开发人员呢？
于 2010-01-14T16:54:23.547 回答
1
我很想建议详细说明您尝试过的内容以及获得的结果，因为这可能会有所改变，但这是我的初步建议：
是测试还是综合测试？有些人可能会盲目编码并进行零测试，但这很少见，IME。通常会进行一些测试，但不足以涵盖大多数需要综合测试的情况。
团体动力可能会有所帮助。我假设他是团队的一员，并且团队的观点在这里可能会有所帮助。在某种程度上，这是试图获得同伴压力，这通常是一件坏事，但有时它可以以好的方式使用。
警告的详细程度如何？在某种程度上，这可能看起来很幼稚，但您认为的测试可能与他的不同。您想要 nUnit 测试、excel 电子表格、他计算机中的日志或其他东西作为测试存在和使用的证据吗？根据您的描述，没有任何证据可以证实他确实理解您的意思，将使用测试并提供这样做的证据。
入住政策问题。有些地方，比如我现在的工作场所，鼓励经常提交，这可能意味着一个人在没有测试的情况下提交代码。您所在的地区是否有已知、接受和严格遵守的政策？这是这里的另一个方面。
于 2010-01-14T18:22:39.047 回答
1
如果您设置了自动构建，请确保失败通知尽可能明显和烦人。开发公共区域中的墙板或音频通知是一个好的开始。然后，确保一个构建被破坏，确保在犯罪者解决问题之前没有人签入代码。
Granted, this will only catch it when his code breaks the build, but the peer pressure for him to continually be spotlighted for this will be an incentive for most. In the event that this does not help, take the next discinplinary actions available through your human resources department. You have already talked to him, you already have given a written notice - find out what the next steps are. A developer who goes his own way is either a visionary or not a team player - and I have never personally had the pleasure of working with a visionary in that regard.
于 2010-01-15T08:26:07.017 回答
0
你试过和他们谈谈吗？可能不是一个糟糕的第一步。如果问题仍然存在，它还可能为您提供一些关于第 2 步应该是什么的线索。
于 2008-09-26T12:48:23.877 回答
0
测试你的拼写！我认为您的意思是“他们的代码”。
- 跟他说话。让他知道这是个问题。
- 召开小组会议讨论代码质量。
- 如果它仍然很糟糕，请强迫他在签入之前检查他的代码。
- 如果到那时他还没有得到提示，你将不得不让他离开。
于 2008-09-26T12:50:28.037 回答
0
NCover + Cruise Control，发送自动报告，然后可以证明当他检查代码覆盖率下降时。
于 2008-09-26T13:37:57.707 回答
0
代码审查和单元测试。
作为（像许多人一样）检查一个微不足道的更改并破坏事情的人，我可以告诉你，单元测试消除了不测试的任何借口，如果它们被设置，那么你可以快速运行整个整体，它们有助于识别谁破坏了代码（假设一个不错的 VCS）。当然，通过非正式的代码审查，我已经检查了由资深（和称职的）同事审查过的琐碎代码，但仍然破坏了代码库。
于 2008-09-26T14:02:28.520 回答
0
如果和他谈不上，你又不能解雇他，那他要么是懒惰，要么是不讲道理。如果你不能走上正经的路和那个人讲道理，那就打他最痛的地方，开始扣他的工资。或者如果你真的想惩罚他，让他维护代码。
于 2008-09-26T15:20:56.583 回答
0
引入代码覆盖工具并从构建服务器生成单元测试未覆盖的所有代码的自动报告。他的名字将在董事会的底部。
该板应该每周打印并粘贴在每个人都可以看到的地方。
在他的覆盖率达到 85% 之前停止给他任何新的事情
给董事会顶端的人最有趣的工作。
将你的下一个书面警告与某个代码覆盖率要求联系起来——那么如果他失败了，你就有明确的解雇理由。
于 2008-09-26T16:28:54.440 回答
0
告诉他他将被重新分配到质量团队，在那里他将只做文档。对于我领导的团队来说，这不止一次对我有用……如果这不起作用，请找其他人来测试他的代码！..等等，那是蹩脚的......哦，是的......解雇他！
于 2008-09-29T13:37:16.027 回答
0
这取决于。
他的代码有效吗？他是你团队中效率最高还是效率最低的成员？代码比其他代码错误吗？他/她的贡献有多大价值？
如果他是一个出色的表演者，可以产生高质量的代码，那么谁在乎。另一方面，如果他/她正在编写漏洞百出的代码，那么请让那个人坐下来，与他们交谈，列出后果，然后他们要么加入，要么不加入
于 2008-09-29T13:52:07.130 回答
0
您提到与开发人员交谈，但我很想知道您是否向他们询问了他们的测试程序。如果他们来自另一家公司，那么他们可能习惯于编写所有代码、签入、测试，然后签入代码的最终版本。如果他们将签到视为另一种保存工作的方式。
但是，如果他们已经在您的公司工作了很长一段时间（比如至少六个月），那么他们应该习惯于您做事的方式，这在更长时间内都不是一个非常有效的借口。
于 2008-09-29T13:56:18.587 回答
0
简单的。让开发人员负责验证报告的错误并修复重现的错误。不要让这个人开发新功能。
如果这个人有半个大脑，他们很快就会被非单元测试代码导致的愚蠢的错误发展到一定程度。此外，该人的整体技能可能会显着提高。
于 2008-10-26T06:14:47.370 回答
0
如果连他的代码的代码审查都不起作用，也许给他一个任务来审查他可能与自己的问题相关的其他“精彩”（;））代码，并要求他将他的代码与那个糟糕的部分进行比较的代码。
通常，这种人的问题是自我实现，所以无论你如何试图让他理解他自己的代码的问题；除非他自己没有意识到，否则它是行不通的。这当然是，如果你没有选择解雇他，事实上想培养他。
于 2008-11-04T06:01:35.033 回答
0
听起来你已经向他明确表示这对你、公司和团队都很重要。
我认为你需要找出他行为背后的原因——他只是没有听到你在说什么吗？也许你需要找到另一种表达方式。
也许他不相信——可能有很多原因——找到根本原因并处理它。
于 2008-11-04T06:16:16.423 回答
0
如果谈话不起作用，请制定一项政策，将没有附带测试的签入代码简单地从存储库中撤出。在他们必须重写他们的代码几次之后，他们可能会收到消息。
于 2008-11-13T05:05:42.677 回答
0
我会建议（和其他人一样）：
- 代码审查，
- 结对编程，
- SCM 提交策略。
于 2008-12-11T09:31:06.167 回答
0
你可以告诉你的版本控制系统，这个用户没有上传任何东西的权限，所以他必须让别人为他做。那应该教他。
于 2008-12-11T09:39:08.677 回答
0
在团队内部就将要测试的内容、测试方式以及测试时间（签入之前、推送之前、合并到主干之前）达成一致。
然后，当签入不符合团队同意的代码应满足的标准集时，只需将其回滚，并要求开发人员修复它。回滚签入是一种非常有效的方法，既可以在面对低质量签入时保持代码库的质量，又可以作为一种轻量级的方式向人们表明他们的代码不符合团队设定的标准.
回滚的好处在于，重新签入代码非常容易——只需回滚回滚，修复任何问题，然后再次检查更改。
我会小心地以一种非常客观的方式来做这件事，不会向任何人发出信号。这意味着将其应用于整个团队，而不仅仅是您的问题成员，并专注于使其更多地关注代码的质量，并使签入的代码符合团队彼此设定的标准，而不是作为一种惩罚.
于 2008-12-26T07:49:42.913 回答
0
你说他不测试他的代码。这是否意味着他不创建单元测试？或者他根本不测试他的代码？
如果他根本不测试他的代码，那么这是他开发的根本问题。测试您编写的代码是工作的一部分。不测试其代码的开发人员是不可接受的，并且会减慢您的项目速度。测试是开发人员（甚至是所谓的明星）工作描述的一部分。
但是，如果他正在测试他的代码，但没有创建“正确”数量的自动化单元测试，那么这是一个不同的问题，需要不同的解决方案。正如其他人所说，您需要找出原因并修复它。代码审查是发现这些问题的好方法。但听起来你已经知道问题所在了。
于 2010-01-14T16:41:44.523 回答