开发人员应该在沙盒中工作吗？

Question

如果开发人员在检查源代码管理之前在其开发环境中执行单元测试，那么是否应该共享该环境（包括测试失败）？

所有版本都应公开吗？

Answer 1

我认为将开发人员构建公开是不切实际的。您不希望在遇到的每个构建失败（单元测试失败）时打扰您的团队成员。

您始终在为某些问题创建解决方案，并且您可能无法在第一时间做到正确，因此单位测试失败将经常发生。特别是如果您采用测试驱动的方法来开发代码：首先编写单元测试并实现功能，这样它就不会再失败了。

Answer 2

我认为在沙盒中工作是个好主意。它救了我几次。我通常会有几个不同的虚拟机浮动，我用它来进行开发，如果我把它弄得很糟糕，我就不必等待我的机器重建了。

我认为简单的开发人员版本的所有测试结果都不应公开。我并不是真的担心通过公开所有失败来伤害别人的感受，但我担心他们提供的信息没用。

调查某种类型的系统会很有趣，因为开发人员在检查时需要提交通过的测试结果，但我认为即使这样也会推动。它可能会对生产力产生不利影响。开发人员已经有足够的非编码工作了。

Answer 3

孩子们应该玩沙盒;），软件开发人员应该在他们自己的PC上玩，并在他们认为满足一定质量水平时提交他们的代码。当每个人定期提交和更新小的和经过测试的代码片段时，我的经验是没有出现严重的问题，只有建设性的反馈，有时候有人会大喊大叫。最后，向公众/客户发布软件是另一回事。这需要进行广泛的测试，编写发行说明，更新手册，营销等等。

Answer 4

是的，如果可能，开发人员应该在沙盒中工作。默认情况下，不应将所有构建都公开。 TDD将导致测试和代码的多次失败和改进。公共共享构建可能很麻烦，但是如果他们非常关心去看看，其他开发人员当然应该能够看到有人在做什么。他们应该在被要求时公开。如果你要求证明他们测试了一些东西，那么在他们检查代码之后运行他们的单元测试应该足够证明。

为开发人员提供自由测试更改的环境，工具和自由将提高软件的稳定性和质量。测试理论和故障排除通常需要小的增量构建。如果沙箱很昂贵，则应该要求它们保留使用它的时间。为每个开发人员提供私有沙箱可能会导致他们的代码长时间分支。问这个的动机是什么？如果开发人员试图隐藏某些内容，那么请找到该问题的根本原因。如果您试图控制成本，请考虑预订模型。

Answer 5

您在此看到了什么好处？特别是，这意味着每个开发人员都会收到每个picayune测试失败的电子邮件。

这仅仅会分散每个人的注意力。

避免因为可能的事情而做某事的诱惑;让您的要求推动您的过程。不要因为你可以创建新流程。