我们的开发人员之一是不断编写代码并将其置于版本控制中，而无需对其进行测试。结果，我们的代码质量受到了影响。

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

编辑

我已经和他谈过几次了，甚至给了他书面警告。

解决方案

为什么不跟他说话呢？他可能实际上不会咬你。

我们是否尝试过与他们讨论？可能不是不好的第一步。如果问题仍然存在，它也可能为我们提供有关第2步应采取的步骤的一些线索。

告诉开发人员我们希望在2周内看到他们的做法发生变化，否则我们将开始公司的纪律程序。提供尽可能多的帮助和协助，但是如果我们不能更换此人，那么他不适合公司。

将他放在自己的开发分支上，只有在我们知道它已经过全面测试的情况下，才能将他的东西带入后备箱。这可能是一个分布式源代码管理管理工具(如GIT或者Mercurial)比较出色的地方。尽管随着SVN中增加的分支/合并支持，我们在管理它方面可能不会有太多麻烦。

编辑

这仅在我们无法摆脱他或者让他改变自己的方式的情况下。如果我们根本无法停止这种行为(通过更改或者开除)，那么我们能做的最好的事情就是缓冲团队的其他成员免受其编码的不良影响。

如果我们可以进行代码审查-那是一个完美的地方。

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

在与开发人员交谈之后，发布有关每个开发人员测试代码覆盖率的统计信息。

使之成为他的年度审查目标的一部分。如果他没有实现，就不会加薪。

有时候，尽管我们确实必须接受某个人不适合团队/环境，但这应该是不得已的做法，并且可能很难处理，但是如果我们用尽了所有其他选择，那么从长远来看，这也许是最好的选择。

如果我们位于可以影响策略的地方，请进行一些更改。在签入之前进行代码审查，并使测试成为开发周期的一部分。

测试拼写！我认为意思是"他们的代码"。

• 跟他说话。让他知道这是一个问题。
• 召开小组会议，讨论代码质量。
• 如果仍然很糟，请强迫他检查代码，然后再将其检入。
• 如果那时他没有得到提示，则必须让他离开。

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

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

根据某些逻辑，例如每个功能，每个错误修复，每个开发团队等，将开发人员置于代码的分支中。然后，不好的签到被隔离到那些分支。当需要进行构建时，请合并到测试分支，查找问题，解决，然后将发行版合并回主分支。

或者删除该开发人员的提交权限，然后让他们将代码发送给年轻的开发人员进行审核和测试，然后再提交。这可能会促使程序发生变化。

我们可以将代码中发现错误的报告与负责该软件的程序员的名字放在一起。

如果他是一个合理的人，请与他讨论该报告。

如果他在乎自己的"声誉"，则定期发布该报告，并将其提供给所有同龄人。

如果他只听"当局"的话，请做报告并将问题上报给他的经理。

无论如何，我经常看到，当人们意识到他们从外面看起来有多糟糕时，他们会改变自己的行为。

嘿，这让我想起了我在xkcd上读到的东西:)

使用Cruise Control或者类似工具，我们可以使签入自动触发构建和单元测试。我们仍然需要确保对他添加的任何新功能进行单元测试，我们可以通过查看他的签入来完成。
但是，这是一个人为问题，因此技术解决方案只能走这么远。

我们是指在签入之前编写自动化单元测试还是手动进行单元测试？

如果商店没有编写自动化测试，那么他将不起作用的代码检入鲁less。对团队有影响吗？我们是否有正式的质量检查部门？

如果我们都在创建自动化的单元测试，那么我建议我们在代码审查过程中将单元测试也包括在内。很明显，在审查过程中，根据标准，该代码是不可接受的。

问题相当广泛，但我希望我能提供一些指导。

我同意菲尔的观点，第一步是单独与他交谈并解释质量的重要性。质量低下通常可以与团队，部门和公司的文化联系在一起。

代码审查。每个星期一早上将所有开发人员都放在一个房间里，并要求他们将前一周基于代码的最出色成就与他们一起带到会议中。

让他们成为聚光灯，并兴奋地解释自己的所作所为。让他们带来代码副本，以便其他开发人员可以看到他们在说什么。

我们几个月前就开始了这个过程，令人惊讶的是发生了大量的潜意识质量检查。毕竟，如果只是要求开发人员谈论他们最兴奋的事情，那么他们将完全被激励来向人们展示他们的代码。然后，其他开发人员将看到质量错误，并公开讨论错误的原因以及应该如何真正编写代码。

