Reuse Repository

ReuseRepository

Reuse is seldom attained. It will not come by just by doing OO. Just as designing good code takes a lot of thought and effort, so does designing a reuse scheme. The scheme must consider the art and science of interchangeable parts, and the human tendencies of authors and of users.

A '96 article by Roland Racko lists challenges for establishing a corporate reuse program: develop good product which is needed, make it accessible, and make it easy to find and use when its needed.

A truly reusable software component must meet a common need and must be easily integrated. (Of course it must be reliable.) "Mining code" might make salient the company's recurring needs, but the code itself will not be truly reusable. A reusable component must be deliberately designed as such and with two goals: broad/common application and convenient interchangeability.

Developing software which has broad and common application takes experience: the language and its idioms, patterns and techniques, and knowledge of the corporate need. It also requires that element of artist which can be elusive to many technical people.

Interchangeable software again requires the skill and art of the developer to pull it off. It also requires corporate-wide standards (naming and techniques) as well as the enforcement of these standards so that code can be truly reusable.

I (RandyCarey) have founded a reuse repository at my company. (Just like most web pages...) It's still being evaluated and improved, but I would like to outline my scheme for maintaining this repository.

Anybody can contribute to the repository, but you can't just submit code. An author must also submit support documentation: a profile similar to GOF's pattern descriptions, an example of the code integrated, an example of a derived class (if applicable), and any other helpful data (such as code used to conduct a unit test). These requirements weed out code that's not well thought out. They also force the author to think through how and why someone would reuse this code.

In order to make reusable parts accessible, the code is kept in a hierarchy of directories on a network. The support documents and header are maintained in an html format. When I want to browse for some desired part to reuse, I start my Netscape browser on the Reuse homepage and hyper-jump down the hierarchy. Once I arrive at a component which catches my interest, I can view the itemized support documents and the header. If I want to use the component, I download the code to the desired directory.

To help guide the less experienced, certain pages in the hierarchy provide links to decision or background pages. For example, our database page offers a link to a page listing the purposes and trade-off's of various storage options: data maintained in RAM vs. in a file, random access vs. lists vs. search trees. While the experienced developer should know which to use, these tips are optional guides for those uncertain when faced with so many choices.

The project is still young, but reuse has occurred many times now that components are easy to find, they interface fairly easily, and support documentation accompanies. Because not just any code goes into the repository, a contributor has pride in having his component included.

To have a truly functional repository of reusable code, (I feel) a company needs [1] to commit to the effort and [2] to centralize this effort through one person (or a small group). This central person should [3] be bestowed with authority and [4] possess the required skill, knowledge, and art to oversee the building and distribution of truly reusable software.

The type of small group that RandyCarey talks about above is succinctly defined in SucceedingWithObjects.

WillTracz is big on using hypertext to navigate reuse libraries, you may want to check out his book ConfessionsOfaUsedProgramSalesman.

Good Luck Randy, it will be hard fun... I too have taken on the role of starting and running a reuse repository.

-- ToddCoram

Would you call this central co-ordinator, a CodeLibrarian?? :) In my experience, organizations with groups that manage/maintain reuseable (source) code don't limit themselves to libraries -- i.e., they will also manage reusable tools.

-- AnthonPang

For another take, see ExtremeReuseRepository