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

Look at Will Tracz's "Confessions of a Used Program Salesman", and stuff by HP's reuse Rabbi, Martin Griss.

Answer 2

For years Microsoft has been a big advocate for what is known as software factories, a big part of which is devoted to solving the problems of reuse.

What are the problems of reuse? First of all, it's hard. It's very hard to come up with a library and API that will serve beyond the immediate needs of the project at hand. How do you predict the future? Also, the problem of a centralized repository that serves as both a knowledge base and a vibrant community of practice is very challenging. How do you make something that is both very flexible yet easy to use? Many have tried and failed. Both software factories and software product lines attempt to address these problems.

Good luck!

Answer 3

I think you will find it difficult to ensure that the entire development team follows these guidelines accurately enough. Especially when the guidelines may be interpreted one way or another. Moreover, it will be a major pain if somebody improves a piece of code by adding tests and suddenly it has to move to a different project. More likely than not, such code will stay in the project it was originally placed into, and over time the maturity levels will become meaningless.

One approach I saw working fine in a large company is this:

• All third party libraries are committed to a special directory and always include a version number.
• Our own common libraries are divided based on the references they have to other things. E.g. if the utility code references the Infragistics library then this bit of utility code goes into an InfragisticsUtils library.
• Our own common libraries that form clearly identifiable "units" go into separate libraries. For example, a library of code that deals with pricing securities is a separate project.
• All reusable code that doesn't satisfy any of the above goes into a catch-all Utilities project.
• Our own libraries are compiled and released to a shared location where projects can reference them. It is up to the projects' development team to decide whether they want to reference a compiled binary or just include the utility project into their solution.

Obviously the quality of the code you find in the catch-all Utilities library can vary significantly. To alleviate this we simply ensured that two people from different development teams reviewed all checkins to Utilities. This weeds out a lot of stuff that has no place there!

Answer 4

I think a great code repository would include a CM tool and a Wiki tool. The CM tool should be structured using the level idea (as you proposed), since it structures the code by quality. The wiki should act as an "advertisement" of what the software can do and how it can help you out. This wiki could also keep information like, which projects are using the code, rating of how usable it is, and examples of how to use it. If anyone is worried about the development team following the level guidelines, it should be pointed out how self policing works and give the example of how well it works with wikis.

Now, the structuring of the CM tool is important. It is designed to convey the quality of the code, so you know what you get into when you use it. For example, if you write a simple class with barely any comments and it doesn't really uphold to coding standards (maybe a prototype) then it would be entered into \sw_repository\level0\ExamplePrototype.

Maybe someone then takes that piece of code and added comments and brings it up to standards. Then that person would place it in \sw_repository\level1\ExamplePrototype.

Then that same person, a while later, creates unit tests for the ExamplePrototype. This would then go to level2 and so on.

Defining the levels should take some thought. They really should be somewhat sequential and even if for example, you had written unit tests for the prototype code but it didn't satisfy the comments and coding standard then it is placed in level0 anyway. However, it would be easy to go to level2 if those comments and standards were satisfied.

Answer 5

Kit mentioned the most important problem: the reuse. the rest of the idea is nice, but it's not more than a detail.

i mean, i myself have trouble maintaining my very own reuse library. sometimes i do an implementation that is very project-specific, or i do the n-th prototype for some idea, and none of those ever gets into my library.

if you really succeed in having a code reuse library, that is used and maintained by many developers, in a disciplined way, than that's victory. you need a version control system and a bug tracker, the latter being used by both project owners and users. you need communication and means of contribution. having a handful of devs using a project dramatically improves its quality. implementation gets better. documentation is created. API and feature design are on a much higher level. a committee is a nice thing, but it cannot decide, how good given code is, without actually using it. it can decide whether the code meets specific standards, but meeting standards is not sufficient for good libraries.

you need to do your best to make sure, you don't have tons of code snippets floating around, all of which can more or less do something. ok, any design decision has pros and cons, but i think, it makes more sense to start with ONE project for a given task, and branch it, if really necessary, but keep alive communication between project teams, and consider (partially) merging back.

don't worry too much about categorizing the quality of different projects. if a project is bad, then users/devs will push it to a better level. most people are clever enough to see, when a library is good, and when it isn't. you really need to put your energy in these symbiotic effects, rather than trying to burden participants with strict rules.

just my 2 cents ... ;)

Answer 6

I think you are thinking too much in a non problem.

How did you setup my library? Easy, if you use the same (or almost the same) method in two or more projects, move it to the library.