如果这不能使开发人员编写高质量的代码，那么他可能不适合团队。

他们可能过于注重速度而不是质量。

这可能会诱使某些人匆忙解决问题以清除其列表，并稍后查看错误报告中返回的内容。

要纠正这种平衡，请执行以下操作：

• 在问题跟踪系统中一次只分配几个项目，
• 代码检查并尽快测试他们"完成"的所有内容，如果有任何问题，它将立即与他们联系
• 与他们谈谈我们对某件商品需要多长时间才能正常工作的期望

如果我们在允许开发人员提交代码之前系统地执行代码审查，那么，问题就可以解决了。但这似乎不是情况，因此，我建议我们这样做：

• 与开发人员交谈。讨论团队中其他人的后果。大多数开发人员都希望得到同行的认可，所以这足够了。还要指出，比起几周前的代码，更容易解决在我们脑海中浮现的代码中的错误。如果我们拥有某种形式的代码所有权，那么这部分很有意义。
• 如果一段时间后仍然无法解决问题，请尝试制定一项政策，使提交错误代码的行为令作者不满意。一种流行的方法是使破坏结构的人负责创建下一个结构。如果构建过程是完全自动化的，则寻找另一项艰巨的任务来代替。这种方法的另一个好处是无需特别指出任何人，这使每个人都可以接受。
• 使用纪律措施。根据团队和公司的规模，可以采用多种形式。
• 解雇开发人员。养坏苹果需要付出一定的代价。当我们走到这一步时，开发人员将不再关心他的同伴开发人员，并且我们已经遇到了人员问题。如果工作环境中毒，我们可能会比这个坏的开发人员损失更多的钱-在生产力和人员方面–都是如此。

这里有一些关于棚户区的想法。

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!

等等。用"草率的开发人员"替换"醉酒的水手"。

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

能见度

如果环境允许将代码推出，等待用户发现问题，然后本质上询问"现在怎么样？"更改代码后，没有真正的动机去测试自己的东西。

与我们在同事处理" Widget Y"和" Widget Z"时仅提供" Widget X"相比，代码审阅和协作鼓励我们更加努力地制作高质量的产品

作品越可见，我们就越可能会在意它的效果。

NCover + Cruise Control，发送自动报告，然后一个人可以证明，他检查代码覆盖率下降了。

代码审查和单元测试。

作为(像许多人一样)检查微小变化并破坏事物的人，我可以告诉我们，单元测试消除了不进行测试的任何借口(如果已设置)，因此我们可以快速运行整个全景，并且有助于确定谁破解了密码(假设使用了不错的VCS)。当然，通过非正式的代码审查，我检入了由高级(和称职)同事审查过的琐碎代码，但仍然破坏了代码库。

仪式殴打！对于每个错误，鞭打一鞭！

(为任何不懂的人开个玩笑)

在某些事情被认为"完成"之前，使已执行的测试用例成为交付品之一。

如果我们还没有执行测试用例，那么工作就不会完成，并且如果在我们记录了测试用例的执行之前已经过了最后期限，那么他就不会准时交付，其后果将与他已经执行尚未完成开发。

如果我们公司的文化不允许这样做，并且它重视速度而不是准确性，那么这可能是问题的根源，而开发人员只是对现有的激励措施做出了回应-他因做很多事情而获得回报半打半倒，而不是少做些正确的事情。

看起来很简单。提出要求，如果他做不到，请更换他。你为什么要保留他？

• 让他"帮忙"构建，并成为构建经理。这样可以减少他开发代码的时间(从而提高每个人的性能)，并教会他为什么必须要有一个良好的构建。
• 强制执行测试用例-如果没有单元测试用例，则无法提交代码。修改构建系统，以便如果测试用例无法正确编译和运行，或者不存在，则整个任务签入将被拒绝。

-亚当

如果与他交谈没有用，并且我们不能解雇他，那么他或者懒惰或者不讲理。如果我们不能和男生一起走高路和理智，那就在伤到他的地方打他，然后开始对付他的薪水。或者，如果我们真的想惩罚他，请让他维护代码。

使人清洁厕所。在军队工作。而且，如果我们与一群吃很多印度食物的人一起工作，他们很快就可以排成一列。

但这就是我...

介绍代码覆盖率工具，并从构建服务器生成有关单元测试未覆盖的所有代码的自动报告。他的名字将是董事会的底部。

董事会应每周印刷并粘贴在每个人都能看到的地方。

停止给他做任何新的事情，直到他的覆盖率达到85％

给最顶层的人提供最有趣的工作。

