如何创建和维护一个代码重用库？ [英] How do I create and maintain a code reuse library?

问题描述

我想设置的可重用的代码库。我在想是每一个可重用的代码模块具有一定的成熟度的投资评级。该评级将被定义为在该可重复使用的代码在于一组特定的要求范围内的水平。 。最高的成熟度级别将横跨一组预定义的要求，规范程度最高的

I am trying to setup a repository of reusable code. I was thinking about having each reusable code module have a certain "Maturity Level" rating. The rating would be defined as the level at which a reusable code lies within a certain set of requirements. The highest maturity level will be the highest degree of standard across a predefined set of requirements.

例如：结果
级;要求;说明结果
级0;代码是合法使用;是代码合法商业行业使用/跨多个合约的/ etc结果
级1？;基本程序代码，并满足0级的要求;原型代码，第三方工具等结果
2级;具有功能接口和意见，并符合1级的要求;每个类和功能足够的文档;能够从评论结果
3级确定的功能;坚持编码标准，并符合2级的要求;定义如下编码标准并通过代码检查工具的测试结果
级4;包括测试案例和满足3级要求;有足够的测试用例来测试代码的结果
级5的所有功能;通过重用委员会批准，并符合4级的要求;通过重用专家和同行审查和验证符合搜索

For example:
Level; Requirements; Description
Level 0; Code is legal to use; Is the code legal to use in commercial industry/across multiple contracts/etc?
Level 1; Base codeline and meets level 0 requirements; Prototyped code, 3rd party tools, etc
Level 2; Has Function Interface and comments and meets level 1 requirements; Sufficient documentation for each class and function; Able to determine functionality from comments
Level 3; Adheres to coding standards and meets level 2 requirements; Follows defined coding standards and passes code checking utility test
Level 4; Includes test cases and meets level 3 requirements; Has sufficient test cases to test all functionality of code
Level 5; Approved by reuse committee and meets level 4 requirements; Reviewed by reuse experts and peers and verified it meets all levels of maturity

我想，如果这个成熟度水平应该是一个分层结构，其中以移动到你需要满足所有以前的水平的要求（如我如上图所示）一个新的水平？

I’m wondering if this maturity level should be a hierarchical structure, where in order to move to the next level you need to meet the requirements of all previous levels (as I have shown above)?

或者如果它应该是需求的一个子集，以满足一个新的水平？

Or if it should be a subset of requirements to meet the next level?

例如，我们有见面点¯x出Ÿ要求，我们可以移动到一个新的水平（需求将如上述相同）。

For example, we have meet x out of y requirements, we can move to the next level (requirements would be the same as mentioned above).

0级，满足0出6要求结果
等级1，符合1出6要求结果
...

Level 0, meets 0 out of 6 requirements
Level 1, meets 1 out of 6 requirements
…

我的子集的方法中看到的问题是，一些要求，应具有更强的权重，并且在这种方法中，将不被考虑在内（除非我开始获取特定像，满足了的b和X出Y的，等等）。但随后可能会开始变得复杂起来。

The problem I see with the subset approach is some requirements should have a stronger weighting, and in this approach that will not be taken into account (unless I start getting specific like, meets a out of b and x out of y, etc). But then it could start to get complicated.

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

Has anyone done this before, and if so, how did you setup your library? Do you have a maturity level at all or some other structure? Any input would be greatly appreciated.

推荐答案

建立一个代码重用库是一项艰巨的任务。主要的困难是不是在你如何设置它，但您如何沟通信息库中的各种库的存在。重用库仅好，如果它们被使用，如果它们是已知的，他们仅使用，并且它们仅广泛使用，如果代码的质量是高的和它是否符合用户的需求。

Setting up a code reuse repository is a difficult task. The main difficulty is not in how you set it up but in how you communicate the existence of the various libraries in the repository. Reuse libraries only good if they are used, and they are only used if they are known, and they are only used widely if the quality of the code is high and if it meets the needs of the users.

我喜欢成熟度等级的想法，但由于其他人发布，有可能是相当多的安装/建造工作要做。我曾经想过类似的方法来构建应用程序的 - 我打电话给他们信心的水平。在应用程序构建的舞台，一个低信任的构建是一个没有通过单元测试;一个中等可信度可能包括传递单元测试，但不是集成测试，等等。这是给QA和用户期待什么沟通的良好机制。一个类似的机制可能是适当的库。

I like the idea of maturity levels, but as others have posted, there is probably quite a bit of setup/build work to do. I have thought of a similar approach to builds of an application - I called them confidence levels. In the application-build arena, a low confidence build is one that did not pass unit tests; a medium confidence might include passing unit tests, but not integration tests, and so on. This was a good mechanism for communicating to QA and users what to expect. A similar mechanism might be appropriate for libraries.

文档注释是必须的，而且还必须有尽可能多的照顾投入他们为你投入的代码。该意见应传达什么，为什么，在哪里，何时，如何，这等你的构建过程应该在文档发布到一个众所周知的位置（再次，沟通是关键）。

Documentation comments are a must, and must also have as much care put into them as you put into the code. The comments should communicate what, why, where, when, how, which, etc. Your build process should publish the documentation to a well-known location (again, communication is key).

随着通信线路，它不会伤害提出从时间到时间正是在那里。再次！ 。通信

Along the lines of communication, it doesn't hurt to present from time-to-time just what is there. Again! communication.

所以，至少你的每一个库的构建应该：

So, at a minimum your build of each library should:

• 发布库（也许通知用户）


• 发布文档


• 运行单元测试


• 发布成熟度级别

• publish the library (maybe notify subscribers)
• publish the documentation
• run unit tests
• publish the maturity level

至于成熟度，我会用级别名称和什么样的水平意味着描述定义它们。对于发布意味着什么向上或向下移动一个级别的标准。其实，现在我想想，也许你​​想要一个组正交标准：为代码的水平，对于文档，使用的政策水平（即必须有XYZ的许可证），和其他属性。 我不建议你在小的增量，虽然接近这一点。在这一天结束时，提供的功能给最终用户是最重要的。

As to maturity levels, I would define them with a "level name" and a description of what the level means. Publish the criteria for what it means to move up or down a level. Actually, now that I think about it, perhaps you want a set of orthogonal criteria: a level for the code, a level for the documentation, use-policies (i.e. must have a license for XYZ), and other attributes. I do recommend you approach this in small increments though. At the end of the day, delivering functionality to end-users is what matters.

你必须也传达自然推可重复使用的比特到存储库中的心态。开发者必须有激励通常做到这一点。静态代码检查工具，它可以查找重复和同行评审只能走这么远。总要有人真正做到移动代码库的工作。

You have to also communicate a mindset of naturally pushing reusable bits into the repository. Developers have to have incentive to do this usually. Static code checking tools that look for duplication and peer reviews only go so far. Someone has to actually do the work of moving code to the repository.

最后，我建议你在安装使用尽可能多的工具支持成为可能，构建，维护，和仓库的沟通。否则，像任何非代码工件，你将面临一定量的熵这降低作为非码伪影会过时的值。

Finally, I recommend that you use as much tool support as possible in the setup, build, maintenance, and communication of the repository. Otherwise, like any non-code artifact, you will face a certain amount of entropy which lowers the value as the non-code artifact becomes dated.

这篇关于如何创建和维护一个代码重用库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！