如何创建和维护代码重用库？

Question

我正在尝试设置可重用代码的存储库.我在想每个可重用的代码模块都有一定的"成熟度"等级.评级将定义为可重用代码位于特定要求集中的级别.最高成熟度级别将是预定义要求集中的最高标准度.

例如:
等级; 要求; 描述
等级0; 代码合法使用; 该代码在商业行业/多个合同/等中使用是否合法？
1级; 基本代码行并满足0级要求; 原型代码,第三方工具等等
2级; 具有功能界面和注释,符合1级要求; 每个类和函数的足够文档; 能够从评论
等级3 确定功能; 遵守编码标准,符合2级要求; 遵循定义的编码标准并通过代码检查实用程序测试
级别4; 包括测试用例并满足3级要求; 有足够的测试用例来测试代码
级别5的所有功能; 经再利用委员会批准,符合4级要求; 由重用专家和同行审核并验证其符合所有成熟度级别

我想知道这个成熟度级别是否应该是一个层次结构,为了进入下一个级别,你需要满足所有以前级别的要求(如上所示)？

或者它是否应该是满足下一级别的要求的子集？

例如,我们满足x个y要求,我们可以进入下一个级别(要求与上面提到的相同).

等级0,满足6个要求中的0个
等级1,符合6个要求中的1个
......

我在子集方法中看到的问题是一些要求应该具有更强的权重,并且在这种方法中不会被考虑(除非我开始具体如此,满足b和x中的y等).但随后它可能会变得复杂起来.

有没有人以前做过这个,如果有的话,你是如何设置你的图书馆的？您是否拥有所有或其他结构的成熟度？任何投入将不胜感激.

Answer 1

设置代码重用存储库是一项艰巨的任务.主要的困难不在于如何设置它,而在于如何在存储库中传达各种库的存在.只有在使用库时才重用库,并且只有在知道它们时才使用它们,并且只有在代码质量高且满足用户需求的情况下才能广泛使用它们.

我喜欢成熟度水平的想法,但正如其他人发布的那样,可能还有相当多的设置/构建工作要做.我已经考虑过类似的应用程序构建方法 - 我称之为置信度.在应用程序构建领域,低置信度构建是未通过单元测试的构建; 中等信度可能包括通过单元测试,但不包括集成测试,等等.这是与QA和用户沟通的良好机制.类似的机制可能适合图书馆.

文档注释是必须的,并且在放入代码时也必须尽可能多地注意它们.评论应该传达什么,为什么,在哪里,何时,如何,哪些等.您的构建过程应该将文档发布到一个众所周知的位置(再次,沟通是关键).

按照沟通的方式,不时出现那里的东西并没有什么坏处.再次!通讯.

因此,每个库的构建至少应该:

• 发布图书馆(也许通知订阅者)
• 发布文档
• 运行单元测试
• 发布成熟度级别

至于成熟度级别,我会用"级别名称"和级别的含义描述来定义它们.发布升级或升级的标准.实际上,现在我考虑一下,也许您需要一组正交标准:代码级别,文档级别,使用策略(即必须拥有XYZ许可证)以及其他属性.我建议你以较小的增量进行处理.在一天结束时,向最终用户提供功能非常重要.

您还必须将自然推送可重用位的思维模式传达到存储库中.开发人员必须有动力去做这件事.寻找重复和同行评审的静态代码检查工具到目前为止.有人必须真正完成将代码移动到存储库的工作.

最后,我建议您在存储库的设置,构建,维护和通信中尽可能多地使用工具支持.否则,就像任何非代码工件一样,当非代码工件变得过时时,您将面临一定数量的熵,这会降低该值.

Answer 2

我认为您会发现很难确保整个开发团队足够准确地遵循这些准则.特别是当指南可能以这种或那种方式解释时.此外,如果某人通过添加测试来改进一段代码并且突然必须转移到另一个项目,那将是一个巨大的痛苦.更有可能的是,此类代码将保留在最初放置的项目中,并且随着时间的推移,成熟度级别将变得毫无意义.

我认为在大公司工作正常的一种方法是:

• 所有第三方库都提交到特殊目录,并始终包含版本号.
• 我们自己的公共库根据它们对其他事物的引用进行划分.例如,如果实用程序代码引用了Infragistics库,则此位实用程序代码将进入InfragisticsUtils库中.
• 我们自己的共同库,形成清晰可识别的"单位"进入单独的库.例如,处理证券定价的代码库是一个单独的项目.
• 所有不满足上述任何要求的可重用代码都会进入一个包罗万象的Utilities项目.
• 我们自己的库被编译并发布到项目可以引用它们的共享位置.由项目的开发团队决定是否要引用已编译的二进制文件或仅将实用程序项目包含在其解决方案中.

显然,您在catch-all Utilities库中找到的代码质量可能会有很大差异.为了缓解这种情况,我们只是确保来自不同开发团队的两个人审核了所有签到Utilities.这清除了很多没有地方的东西!