将下一个书面警告与特定代码覆盖率要求联系在一起，那么如果他失败了，我们就有明确的解雇原因。

每次开发人员检查无法编译的内容时，请将一些钱放入罐子中。在办理入住手续之前，我们需要三思而后行。

告诉他，他将被重新分配到质量团队，他将只做文档记录。对于我领导的团队来说，这对我不止一次起作用...如果不起作用，请找其他人来测试他的代码！ ..等等，那真是la脚...哦，是的。解雇他！！！

不幸的是，如果我们已经多次与他交谈并给他书面警告，我会说是时候将他从团队中删除。

这取决于。

他的代码有效吗？
他是我们团队中生产力最高或者生产力最低的成员吗？
程序代码比其他程序错误吗？
他/她的贡献有多有价值？

如果他是一位出色的表演者，会产生高质量的代码，那么他会在乎。另一方面，如果他/她正在生成错误代码，则请该人坐下，与他们交谈，说明后果，然后他们或者加入，或者不加入

我们提到与开发人员交谈，但我很好奇我们是否询问他们的测试程序。如果他们来自另一家公司，则可能习惯于编写所有代码，检入代码，进行测试，然后检入代码的最终版本。如果他们正在查看签到，这只是保存工作的另一种方式。

但是，如果他们在贵公司工作了很长时间(例如至少六个月)，则应该习惯于他们做事的方式，而这并不是更长久的有效借口。

我通常不主张这样做，除非其他所有方法都失败了...

有时，公开显示的开发人员错误计数图表可以施加足够的同伴压力，以获得满意的结果。

简单的。让开发人员负责验证所报告的错误，并修复所产生的错误。不要让此人从事新功能。

如果这个人只有半个头脑，他们将很快因非单元测试代码引起的骨头错误而发展出一定程度的烦恼。此外，此人的整体技能可能会显着提高。

如果甚至对他的代码进行的代码审查都行不通，则可能给他一个任务，以审查他可能与自己的问题有关的其他"奇妙"(;))代码，并要求他将其代码与该糟糕的代码进行比较。代码。

通常，这类人遇到的问题是自我实现，所以无论我们如何尝试使他理解自己的代码所带来的问题，都是如此。直到并且除非他本人不知道，否则它不会起作用。当然是这样，如果我们没有解雇他的权利，实际上是想修饰他。

听起来我们已经向他明确表示，这对我们，公司和团队都很重要。

我认为我们需要找出他的行为背后的原因是他只是不听我们在说什么？也许我们需要找到另一种表达方式。

也许他不相信有很多原因可以找到根本原因并加以解决。

对等编程是另一种可能性。如果他与团队中另一个经验丰富的开发人员在一起，他们死后符合质量标准并且知道程序，那么这将带来一些好处：

• 在经验丰富的开发人员的支持下，他将学习对他的期望，并查看他的代码与满足期望的代码之间的区别
• 另一个开发人员可以执行测试优先策略：在为代码编写测试之前，不允许编写代码
• 同样，另一位开发人员可以在检入代码之前验证代码是否符合标准，从而减少大量的不良检入操作

当然，所有这些都要求公司和开发人员必须接受他们可能不愿意接受的这一过程。

似乎人们已经对这个问题提出了许多富有想象力和曲解的答案。事实是，这不是游戏。将精心设计的同伴压力系统设计为"给他起名并感到羞耻"并不能解决问题的根源。他为什么不写测试？

我认为你应该是直接的。我知道我们说过我们已经与他交谈，但是我们是否试图找出他为什么不编写测试的原因？显然，在这一点上，他知道自己应该这样做，因此，肯定有某些原因导致他没有按照被告知的方式去做。懒惰吗？拖延？程序员以其自负和强大的见解而闻名，也许他出于某种原因而深信测试是浪费时间，或者他的代码始终是完美的并且不需要测试。如果他是一个不成熟的程序员，那么他可能不会完全理解他的行为的含义。如果他"太成熟"，他可能会束手无策。不管是什么原因，请解决。

如果确实有意见问题，则需要让他明白，他需要将自己的个人意见放在一边，并遵守规则。明确指出，如果不能信任他遵守规则，那么他将被替换。如果他仍然不这样做，那就这样做。

最后一件事记录了所有讨论以及由于他的更改而发生的任何问题。如果遇到最坏的情况，我们可能会被迫为自己的决定辩护，在这种情况下，拥有书面证据无疑将非常宝贵。

