我们的一位开发人员不断编写代码并将其置于版本控制中而不进行测试。因此，我们的代码质量受到了影响。
除了摆脱开发者之外，我该如何解决这个问题？
修改
我和他谈了很多次，甚至给了他书面警告
答案 0 :(得分：42)
如果你可以进行代码审查 - 这是抓住它的理想场所。
我们要求在合并到迭代主干之前进行审核，因此通常会捕获所有内容。
答案 1 :(得分：32)
如果您在允许开发人员提交代码之前系统地执行代码审核，那么您的问题基本上已得到解决。但这似乎不是你的情况，所以这就是我的建议：
答案 2 :(得分：21)
（任何没有得到它的人的笑话）
答案 3 :(得分：14)
作为一个很少测试自己代码的开发人员，我可以告诉你一件事让我慢慢改变了我的行为......
<强>可见性
如果环境允许推出代码，等待用户发现问题，然后基本上问“现在怎么样？”在对代码进行更改之后，没有真正的动机去测试自己的东西。
代码审查和协作鼓励您努力制作高质量的产品，而不是在您的同事处理'Widget Y'和'Widget Z'时提供'Widget X'
你的工作越明显，你就越有可能关心它的运作情况。
答案 4 :(得分：10)
代码审查。每周一早上把你所有的开发人员都放在一个房间里，让他们把他们最引以为傲的代码成就从前一周带到会议中。
让他们成为众人瞩目的焦点，并对解释他们所做的事感到兴奋。让他们带上代码的副本，以便其他开发人员可以看到他们正在谈论的内容。
几个月前我们开始了这个过程，看到发生的次级质量检查的数量令人惊讶。毕竟，如果简单地要求开发人员谈论他们最为兴奋的事情，那么他们就会完全向人们展示他们的代码。然后，其他开发人员将看到质量错误并公开讨论他们错误的原因以及如何真正编写代码。
如果这不能让您的开发人员编写高质量代码，那么他可能不适合您的团队。
答案 5 :(得分：10)
将其纳入年度审核目标。如果他没有实现，就不会加薪。
有时虽然你必须接受某人不适合你的团队/环境，但它应该是最后的手段并且很难处理，但如果你已经用尽所有其他选择，那么它可能是最好的选择。从长远来看。
答案 6 :(得分：9)
告诉开发者您希望在2周内看到他们的做法发生变化，否则您将开始公司的纪律处分程序。提供尽可能多的帮助和帮助，但如果你不能改变这个人，他就不适合你的公司。
答案 7 :(得分：9)
使用Cruise Control或类似工具，您可以使签到自动触发构建和单元测试。你仍然需要确保对他添加的任何新功能进行单元测试，你可以通过查看他的签到来做。 然而，这是一个人为问题，因此技术解决方案只能走到这一步。
答案 8 :(得分：8)
为什么不和他说话？他可能实际上不会咬你。
答案 9 :(得分：8)
让他“保姆”构建，并成为构建经理。这将使他没有多少时间来开发代码（从而提高每个人的表现）并教会他为什么一个好的构建是如此必要。
强制执行测试用例 - 如果没有单元测试用例，则无法提交代码。修改构建系统，以便如果测试用例无法正确编译和运行，或者不存在，则拒绝整个任务签入。
- 亚当
答案 10 :(得分：7)
发布每个开发人员测试代码覆盖率的统计信息，这是在与他交谈之后。
答案 11 :(得分：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!
等。用“邋developer的开发者”取代“醉酒的水手”。
答案 12 :(得分：5)
根据您使用的版本控制系统的类型，您可以设置签入策略，强制代码在允许签入之前通过某些要求。如果您使用的是Team Foundation Server之类的系统，则可以为签入指定代码覆盖率和单元测试要求。
答案 13 :(得分：5)
你知道，这是一个避免单挑他的绝佳机会（虽然我同意你需要与他交谈）并在内部实施测试优先流程。如果规则不明确并且所有人都知道期望，我发现你描述的并不是那么罕见。我发现做第一个测试开发方案对我来说效果很好，并且提高了代码质量。
答案 14 :(得分：4)
他们可能过分关注速度而非质量。
这可能会诱使一些人急于解决问题以清除他们的列表，并看看以后在错误报告中返回的内容。
纠正这种平衡：
答案 15 :(得分：3)
同行编程是另一种可能性。如果他与团队中另一位熟练的开发人员达成质量标准并且知道程序，那么这有一些好处：
所有这些当然要求公司和开发人员接受他们可能不会的这个过程。
答案 16 :(得分：3)
似乎人们已经为这个问题提出了许多富有想象力和狡猾的答案。但事实是，这不是游戏。设计精心设计的同伴压力系统来“命名和羞辱”他并不会找到问题的根源，即。为什么他不写测试？
我认为你应该是直接的。我知道你说你跟他说过话，但是你试过找出为什么他没有写测试？显然，在这一点上，他知道他应该，所以肯定有一些理由说明他为什么不做他被告知要做的事情。是懒惰吗？拖延？程序员以他们的自负和强烈的意见而闻名 - 也许他因某种原因确信测试是浪费时间，或者他的代码总是完美的而且不需要测试。如果他是一个不成熟的程序员，他可能不完全理解他的行为的含义。如果他“太成熟”，他可能会过于习惯。不管是什么原因，请解决它。
如果确实归结为意见问题，你需要让他明白他需要将自己的个人观点放在一边并遵循规则。明确表示如果他不能信任遵守规则，那么他将被替换。如果他还没有，就这样做。
最后一件事 - 记录您的所有讨论以及由于他的更改而发生的任何问题。如果遇到最坏的情况，你可能会被迫为你的决定辩护，在这种情况下，拥有文件证据肯定是非常宝贵的。
答案 17 :(得分：2)
除非所有其他方法都失败，否则我通常不会提倡这一点......
有时，公开显示的开发人员错误计数图表可以应用足够的同伴压力来获得有利的结果。
答案 18 :(得分：2)
看起来很简单。使它成为一项要求，如果他不能这样做，请替换他。你为什么要留下他？
答案 19 :(得分：2)
尝试胡萝卜，让它成为一个有趣的游戏 例如Hudson的持续集成游戏插件 http://wiki.hudson-ci.org/display/HUDSON/The+Continuous+Integration+Game+plugin
答案 20 :(得分：2)
如果您所在的地方可以影响政策，请进行一些更改。在签入之前进行代码审查，并将测试作为开发周期的一部分。
答案 21 :(得分：2)
坚持他自己的开发分支，只有当你知道它已经过彻底的测试时才将他的东西带进行李箱。这可能是像GIT或Mercurial这样的分布式源代码管理工具优秀的地方。虽然SVN中增加了分支/合并支持，但管理它可能不会太麻烦。
修改
只有当你无法摆脱他或让他改变他的方式时，才会这样做。如果你不能让这种行为停止（通过改变或解雇），那么你所能做的最好就是让团队的其他成员免受他编码的不良影响。答案 22 :(得分：1)
如果您设置了自动构建，那么请确保故障通知既明显又烦人。开发公共区域中的墙板或音频通知是一个良好的开端。然后，确保一个构建被破坏，确保没有人检查代码，直到罪犯解决了问题。
当然，这只会在他的代码破坏构建时才能捕获它，但是对于他来说，持续受到关注的同伴压力对大多数人来说都是一种激励。如果这没有帮助，请通过人力资源部门采取下一个可用的学术行动。你已经和他谈过了，你已经给了书面通知 - 找出接下来的步骤。一个走自己的路的开发人员要么是一个有远见的人，要么不是一个团队合作者 - 在这方面，我从未亲自有幸与有远见的人合作。
答案 23 :(得分：1)
您可以在此处找到一些有用的答案：How to make junior programmers write tests?
答案 24 :(得分：1)
如果你真的与他交谈并且你已经给了他他需要的所有支持和培训来理解为什么这是一个大问题然后我会看看摆脱他（如何运作取决于你在世界的哪个方面）。我知道你说除了解雇他之外你想要的东西，但有时候问题不是“好”的解决方案。
没有苛刻的程序员总是谈论让那些不认真对待软件开发的公司。
如果这是合理的，那么公司为什么要提供一个开发人员，但是他们仍然没有认真对待软件开发？
答案 25 :(得分：1)
我很想建议你仔细研究一下你尝试过的东西以及你得到的结果，因为这可能会有所改变，但这是我最初的建议：
是测试还是综合测试？有些人可能盲目编码并进行零测试，但这种情况相当罕见，即IME。通常会进行一些测试但不足以涵盖大部分可以进行全面测试的情况。
团队动力可能会有所帮助。我认为他是一个团队的一员，团队的观点在这里可能会有所帮助。在某种程度上，这是试图获得同伴压力，这通常是一件坏事，但有时它可以很好地使用。
警告的拼写有多清楚？在某种程度上，这似乎是幼稚的，但你认为测试的可能与他的不一样。你想要nUnit测试，excel电子表格，他的计算机上的日志，还是其他东西作为测试存在和使用的证据？根据你所描述的，没有任何东西可以证实他确实理解你的意思，是否会使用测试并提供这样做的证据。
办理登机手续的政策问题。有些地方，比如我目前的工作场所，鼓励经常提交，这可能意味着没有测试就会提交代码。你有一个已知的，被接受的和遵循良好的政策吗？这是另一个方面。
答案 26 :(得分：1)
不幸的是，如果你已经和他多次交谈并给他书面警告，我会说是时候把他从团队中消灭了。
答案 27 :(得分：1)
每次开发人员检查无法编译的内容时，都会在jar中放一些钱。在办理登机手续之前，你会三思而行。
答案 28 :(得分：1)
让人清洁厕所。在陆军工作。如果你和一群吃了很多印度食物的人一起工作，那么他们就不会长时间排队。
但那只是我......
答案 29 :(得分：1)
根据一些逻辑，例如每个功能，每个错误修复，每个开发团队，等等，将您的开发人员放在代码的分支上。然后，错误的签到被隔离到那些分支。在进行构建时，合并到测试分支，找到问题，解决，然后将您的版本合并回主分支。
或删除该开发人员的提交权限，让他们将代码发送给年轻的开发人员进行审核和测试，然后才能提交。这可能会促使程序发生变化。
答案 30 :(得分：1)
您可以在代码中找到一个错误的报告，其中包含负责该软件的程序员的名称。
如果他是一个理智的人，请与他讨论报告。
如果他关心他的“声誉”，定期发布报告并将其提供给所有同行。
如果他只听取“权限”，请执行报告并将问题上报给他的经理。
无论如何，我经常看到，当人们意识到他们从外面看起来有多糟糕时，他们会改变他们的行为。
嘿，这让我想起something I read on xkcd：）
答案 31 :(得分：1)
在某些事情被视为“完成”之前，将已执行的测试用例作为可交付成果之一。
如果您没有执行测试用例，那么工作就不完整了，如果截止日期在您记录的测试用例执行之前通过，那么他没有按时交付，结果将是相同的如果他没有完成开发。
如果贵公司的文化不允许这样做，并且它重视速度超过准确性，那么这可能是问题的根源，而开发人员只是回应现有的激励措施 - 他正在做的事情得到奖励很多事情都是正确的，而不是正确的事情。
答案 32 :(得分：1)
您是指在办理登机手续前编写自动单元测试或手动单元测试吗？
如果您的商店没有编写自动化测试，那么他检查不起作用的代码就是鲁莽的。它会影响团队吗？你有一个正式的QA部门吗？
如果您都在创建自动化单元测试，那么我建议您的部分代码审查流程也包括单元测试。很明显，在您审核期间，根据您的标准，代码是不可接受的。
你的问题相当广泛，但我希望我提供了一些方向。
我同意菲尔的观点，第一步是单独与他交谈并解释质量的重要性。质量差通常与团队，部门和公司的文化联系在一起。
答案 33 :(得分：0)
你试过和他们谈过这个吗？可能不是一个糟糕的第一步。如果问题仍然存在，它还可能为您提供一些关于步骤2应该是什么的线索。
答案 34 :(得分：0)
介绍代码覆盖率工具，并从构建服务器生成单元测试未涵盖的所有代码的自动化报告。他的名字将成为董事会的最低点。
董事会应该每周打印并卡在某个地方，每个人都可以看到它。
在他的报道率为85％
之前，不要再向他提出任何新的事情了让董事会成员中最有趣的工作。
将您的下一个书面警告与某个代码保险要求联系起来 - 如果他失败，您有明确的解雇原因。
答案 35 :(得分：0)
测试你的拼写！我认为你的意思是“他们的代码”。
答案 36 :(得分：0)
你说他没有测试他的代码。这是否意味着他不创建单元测试？或者他没有全部测试他的代码？
如果他根本不测试他的代码，那么这是他的发展的根本问题。测试您编写的代码是工作的一部分。不测试代码的开发人员是不可接受的，并且正在减慢您的项目速度。测试是开发人员（即使是所谓的明星）的工作描述的一部分。
但是，如果他正在测试他的代码但没有创建“正确”数量的自动单元测试，那么这是一个不同的问题，需要一个不同的解决方案。正如其他人所说，你需要找出原因并解决它。代码审查是发现这些问题的好方法。但听起来你已经知道了这些问题。
答案 37 :(得分：0)
在团队内部建立一个协议，了解将要测试的内容以及应该如何测试，以及何时应该进行测试（在签入之前，在推送之前，在它合并到主干之前）。
然后，当签到不符合标准时，团队同意代码应该满足，只需回滚，并要求开发人员修复它。滚动签到是一种非常有效的方法，可以在质量低劣的签到时保持代码库的质量，并且作为一种轻量级方式向人们发出信号，告知他们的代码不符合团队设定的标准
关于回滚的好处是，重新检查代码非常容易 - 只需回滚回滚，修复问题所在，然后再次检查更改。
我会小心翼翼地以一种非常客观的方式做到这一点，并没有发出任何信号。这意味着将它应用于整个团队，而不仅仅是您的问题成员，并专注于使其更多地了解代码的质量，并使得检查的代码符合团队相互制定的标准，而不是作为惩罚
答案 38 :(得分：0)
您可以告诉您的版本控制系统该用户无权上传任何内容，因此他必须要求某人为他执行此操作。那应该教他。
答案 39 :(得分：0)
我建议（和其他人一样）：
答案 40 :(得分：0)
如果说话不起作用，请将一个策略放在其中，而无需附带测试的代码只是从存储库中退出。在他们不得不重写代码几次之后，他们可能会收到消息。
答案 41 :(得分：0)
NCover + Cruise Control，发出自动报告，然后可以证明他在检查代码覆盖范围时会失败。
答案 42 :(得分：0)
代码审查和单元测试。
曾经（像许多人一样）检查琐碎变化并破坏事物的人，我可以告诉你，单元测试会删除任何没有测试的借口，如果它们已经设置好，那么你可以快速地完成全部操作，并且他们帮助确定谁破坏了代码（假设一个体面的VCS）。当然，通过非正式的代码审查，我检查了一个由高级（和称职的）同事审查过的简单代码，但仍然打破了代码库。
答案 43 :(得分：0)
听起来你已经向他明确表示这对你，公司和团队都很重要。
我认为你需要找出他的行为背后的原因 - 他是不是听不到你在说什么？也许你需要找到另一种说法。
也许他不相信 - 可能有很多原因 - 找到根本原因并处理 。
答案 44 :(得分：0)
如果他的代码的代码审查不起作用，也许给他一个任务来审查一些其他“精彩”（;））代码，他可能与他自己的问题有关，并要求他将他的代码与那段糟糕的代码。
通常，这类人的问题是自我实现，所以无论你如何试图让他用他自己的代码来理解问题;除非他自己没有意识到，否则它不会起作用。这当然是，如果你没有选择解雇他，实际上是想培养他。
答案 45 :(得分：0)
简单。让开发人员负责验证报告的错误并修复重现的错误。不要让这个人使用新功能。
如果这个人有半个脑，那么由于没有单元测试代码，他们很快就会因为骨头虫而产生一定程度的呕吐。此外，该人的整体技能可能会显着增长。
答案 46 :(得分：0)
您提到与开发人员交谈，但我很想知道您是否向他们询问了他们的测试程序。如果他们来自另一家公司，那么他们可能习惯于编写所有代码，检查它们，然后进行测试，然后检查最终版本的代码。如果他们将签到视为另一种保存工作的方式。
但是，如果他们已经在贵公司工作了很长一段时间（比如至少六个月），那么他们应该习惯你的工作方式，这不会是一个非常有效的借口。< / p>
答案 47 :(得分：0)
它依赖。
他的代码有用吗？ 他是团队中效率最高或效率最低的成员吗？ 代码比其他代码更乱吗？ 他/她的贡献有多大价值？
如果他是一个出色的高质量代码，那么谁在乎谁是一个出色的表演者。另一方面，如果他/她正在制作错误的代码，那么请让那个人失望，与他们交谈，列出后果，他们要么加入，要么不加入
答案 48 :(得分：0)
如果与他说话不起作用，你就不能解雇他，那么他要么是懒惰的，要么是不合理的。如果你不能走高端路线并与那个人说理，那么就把他打到痛苦的地方并开始对付他的工资。或者，如果你真的想惩罚他，让他维护代码。
答案 49 :(得分：0)
告诉他他将被重新分配到质量团队，他将只做文件。对于我领导的团队来说，这对我来说不止一次......如果这不起作用，找别人来测试他的代码吧！ ..等等，那是蹩脚的......是啊..解救他!!!