11

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

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

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

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

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

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

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

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

4

9 回答 9

9

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

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

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

沿着沟通的路线，不时地展示那里的东西并没有什么坏处。再次！沟通。

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

  • 发布图书馆（也许通知订阅者）
  • 发布文档
  • 运行单元测试
  • 公布成熟度等级

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

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

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

于 2009-09-01T23:54:31.517 回答
5

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

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

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

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

于 2009-08-20T19:17:03.717 回答
3

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

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

也许有人随后会使用那段代码并添加注释并将其提升到标准。然后那个人会将它放在 \sw_repository\level1\ExamplePrototype 中。

然后，同一个人，过了一会儿，为 ExamplePrototype 创建单元测试。然后这将进入 level2，依此类推。

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

于 2009-09-03T14:50:43.723 回答
2

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

这是我的 C++ 库
http://code.google.com/p/kgui/

于 2009-08-19T19:41:43.257 回答
2

多年来，微软一直大力倡导所谓的软件工厂，其中很大一部分致力于解决重用问题。

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

祝你好运！

于 2009-09-03T03:38:19.213 回答
2

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

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

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

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

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

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

于 2009-09-03T15:40:41.660 回答
1

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

于 2009-09-01T23:21:33.517 回答
0

我认为您在非问题上想得太多。

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

于 2009-08-19T19:40:21.963 回答
-1

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

于 2009-08-21T02:02:07.010 回答