如何克服公共开源项目中的工具问题？

Question

两个不同的团队(来自不同的公司)正在联合开展一个公共的开源项目。就技术设计达成一致是我们没有问题的事情，但我正在努力解决工具/工作流问题。

我非常喜欢一个名为phpspec (类似于RSpec)的BDD测试工具，而我的很多队友都坚持他们所知道的(phpunit)，而不管这两种工具的优缺点。当成员们有这样的分歧时，你如何推进一个项目呢？你应该执行一个标准测试工具吗？有办法两者兼用吗？

我认为归根结底，这取决于议员是否会冲出舒适区，学习更适合这项工作的新科技。我强烈认为，你应该总是愿意学习新的东西，但我的印象是，其他人纯粹是关心尽快完成事情，从而使用他们以前使用过的工具。

Answer 1

我认为你回答了你自己的问题；虽然你想使用1种工具，但“很多”的同事更喜欢使用其他的工具。如果没有“老板”来决定工具，那么大多数规则和您都需要使用首选的工具。

现在，您没有理由不能尝试与他们一起讨论工具。你必须采取主动，领导围绕变革的辩论，你还必须说服他们同意你的观点，这将需要一些努力。

从他们的角度来思考这个问题。除非您与他们合作，否则他们中的一个可能会发布一个问题：“如何处理一个坚持使用与我们标准不同的工具的开发人员？”如果一个开发人员决定更改您已经同意使用的工具，您会如何反应？

最终，你必须同意使用通用的工具，就像普通的设计一样。如果你不这样做，就会有混乱。

Answer 2

每个项目都需要某种中央领导才能发号施令，做出这样的决策。

在一家公司中，这通常是由管理层任命的项目负责人。在一个大型开源社区中，领导力通常是一种精英式的社区过程，每个参与者都可以提出建议，并由一个专家小组对其进行投票。

您的项目似乎介于这两者之间。两家公司参与的份额相等，让一家公司担任唯一的项目领导对另一家公司来说似乎是不可接受的。但你的规模似乎还不够大，不足以证明你的社区进程涉及到所有繁文缛节和文书工作。

一种可能的解决方案是任命两名项目负责人，每个公司一名，他们共同商定一个共同的工作流流程，并在各自的公司中强制执行。

另一种解决方案是雇佣一位独立的项目负责人，他不是这两家公司的成员。这可以通过组建第三家公司作为一个合资企业来实现，该公司由两个合作伙伴共同拥有，并拥有创建该软件的唯一使命。那家公司唯一的常客是一位独立的项目负责人。您的团队和其他公司的团队仍将被各自的公司雇用，但将被指派为合资企业的承包商。两个团队都会向项目负责人汇报，而项目负责人又会向他的公司的所有者(你们各自的老板)汇报。

Answer 3

我建议您检查需求，并决定哪些工具需要通用。例如，当有大量代码共享时，不能让一些人使用svn，而其他人使用git。然而，当涉及到编辑时，差异可能是可以接受的。人们转换工具的时间、成本和动机基本上都与偏好有关，这往往是不值得的。

一些实际例子：

必须是共同的：

• 正在使用的数据库
• 正在使用的语言
• 源控系统

好的，与众不同：

• git工具- gui's，cli等。终端工件(代码在git中)是相同的。
• 编者-这里有很多选择

一个重要的因素是共享是频繁的编辑器。基本上，如果人们擅长不同的编辑器，你必须首先接受它。在一个开源风格的项目中，人们很可能会坚持他们所知道的，并感到舒服。

如果需要对代码进行配对，则有三个选项：

• 一个人做打字和使用编辑器是舒适和熟练的。
• 两个人都使用一个非常简单的编辑器(记事本、gedit等)。
• 一个人投入时间去学习另一个人使用的编辑器。

我在编辑器方面的个人经验(过去几年在Rails社区工作时)是，人们在编辑器(通常是emacs和vi)之间存在很大的分歧。当涉及到编写代码，甚至是配对时，这并不重要，只要编码人员精通他们的工具，并且观察的人可以跟随并看到代码正常。

在您的例子中，它更多地是关于工具，而不是工具本身。关于在编写代码时使用哪个测试框架(phpspec与phpunit)的问题，这当然很棘手。我认为这可以归结为当你前进的时候会发生什么。每个组/人是否需要阅读或修改他们不知道的在另一个框架中编写的测试？开源协作经常需要这样做。如果是这样的话，您需要就框架达成协议。你将需要在困难和经常有争议的讨论中工作。最好先就事情达成一致.你可以同意..。例如“我们确实需要挑选一个”和‘无论我们在讨论结束时决定什么，我们都同意受它的约束’，‘我们要做的第一件事是仔细听取对方的意见’等等。

对于这个不同工具的问题，我将努力说明为什么我的工具工作得很好而不是其他工具。例如，对于编辑器，它在结尾处的输出是相同的。如果测试用于生成代码(即tdd)并在之后丢弃，那么它们的实现就不那么重要了。如果它们后来被保留并用作回归测试，那么使用相同的框架可能是最有意义的。