大型团队中的常见库

假设您有五种产品,并且所有产品都使用公司内部库中的一个或多个,由各个开发人员编写.

这听起来很简单,但在实践中,我发现这是非常难以维持.

您如何处理以下情况:

开发人员无意中引入了一个错误并破坏了生产中的所有内容.

每个库都必须成熟,这意味着API需要不断发展,那么如果每个开发人员在非常忙于其他项目时需要更新/测试他们的代码,那么如何将更新版本部署到生产中？这是资源和时间问题吗？

版本控制,部署和使用.您是将它存储在一个全局位置还是强制每个项目使用,例如,svn:externals来"绑定"一个库？

我发现制定一个好的策略非常困难.我自己的宠物理论是这样的:

每个公共库都必须有一套超级全面的测试,否则它永远不应该是常见的,即使它意味着其他人重复这些努力.重复的未经测试的代码优于常见的未经测试的代码(您只破坏一个项目).

每个公共库都必须有一个专门的维护者(可以通过一个小团队中非常好的测试套件来抵消).

每个项目都应该检查已知可以使用它的库的版本.这意味着随着公共代码的更新,开发人员不必为了更新API使用而被撤下.它会是什么.每一段非常重要的代码都会在数月和数年内发展.

谢谢你对此的看法!

你在这里有一套相互竞争的目标.首先,可重用组件库必须足够开放,以便其他项目的人员可以轻松添加(或向其提交组件).如果他们这样做太难了,他们将构建自己的库,忽略常见的库,导致大量重复代码和浪费精力.另一方面,您希望足够控制库的开发,以确保其质量.

我一直在这个位置.没有简单的答案.但是,有一些启发式方法可以提供帮助.

将库视为内部项目.定期发布.确保它具有明确定义的释放程序,完成单元测试和质量保证.而且,最重要的是,经常发布,以便经常向产品库中提交新的提交内容.

鼓励人们为图书馆做出贡献,而不仅仅是建立自己的内部图书馆.

让人们可以轻松地为图书馆做出贡献,并使标准清晰明确(例如,新课程必须附带单元测试和文档).

让一两个开发人员负责库,并且(重要!)为他们分配时间来处理它.一个被视为事后想法的图书馆很快就会成为事后的想法.

简而言之,在成功的开源库项目之后,对内部库的开发和维护进行建模.

我不同意这点:

重复的未经测试的代码优于常见的未经测试的代码(您只破坏一个项目).

如果你们同样有可能通过实现相同的东西来创建bug,那么你们都必须在"重复"库的每个实例中修复潜在的不同错误.

似乎一次编写库会更快/更便宜,而不是让其他多个团队编写相同的东西,将一些资源分配给测试.

现在解决你的实际问题:我模仿我们用真正的第三方库做的事情.我们使用特定版本,直到我们准备好或被迫升级.我不会因为我可以升级所有东西 - 必须有一个理由.

一旦我看到了这个原因(错误修复,新功能等),那么我升级的风险是新库可能有新的错误或破坏更改.

因此,您的图书馆项目将在必要时继续开发,而不会影响各个团队,直到他们准备"升级".

您可以发布版本或peg/branches/tag svn来帮助完成所有这些.

如果所有团队都可以访问错误跟踪器,他们也可以在升级之前轻松查看升级候选者中存在哪些已知问题.或者,您可以自己维护该列表.

@Brian Clapper提供了一些关于如何在他的答案中将您的库作为项目运行的出色指南.