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

Question

如果开发人员在签入源代码控制之前在其开发环境中执行单元测试，那么应该共享该环境（包括测试失败）？

所有的构建应该公开吗？

Answer 1

我觉得在沙箱里工作是个好主意。它为我节省了几次。我通常有几个不同的虚拟机在我用于开发的环境中漂浮，如果我把它搞糟真的很糟糕，我不必等待我的机器被重建。

我不认为所有来自简单开发人员构建的测试结果应该公开。我并不是真的担心通过让所有的失败成为公众的必要而伤害某人的感情，但我担心他们提供的信息是无用的。

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

Answer 2

我认为让开发人员建立公开是不切实际的。您不希望遇到您的团队成员遇到每次构建失败（单元测试失败）。

你总是在为某些问题创建解决方案的过程中，并且机会是你第一次无法正确完成，所以经常会发生单元测试失败。特别是如果你采用测试驱动的方法来开发你的代码：首先编写你的单元测试并实现功能，这样它不会再失败。

Answer 3

是的，开发人员应尽可能在沙箱中工作。没有构建不应该默认公开。 TDD将导致测试和代码的多次故障和改进。公开共享构建可能会令人烦恼，但其他开发人员当然应该能够看到某人正在关注的内容，只要他们关心的足以去看看。当被要求时，他们应该公开。如果你要求证明他们在检查代码之后测试了运行他们的单元测试的东西，那么应该足够证明。

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

Answer 4

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

这只是为了分散每个人的注意力。

避免做某件事的诱惑，只是因为它可以做;让你的需求驱动你的过程。不要因为可以创建新的流程。

Answer 5

孩子们应该玩沙盒;），软件开发人员应该在他们自己的PC上玩，并在他们认为符合某种质量水平时提交他们的代码。当每个人都经常提交并更新少量和经过测试的代码片段时，我的经验是，没有发生严重的问题，只有建设性的反馈，有时候会有人喊出一些东西。最后将软件发布给公众/客户是另一回事。这需要广泛的测试，编写发行说明，更新手册，市场营销等。