我正在尝试建立一个可重用代码的存储库。我正在考虑让每个可重用代码模块都有一定的“成熟度”等级。评级将被定义为可重用代码在一组特定要求中的级别。最高成熟度级别将是一组预定义要求的最高标准。
例如:
等级;要求;说明
0级；代码是合法使用的；该代码在商业行业/跨多个契约(Contract)/等中使用是否合法？
1级;基本代码线并满足 0 级要求；原型(prototype)代码、第三方工具等
2级；具有功能接口(interface)和注释，满足1级要求；每个类和函数的足够文档；能够根据评论确定功能
3级；遵守编码标准，满足二级要求；遵循定义的编码标准并通过代码检查实用程序测试
4级；包括测试用例并满足 3 级要求；有足够的测试用例来测试代码的所有功能
5级；经复用委员会批准，符合4级要求；由重用专家和同行审查并验证它满足所有成熟度级别
我想知道这个成熟度级别是否应该是一个层次结构，为了进入下一个级别，您需要满足所有先前级别的要求(如我上面所示)？
或者它是否应该是满足下一个级别的要求的子集？
例如，我们已经满足了 y 个要求中的 x 个，我们可以进入下一个级别(要求与上面提到的相同)。
0级，满足6项要求中的0项
1 级，满足 6 项要求中的 1 项
……
我看到子集方法的问题是一些要求应该有更强的权重，并且在这种方法中不会被考虑(除非我开始变得具体，比如满足 b 中的 a 和 y 中的 x， ETC)。但随后它可能会开始变得复杂。
以前有没有人这样做过，如果有，你是如何设置你的库的？您是否有成熟度级别或其他结构？任何输入将不胜感激。
最佳答案
设置代码重用存储库是一项艰巨的任务。主要困难不在于如何设置它，而在于如何传达存储库中各种库的存在。重用库只有在被使用时才是好的，只有在已知时才会被使用，只有在代码质量高且满足用户需求时才会被广泛使用。
我喜欢成熟度级别的想法，但正如其他人发布的那样，可能需要做大量的设置/构建工作。我想到了一种构建应用程序的类似方法——我称它们为置信水平。在应用程序构建领域，低置信度构建是指未通过单元测试的构建；中等置信度可能包括通过单元测试，但不通过集成测试等。这是与 QA 和用户沟通预期内容的良好机制。类似的机制可能适用于图书馆。
文档注释是必须的，并且必须像您在代码中一样小心翼翼地对待它们。评论应该传达什么、为什么、在哪里、何时、如何、哪个等。您的构建过程应该将文档发布到一个众所周知的位置(同样，沟通是关键)。
在沟通方面，时不时地展示一下那里的内容并没有什么坏处。再次!沟通。
因此，至少每个库的构建应该:
- 发布库(可能通知订阅者)
- 发布文档
- 运行单元测试
- 发布成熟度级别
至于成熟度级别，我会用“级别名称”和级别含义的描述来定义它们。发布向上或向下移动一个级别意味着什么的标准。实际上，现在我考虑了一下，也许您想要一组正交标准:代码级别、文档级别、使用策略(即必须具有 XYZ 许可证)和其他属性。 不过，我确实建议您以较小的增量来实现这一点。归根结底，向最终用户交付功能才是最重要的。
您还必须传达一种自然地将可重用位插入存储库的心态。开发人员通常必须有动力这样做。寻找重复和同行评审的静态代码检查工具只能做到这一点。必须有人实际执行将代码移动到存储库的工作。
最后，我建议您在存储库的设置、构建、维护和通信中尽可能多地使用工具支持。否则，就像任何非代码工件一样，您将面临一定量的熵，随着非代码工件变得过时，它会降低值(value)。
关于c# - 如何创建和维护代码重用库？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1302141/