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