如果无法进行对话，请制定一个策略，将无需进行附带测试的情况下检入的代码直接从存储库中撤回。他们不得不重写几次代码后，他们可能会收到消息。

我建议(和其他人一样)：

• 代码审查，
• 配对编程
• SCM提交策略。

我们可以告诉版本控制系统，该用户无权上传任何内容，因此他必须要求某人为他完成此操作。那应该教他。

在团队内部就将要测试的内容，应该如何测试以及应该何时测试(签入之前，推送之前，合并到主干之前)达成协议。

然后，当签入不符合一组标准时，团队同意的代码应符合，只需将其回滚，并要求开发人员对其进行修复。回滚签入是一种非常有效的方式，既可以在签入质量较差的情况下保持代码库的质量，又可以作为一种轻量级的方式向人们发出信号，说明他们的代码不符合团队设定的标准。

关于回滚的一个很好的部分是，只需回滚回滚，修复所有问题，然后再次检查更改，就很容易检查回代码。

我将以一种非常客观的方式来谨慎行事，不会向任何人发出信号。这意味着将其应用到整个团队中，而不仅仅是问题成员，并专注于使它更多地关于代码的质量，并使被检入的代码符合团队彼此设置的标准，而不是作为一种惩罚。 。

尝试胡萝卜，使其成为一个有趣的游戏。
例如，Hudson的持续集成游戏插件
http://wiki.hudson-ci.org/display/HUDSON/The+Continuous+Integration+Game+plugin

我们说他不测试他的代码。这是否意味着他不创建单元测试？还是他根本不测试自己的代码？

如果他根本不测试他的代码，那么这是他开发的根本问题。测试我们编写的代码是工作的一部分。不测试其代码的开发人员是不可接受的，并且会降低项目速度。测试是开发人员(甚至是所谓的明星)工作说明的一部分。

但是，如果他正在测试自己的代码但未创建"正确"数量的自动化单元测试，则这是一个不同的问题，需要不同的解决方案。正如其他人所说，我们需要找出原因并加以解决。代码审查是发现这些问题的好方法。但是听起来我们已经知道问题所在。

我们可能会在这里找到一些有用的答案：如何使初级程序员编写测试？

如果我们与他进行了真诚的交谈，并且我们给予了他所有的支持和培训，他需要了解为什么这很重要，那么我会考虑摆脱他(如何运作取决于我们在世界上的哪个角落)是)。我知道我们说我们除了解雇他外还想要其他东西，但有时并没有解决问题的"不错"的解决方案。

不用苛刻，程序员总是谈论离开那些不重视软件开发的公司。

如果这是合理的，那么公司为什么要忍受已经给了每个合理机会但仍然显然不认真对待软件开发的开发人员呢？

我很想建议我们详细介绍一下我们尝试过的方法和获得的结果，因为这可能会有所变化，但这是我的初步建议：

• 是测试还是综合测试？有些人可能盲目地编写代码并进行零测试，但这是相当罕见的IME。通常，已经进行了一些测试，但不足以涵盖将要进行全面测试的大多数情况。
• 小组动态可能会有所帮助。我认为他是团队的一员，并且团队的观点在这里可能会有所帮助。从某种意义上说，这试图获得同伴的压力，这通常是一件坏事，但有时可以很好地加以利用。
• 警告的表达方式如何？从某种意义上说，这似乎很幼稚，但我们可能认为测试与他的想法可能不同。我们是否要使用nUnit测试，excel电子表格，来自其计算机的日志或者其他用于证明测试存在和使用的证据？根据描述，没有任何证据可以证明他确实了解意思，打算使用测试并提供这样做的证据。
• 入住政策问题。有些地方，例如我目前的工作场所，鼓励经常提交，这可能意味着人们确实在没有测试的情况下提交了代码。我们所在的地方是否有一个已知的，被接受的且遵循良好的政策？这是另一方面。

如果我们已设置了自动构建，则请确保故障通知尽可能明显且令人讨厌。开发公共区域中的墙板或者音频通知是一个好的开始。然后，确保一个构建被破坏，确保在违规者解决问题之前，没有人签入代码。

当然，只有在他的代码破坏了构建时，它才能抓住它，但是，不断受到关注的同伴压力对于大多数人来说都是一个诱因。如果这样做没有帮助，请通过人力资源部门采取下一个纪律处分。我们已经与他交谈过，我们已经发出了书面通知，以了解下一步的工作。走自己的路的开发人员或者是有远见的人，或者不是团队合作者，而我个人从来没有在这方面与有远见的人一起工作的乐趣。