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

我正在尝试设置一个可重用代码的存储库。我在考虑让每个可重用代码模块都有一个特定的“成熟度级别”。评级将被定义为可重用代码位于特定需求集合中的级别。最高成熟度级别将是一组预定义需求的最高标准

例如：
水平；要求；说明
0级；代码使用合法；在商业行业/跨多个合同/等中使用该代码是否合法？
一级；基本代码线，满足0级要求；原型代码、第三方工具等
二级；具有功能接口和意见，满足一级要求；每个类别和功能的足够文件；能够从评论中确定功能性
三级；遵守编码标准并满足2级要求；遵循定义的编码标准并通过代码检查实用程序测试
四级；包括测试用例并满足3级要求；有足够的测试用例来测试代码的所有功能
五级；经复用委员会批准，满足4级要求；由重用专家和同行审查，并验证其符合所有成熟度级别

我想知道这个成熟度级别是否应该是一个层次结构，为了进入下一个级别，您需要满足之前所有级别的要求（如我上面所示）

或者它是否应该是满足下一个层次的需求的子集

例如，我们满足了y中的x需求，我们可以进入下一个级别（需求与上面提到的相同）

0级，满足6项要求中的0项要求
1级，满足6项要求中的1项要求

我看到的子集方法的问题是，一些需求应该有一个更强的权重，在这种方法中，这将不会被考虑（除非我开始变得具体，比如，满足b中的a和y中的x等）。但接下来事情可能会变得复杂起来

---

以前有人这样做过吗？如果有，您是如何设置库的？您是否有一个成熟度级别或其他结构？如果您有任何意见，我们将不胜感激。

我认为您在一个没有问题的问题上想得太多了

---

您是如何设置我的库的？很简单，如果您在两个或多个项目中使用相同（或几乎相同）的方法，请将其移动到库中。

对于我的库，我只输入了我编写的可跨多个应用程序使用的代码。如果代码是特定于特定应用程序的，那么它不会进入库。随着越来越多的应用程序使用它，bug会被解决，所以我从来没有期望它马上就没有bug。随着库的成熟和不同应用程序的压力，bug将不断被发现和修复。它永远不会没有bug，但随着时间的推移，它将接近可靠性。 此外，当我意识到某些东西的API是错误的，我不担心它，并尽快重构API

这是我的c++库

---

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

我在一家大公司看到的一种行之有效的方法是：

• 所有第三方库都提交到一个特殊目录，并且始终包含一个版本号
• 我们自己的公共库根据它们对其他事物的引用进行划分。例如，如果实用程序代码引用

  基础设施

  库，则此位实用程序代码将进入

  基础设施库

• 我们自己的公共库形成了清晰可识别的“单元”，它们被放入不同的库中。例如，处理证券定价的代码库是一个单独的项目
• 所有不满足上述任何条件的可重用代码都会进入一个“一网打尽”的

  Utilities

  项目
• 我们自己的库被编译并发布到一个共享位置，在那里项目可以引用它们。由项目的开发团队决定是要引用已编译的二进制文件，还是只将实用程序项目包含到解决方案中

---

显然，您在catch all

Utilities

库中找到的代码的质量可能会有很大差异。为了缓解这种情况，我们只需确保来自不同开发团队的两个人检查了

实用程序的所有签入。这就清除了很多没有位置的东西
 拥有自己的图书馆被认为是一个不错的方法，但一个数千行的图书馆就是一个废墟
 看看Will Tracz的《二手程序推销员的自白》，以及HP的重用拉比Martin Griss的作品。
建立代码重用存储库是一项艰巨的任务。主要的困难不在于如何设置它，而在于如何传达存储库中各种库的存在。重用库只有在使用时才有用，只有在已知的情况下才会使用，只有在代码质量高且满足用户需求的情况下才会广泛使用

我喜欢成熟度级别的概念，但正如其他人所发布的，可能有相当多的设置/构建工作要做。我已经想到了一种类似的方法来构建应用程序——我称之为信心级别。在应用程序构建领域，低置信度构建是指没有通过单元测试的构建；中等置信度可能包括通过单元测试，但不通过集成测试，等等。这是一个很好的与QA和用户沟通的机制