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

建立代码重用存储库是一项困难的任务。主要的困难不在于你如何设置它,而在于 如何沟通各种图书馆的存在 在存储库中。重用库只有在被使用的情况下才是好的,只有在已知的情况下才被使用,并且只有在代码质量高并且满足用户需求的情况下才被广泛使用。

我喜欢成熟度级别的概念,但正如其他人发布的那样,可能有相当多的安装/构建工作要做。我想到了一种类似于应用程序构建的方法——我称之为置信水平。在应用程序构建领域中,低置信度构建是指没有通过单元测试的构建;中等置信度可能包括通过单元测试,但不包括集成测试等等。这是一个很好的机制,可以向QA和用户传达期望的内容。类似的机制可能适用于库。

文档注释是必须的,而且必须像输入代码一样小心地输入它们。注释应该传达什么、为什么、在哪里、何时、如何、哪个等等。您的构建过程应该将文档发布到一个众所周知的位置(同样,沟通是关键)。

在沟通的过程中,时不时地呈现什么并不伤人。再一次!沟通。

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

• 发布库(可能通知订户)
• 发布文档
• 运行单元测试
• 发布成熟度级别

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

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

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

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

我在一家大公司看到的一种方法是:

• 所有第三方库都被提交到一个特殊目录,并且始终包含一个版本号。
• 我们自己的公共图书馆是根据 参考文献 他们必须做其他事情。例如,如果实用程序代码引用 Infragistics 然后这个实用程序代码进入 InfragisticsUtils 图书馆。
• 我们自己的共同图书馆,形成清晰可识别的“单位”进入单独的图书馆。例如,处理证券定价的代码库是一个单独的项目。
• 所有不满足上述任何条件的可重用代码都将进入一个catch all Utilities 项目。
• 我们自己的库被编译并发布到项目可以引用它们的共享位置。由项目的开发团队决定他们是要引用已编译的二进制文件,还是只将实用程序项目包含到他们的解决方案中。

显然,您在catch all中找到的代码的质量 公用事业 图书馆可以有很大的差异。为了缓解这种情况,我们简单地确保来自不同开发团队的两个人审查了 公用事业 . 这会除掉很多地方都没有的东西!

我认为一个伟大的代码库应该包括一个CM工具和一个wiki工具。CM工具应该使用级别概念(如您所提议的)来构造,因为它按质量构造代码。wiki应该充当一个“广告”,说明软件可以做什么以及它如何帮助你。这个wiki还可以保存信息,比如,哪些项目正在使用代码,对代码的可用性进行评级,以及如何使用代码的示例。如果有人担心开发团队遵循级别指导方针,那么应该指出自我管理是如何工作的,并给出它与wikis的工作效果的例子。

现在,CM工具的结构非常重要。它的设计目的是传达代码的质量,所以当您使用它时,您知道会进入什么样的领域。例如,如果您编写的一个简单类几乎没有任何注释,并且它实际上并不支持编码标准(可能是原型),那么它将被输入到\sw_repository\level0\example prototype中。

也许有人会接受这段代码并添加注释,然后将其提高到标准。然后那个人将它放在\sw_repository\level1\exampleprototype中。

不久之后,同一个人为示例原型创建单元测试。然后将转到第二级,以此类推。

定义层次应该考虑一下。它们确实应该是有点顺序的,即使您已经为原型代码编写了单元测试,但是它不满足注释和编码标准,那么它无论如何都被放在0级。但是,如果这些意见和标准得到满足,就很容易进入2级。

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

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

多年来,微软一直是所谓的 software factories 其中很大一部分致力于解决重用问题。

重用的问题是什么?首先,这很难。很难找到一个库和API来满足手头项目的即时需求。你如何预测未来?此外,作为知识库和充满活力的实践社区的集中存储库的问题也是非常具有挑战性的。你如何制造既非常灵活又易于使用的东西?许多人尝试过却失败了。两者都是 software factories 和 software product lines 尝试解决这些问题。

祝你好运!

提到的工具 最重要的问题:重用 . 其余的想法很好,但不只是一个细节。

我的意思是,我自己很难维护自己的重用库。有时我会做一个非常特定于项目的实现,或者我会为一些想法做第n个原型,而这些都不会进入我的库中。

如果您真的成功地拥有了一个代码重用库,那么它将由许多开发人员以一种规范的方式使用和维护,而不是胜利。您需要一个版本控制系统和一个bug跟踪器,后者被项目所有者和用户使用。你需要沟通和贡献的方式。有几个开发人员使用一个项目可以显著地提高其质量。实现变得更好。创建文档。API和特性设计在更高的层次上。委员会是一件好事,但它不能决定给定代码有多好,而实际上没有使用它。它可以决定代码是否符合特定的标准,但是满足标准对于好的库来说还不够。

你需要尽你最大的努力确保,你没有大量的代码片段漂浮在周围,所有这些都或多或少可以做些什么。好的,任何设计决策都有利弊,但我认为,从一个给定任务的一个项目开始,并在必要时进行分支,但在项目团队之间保持活跃的沟通,并考虑(部分)重新合并更有意义。

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

只是我的2美分…;)

看看WillTracz的《二手程序销售员的忏悔录》,以及惠普的重用拉比马丁·格里斯的作品。

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

你是如何设置我的库的? 很简单,如果在两个或多个项目中使用相同(或几乎相同)的方法,请将其移到库中。

拥有自己的图书馆被认为是一种很好的方法,但是成千上万行的一个是一个废墟!