并行开发w/o中心设计？

Question

我有一个开发团队，他们试图同时为系统的不同(有时甚至相邻)部分编写规范/测试。

通常，编写规范/测试的人不是编写实现并通过规范/测试的开发人员。

下面是我们面临的问题:尚未编写实现的规范/测试的接收者对系统的许多对象的设计还不熟悉：

我是用现有的对象(S)来解决这个问题(规范/测试)，还是第一次创建允许系统通过该规范/测试的依赖项？

并非项目中的所有开发人员都有领域知识来很好地做出这些决定，而且我们正在发生冲突，因为在相对孤立的情况下创建的不同设计和对象开始相互冲突和重复。

这个问题的解决办法(S)是什么？项目中的每个开发人员都必须知道(或准备询问)系统的对象，这是否是不可避免的？

可以自由地提供你认为是显而易见的答案。

Answer 1

该系统用于什么领域？我的经验是，所有这些编写规范往往是过分的。在拥有软件的想法或愿景的人和正在实现软件的人之间加强沟通和协作通常更有帮助。它是核心敏捷价值观(http://agilemanifesto.org/)的核心之一，在文档之上工作的软件(我包括大量的文件到文档)。

在我看来，每个开发人员都必须了解域，对于域名新手来说，这涉及到投资。一个非常有用的方法是进行对对编程，或者请一位导师介绍对系统各部分了解较少的开发人员。

当然，当规范密集的方法是问题的最佳解决方案时，这个规则也有例外。它还取决于系统的大小和团队的大小。所以也许你可以给出更多的细节。

Answer 2

并不是所有的项目开发人员都有领域知识，可以很好地做出这些决定。

如果一些开发人员对系统的目的或客户需求缺乏深入的理解(客户领域的知识)，那么他们需要更长的时间来编写，而编写的代码将需要更多的测试和更多的返工。这是一种典型的尝试性学习方法，是一种成本和投资.

如果有些开发人员没有很好地设计架构，那么将设计工作委托给更好的架构师。好的设计不仅需要领域知识，例如架构智慧，有些程序员比其他程序员做得更好，而且这种智慧不会随着经验线性增长。这有两种方法可以发挥作用：

• 架构师可以指定启联和接口方法，并让其他开发人员实现细节。
• 架构师可以事后进入，并在代码/spec/测试已经稳定的情况下监督项目的重构。

如果你想让软件架构和目的很好地匹配，那么.换个团队或者换个公司。DDD通常有“非专家不需要应用”的政策。

通常，编写规范/测试的人不是编写实现并通过规范/测试的开发人员。

如果一个规范/测试过于笼统/模糊/庞大，开发人员无法实现.把它们分解成更小的规格/测试。

我是用现有的对象(S)来解决这个问题(规范/测试)，还是第一次创建允许系统通过该规范/测试的依赖项？

在你的情况下，我建议你接受返工。有时，创建/重用问题的答案并不明显。一有时间就问一位建筑师。如果不是，抛硬币。

..。到目前为止，我们正在发生冲突，因为在相对孤立的情况下创建的不同设计和对象开始相互冲突和重复。

以下是我在一个较小的项目中使用的一种方法。对于较大的项目，它可能是不可扩展的。

每个团队成员从阅读所有其他团队成员的代码更改开始一天的工作。

(这适用于“每个人都在一个巨大的房间与其他团队共享”设置，因为它可以做到绝对沉默。它也适用于地理上分散的团队，因为它不占用面对面的时间。拥有专用办公空间的团队可能会发现配对编程更合适。)

(这项工作是可管理的，每天提交10个源，或500行更改。)

Answer 3

听起来，您可以通过将所有主要开发人员聚集在一起，在实现之前讨论每个新规范来节省大量资金。

最重要的是沟通，如果你不知道你不能使用。