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

Posted 2023-02-23

【中文标题】如何创建和维护代码重用库？

【英文标题】：How do I create and maintain a code reuse library?

【发布时间】：2010-11-21 02:08:47

【问题描述】：

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

例如： 等级;要求;说明 0级；代码合法使用；代码在商业行业/跨多个合同/等中使用是否合法？ 1级;基本代码行并满足 0 级要求；原型代码、第 3 方工具等 2级；具有Function Interface和cmets，满足1级要求；每个类和功能都有足够的文档；能够从 cmets 确定功能 3级；遵守编码标准并满足2级要求；遵循定义的编码标准并通过代码检查实用程序测试 4级；包括测试用例并满足 3 级要求；有足够的测试用例来测试代码的所有功能 5级；经重用委员会批准，符合4级要求；由重用专家和同行审查并验证它符合所有成熟度级别

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

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

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

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

我在子集方法中看到的问题是某些要求应该具有更强的权重，并且在这种方法中不会考虑到（除非我开始变得具体像，满足 b 中的 a 和 y 中的 x，等等）。但随后可能会开始变得复杂。

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

【问题讨论】：

我认为当你不得不担心代码重用库的维护时，你就走错了路... :p

@jalf - 那么你显然没有重用库 :) 你编写的所有可重用代码都没有添加错误或需要的功能？

@jalf 这就是为什么他现在将精力和注意力放在设计和结构上，以节省他以后的工作......

我的经验是代码存储库永远不会起作用。如果代码很简单 - 你可以在互联网上找到它或自己编写一些努力。如果它很复杂 - 它不太可能在其他项目中重用

【参考方案1】：

设置代码重用存储库是一项艰巨的任务。主要困难不在于您如何设置它，而在于您如何传达存储库中各种库的存在。重用库只有被使用才好，只有在已知的情况下才会被使用，只有在代码质量高且满足用户需求的情况下才会被广泛使用。

我喜欢成熟度级别的想法，但正如其他人所发布的那样，可能还有相当多的设置/构建工作要做。我已经想到了构建应用程序的类似方法——我将它们称为置信度。在应用程序构建领域，低置信度构建是未通过单元测试的构建；中等信心可能包括通过单元测试，但不包括集成测试，等等。这是与 QA 和用户交流预期的良好机制。类似的机制可能适用于图书馆。

文档 cmets 是必须的，并且必须像您在代码中一样关注它们。 cmets 应该传达什么、为什么、在哪里、何时、如何、哪个等。您的构建过程应该将文档发布到一个众所周知的位置（同样，沟通是关键）。

在交流的过程中，不时展示现有的内容并没有什么坏处。再次！交流。

因此，每个库的构建至少应该：

发布库（可能通知订阅者） 发布文档 运行单元测试 发布成熟度级别

至于成熟度级别，我会用“级别名称”和级别含义的描述来定义它们。发布上移或下移级别的标准。实际上，现在我考虑一下，也许您想要一组正交标准：代码级别、文档级别、使用策略（即必须拥有 XYZ 的许可证）和其他属性。 我确实建议您以较小的增量来处理此问题。归根结底，向最终用户交付功能才是最重要的。

您还必须传达一种自然地将可重用位推入存储库的心态。开发人员通常必须有这样做的动力。寻找重复和同行评审的静态代码检查工具只能到此为止。必须有人实际完成将代码移动到存储库的工作。

最后，我建议您在存储库的设置、构建、维护和通信中使用尽可能多的工具支持。否则，就像任何非代码工件一样，您将面临一定量的熵，这会随着非代码工件过时而降低值。

【讨论】：

+1 表示“你如何传达各种库的存在”以及其他......更糟糕的结果是“剪切和粘贴”文化的盛行，它并没有起到什么作用你想要的，图书馆发布过程是不可理解的，所以我们......这是可怕的事情发生了多少。

对。剪切和粘贴实际上只有一次是合理的，然后如果泛化不是立即显而易见并且您挤满了时间。代码的第三个实例应该是泛化的危险信号。同意 - 剪切和粘贴过于普遍并且可能是有害的：多点维护。

【参考方案2】：

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

我看到在一家大公司工作得很好的一种方法是：

所有第三方库都被提交到一个特殊的目录并且总是包含一个版本号。 我们自己的公共库是根据它们对其他事物的引用来划分的。例如。如果实用程序代码引用了Infragistics 库，那么这段实用程序代码将进入InfragisticsUtils 库。 我们自己的形成清晰可识别“单元”的公共库进入单独的库。例如，处理证券定价的代码库是一个单独的项目。 不满足上述任何条件的所有可重用代码都将进入一个包罗万象的Utilities 项目。 我们自己的库被编译并发布到项目可以引用它们的共享位置。由项目的开发团队决定是要引用已编译的二进制文件还是仅将实用程序项目包含到他们的解决方案中。

显然，您在包罗万象的Utilities 库中找到的代码质量可能会有很大差异。为了缓解这种情况，我们简单地确保来自不同开发团队的两个人审查了所有签入到Utilities。这清除了很多没有地方的东西！

【参考方案3】：

