How do I create and maintain a code reuse library?

Question

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 a

Answer 1

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.

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

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.