如何创建和维护代码重用库？
我正在尝试设置可重用代码的存储库。 我在考虑让每个可重用的代码模块都有一定的“成熟度等级”。 评级将被定义为可重用代码位于特定要求集内的级别。 最高成熟度级别将是预定义要求集中的最高标准度。
例如：
水平; 要求; 描述
0级; 代码合法使用; 该代码在商业行业/多个合同/等中是否合法？
1级; 基本代码行并满足0级要求; 原型代码，第三方工具等
2级; 具有function界面和注释，符合1级要求; 每个类和函数的足够文档; 能够从评论中确定function
3级; 遵守编码标准，符合2级要求; 遵循定义的编码标准并通过代码检查实用程序测试
4级; 包括测试用例并满足3级要求; 有足够的测试用例来测试代码的所有function
5级; 经再利用委员会批准，符合4级要求; 由重用专家和同行审核并validation其符合所有成熟度级别
我想知道这个成熟度级别是否应该是一个层次结构，为了进入下一个级别，你需要满足所有以前级别的要求（如上所示）？
或者它是否应该是满足下一级别的要求的子集？
例如，我们满足x个y要求，我们可以进入下一个级别（要求与上面提到的相同）。
0级，满足6个要求中的0个
1级，满足6个要求中的1个
…
我在子集方法中看到的问题是某些要求应该具有更强的权重，并且在这种方法中不会被考虑（除非我开始具体化，满足b和x中的y等）。 但随后它可能会变得复杂起来。
有没有人以前做过这个，如果有的话，你是如何设置你的图书馆的？ 您是否拥有所有或其他结构的成熟度？ 任何投入将不胜感激。
设置代码重用存储库是一项艰巨的任务。 主要的困难不在于如何设置它，而在于如何传达存储库中各种库的存在 。 只有在使用库时才重用库，并且只有在知道它们时才使用它们，并且只有在代码质量高且满足用户需求的情况下才能广泛使用它们。
我喜欢成熟度水平的想法，但正如其他人发布的那样，可能还有相当多的设置/构建工作要做。 我已经想到了一种类似于构建应用程序的方法 – 我称之为置信度。 在应用程序构建领域，低可信度构建是未通过unit testing的构建; 中等信度可能包括通过unit testing，但不包括集成测试，等等。 这是与QA和用户沟通期望的良好机制。 类似的机制可能适合图书馆。
文档注释是必须的，并且在放入代码时也必须尽可能多地注意它们。 评论应该传达什么，为什么，在哪里，何时，如何，哪些等等。您的构建过程应该将文档发布到一个众所周知的位置（同样，沟通是关键）。
沿着沟通的方向，不时地呈现那里的东西并没有什么坏处。 再次！ 通讯。
因此，每个库的构建至少应该：
- 发布图书馆（也许通知订阅者）
- 发布文档
- 运行unit testing
- 公布成熟度
至于成熟度级别，我会用“级别名称”和级别的含义描述来定义它们。 发布升级或升级的标准。 实际上，现在我考虑一下，也许您需要一组正交标准：代码级别，文档级别，使用策略（即必须拥有XYZ许可证）以及其他属性。 我建议你以较小的增量进行处理。 在一天结束时，向最终用户提供function非常重要。
您还必须将自然推送可重用位的思维模式传达到存储库中。 开发人员必须有动力去做这件事。 寻找重复和同行评审的静态代码检查工具到目前为止还没有。 有人必须实际将代码移动到存储库。
最后，我建议您在存储库的设置，构建，维护和通信中尽可能多地使用工具支持。 否则，与任何非代码工件一样，您将面临一定量的熵，当非代码工件变为过时时，该熵会降低该值。
我认为您会发现很难确保整个开发团队足够准确地遵循这些准则。 特别是当指南可能以这种或那种方式解释时。 此外，如果某人通过添加测试来改进一段代码并且突然必须转移到另一个项目，那将是一个巨大的痛苦。 更有可能的是，此类代码将保留在最初放置的项目中，并且随着时间的推移，成熟度级别将变得毫无意义。
我认为在大公司工作正常的一种方法是：
- 所有第三方库都提交到特殊目录，并始终包含版本号。
- 我们自己的公共库根据它们对其他事物的引用进行划分。 例如，如果实用程序代码引用
Infragistics库，则此位实用程序代码将进入InfragisticsUtils库。 - 我们自己的共同库，形成清晰可识别的“单位”进入单独的库。 例如，处理定价证券的代码库是一个单独的项目。
- 所有不满足上述任何要求的可重用代码都会进入一个包罗万象的
Utilities项目。 - 我们自己的库被编译并发布到项目可以引用它们的共享位置。 由项目的开发团队决定是否要引用已编译的二进制文件或仅将实用程序项目包含在其解决方案中。
显然，您在catch-all Utilities库中找到的代码质量可能会有很大差异。 为了缓解这种情况，我们只是确保来自不同开发团队的两个人审核了所有签入Utilities 。 这清除了很多没有地方的东西！
我认为一个优秀的代码库将包括一个CM工具和一个Wiki工具。 CM工具应该使用级别构思（如您所建议的）构建，因为它按质量构建代码。 维基应该充当软件可以做什么以及它如何帮助你的“广告”。 这个wiki还可以保存信息，例如哪些项目正在使用代码，评估它的可用性以及如何使用它的示例。 如果有人担心开发团队遵循级别指南，那么应该指出自我管制是如何工作的，并举例说明它与wiki的工作情况。
现在，CM工具的结构很重要。 它旨在传达代码的质量，因此您知道在使用它时会遇到什么。 例如，如果你编写一个几乎没有任何注释的简单类，并且它并不真正支持编码标准（可能是原型），那么它将被输入\ sw_repository \ level0 \ ExamplePrototype。
也许有人会接受这段代码并添加评论并将其提升到标准。 然后那个人将它放在\ sw_repository \ level1 \ ExamplePrototype中。
然后，同一个人，稍后，为ExamplePrototype创建unit testing。 然后这将转到level2，依此类推。
定义水平应该考虑一下。 它们实际上应该是有些顺序的，即使例如，您已经为原型代码编写了unit testing，但它不满足注释和编码标准，那么无论如何它都被置于level0中。 但是，如果满足这些评论和标准，那么很容易进入第2级。
对于我的库，我只是输入我编写的代码，可以在多个应用程序中使用。 如果代码特定于特定应用程序，则它不会进入库。 随着越来越多的应用程序使用它，错误得到解决，所以我从来没有想到它会立即无bug。 随着您的图书馆的成熟和不同的应用程序的压力，将不断找到并修复错误。 它永远不会没有bug，但随着时间的推移会接近可靠性。 此外，当我意识到某些东西的API错误时，我不担心它并尽快重构API。
这是我在c ++中的库
http://code.google.com/p/kgui/
多年来，微软一直是所谓的软件工厂的大力倡导者，其中很大一部分致力于解决重用问题。
重用有什么问题？ 首先，这很难。 很难想出一个能够满足当前项目当前需求的库和API。 你如何预测未来？ 此外，作为知识库和充满活力的实践社区的集中存储库的问题非常具有挑战性。 你如何制作既灵活又易于使用的产品？ 许多人尝试过但都失败了。 软件工厂和软件产品线都试图解决这些问题。
祝好运！
Kit提到了最重要的问题：重用 。 其余的想法很好，但它只不过是一个细节。
我的意思是，我自己无法维护我自己的重用库。 有时候我会做一个特定于项目的实现，或者我会做一些想法的第n个原型，而且这些都没有进入我的库。
如果你真的成功拥有一个代码重用库，许多开发人员都会以一种纪律的方式使用和维护它，而不是那种胜利。 您需要一个版本控制系统和一个错误跟踪器，后者由项目所有者和用户使用。 你需要沟通和贡献的方式。 少数开发人员使用项目可以显着提高其质量。 实施变得更好。 文档已创建。 API和function设计处于更高的层次。 委员会是一件好事，但它无法决定，给定代码有多好，而不实际使用它。 它可以决定代码是否符合特定标准，但满足标准对于良好的库来说是不够的。
你需要尽力确保，你没有大量的代码片段，所有这些都可以或多或少地做些什么。 好吧，任何设计决策都有利有弊，但我认为，从一个项目开始为给定任务开始更有意义，并且如果真的有必要分支它，但保持项目团队之间的沟通，并考虑（部分）合并背部。
不要过分担心不同项目的质量分类。 如果项目不好，那么用户/开发人员会将其推向更好的水平。 大多数人都很聪明地看到，当图书馆是好的，什么时候不是。 你真的需要把精力放在这些共生效应上，而不是试图用严格的规则给参与者带来负担。
只是我的2美分……;）
看看Will Tracz的“使用过的程序推销员的自白”，以及惠普重用Rabbi，Martin Griss的内容。
我认为你在非问题上思考得太多了。
你是怎么设置我的图书馆的？ 很简单，如果您在两个或多个项目中使用相同（或几乎相同）的方法，请将其移至库中。
拥有一个人自己的图书馆被认为是一种很好的方法，但千万行是一个废墟！