我认为一个出色的代码存储库应该包括一个 CM 工具和一个 Wiki 工具。 CM 工具应该使用水平思想（如您所建议的那样）来构建，因为它按质量构建代码。 wiki 应该充当软件可以做什么以及它如何帮助您的“广告”。该 wiki 还可以保存诸如哪些项目正在使用该代码、对其可用性的评级以及如何使用它的示例等信息。如果有人担心开发团队遵循级别指南，应该指出自我监管的工作原理，并举例说明它与 wiki 的工作情况。

现在，CM 工具的结构很重要。它旨在传达代码的质量，因此您知道在使用它时会遇到什么。例如，如果您编写了一个几乎没有任何 cmets 的简单类，并且它并不真正符合编码标准（可能是原型），那么它将被输入到 \sw_repository\level0\ExamplePrototype。

也许有人会使用那段代码并添加 cmets 并使其达到标准。然后那个人会把它放在 \sw_repository\level1\ExamplePrototype 中。

然后，同一个人，过了一会儿，为 ExamplePrototype 创建单元测试。然后这将转到第 2 级，依此类推。

定义级别需要一些思考。它们确实应该是顺序的，例如，即使您已经为原型代码编写了单元测试，但它不满足 cmets 和编码标准，那么无论如何它都被放置在 level0 中。但是，如果满足这些cmet和标准，就很容易进入level2。

【参考方案4】：

对于我的库，我只是放入了我编写的可跨多个应用程序使用的代码。如果代码特定于特定应用程序，则它不会进入库。随着越来越多的应用程序使用它，错误得到解决，所以我从没想过它会立即消除错误。随着您的库的成熟和不同应用程序的压力，将不断发现并修复错误。它永远不会没有错误，但随着时间的推移会接近可靠性。 另外，当我意识到某些东西的 API 是错误的时，我不会担心它并尽快重构 API。 这是我的 C++ 库http://code.google.com/p/kgui/

【讨论】：

所以除了跨应用程序的基本要求之外，您没有任何关于将哪些代码放入库中的标准？

为了响应 SwDevMan81，我的标准是将可以在其他应用程序中重用的代码放入我的库中。仅仅因为它在库中并不一定会使应用程序更大，因为链接器通常足够聪明，只包含在每个应用程序中实际调用/引用的库位。

【参考方案5】：

多年来，Microsoft 一直大力倡导所谓的 software factories，其中很大一部分致力于解决重用问题。

重用有哪些问题？首先，很难。很难想出一个库和 API 来满足手头项目的直接需求。你如何预测未来？此外，作为知识库和充满活力的实践社区的集中存储库的问题非常具有挑战性。您如何制作既灵活又易于使用的东西？许多人尝试过，但都失败了。 software factories 和software product lines 都试图解决这些问题。

祝你好运！

【参考方案6】：

Kit 提到了最重要的问题：重用。 这个想法的其余部分很好，但它不仅仅是一个细节。

我的意思是，我自己在维护自己的重用库时遇到了麻烦。有时我会做一个非常特定于项目的实现，或者我为某个想法做第 n 个原型，但这些都没有进入我的库。

如果你真的成功地拥有了一个代码重用库，它被许多开发人员以一种有纪律的方式使用和维护，那就是胜利。您需要一个版本控制系统和一个错误跟踪器，后者由项目所有者和用户使用。你需要沟通和贡献的方式。让少数开发人员使用一个项目可以显着提高其质量。实施变得更好。创建文档。 API 和功能设计处于更高的水平。委员会是一件好事，但如果不实际使用它，它无法决定给定的代码有多好。它可以决定代码是否符合特定标准，但对于好的库来说，符合标准是不够的。

你需要尽你最大的努力确保你没有大量的代码 sn-ps 漂浮在周围，所有这些或多或少都可以做一些事情。好的，任何设计决策都有优点和缺点，但我认为，对于给定任务从一个项目开始并分支它（如果确实需要）更有意义，但要保持项目团队之间的活跃沟通，并考虑（部分）合并返回。

不要太担心对不同项目的质量进行分类。如果一个项目不好，那么用户/开发人员会将其推向更好的水平。大多数人都很聪明，可以看出图书馆什么时候好，什么时候不好。你真的需要把精力放在这些共生效应上，而不是试图用严格的规则给参与者带来负担。

只是我的 2 美分 ... ;)

【讨论】：

是的，没有严格的规定。如果担心可能会在图书馆里弄乱一些东西，人们就不会贡献，它的价值就会下降。有了重构、单元测试、源代码控制和覆盖率等足够好的工具——应该（我希望！）减少恐惧。

【参考方案7】：

看看 Will Tracz 的“一个二手程序推销员的自白”，以及惠普的重用拉比 Martin Griss 的作品。

【参考方案8】：

我认为你在一个非问题上想太多了。

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

【讨论】：

我认为这不仅仅是“将其移至图书馆”。第三方软件、分包软件等呢？在一家大公司中，您可能有很多可以使用可重用模块的项目。我们如何管理它们？

【参考方案9】：

拥有自己的图书馆被认为是一种好方法，但是几千行的一个就是废墟！