How do you ensure code is reused correctly? [closed]

Question

Frequently when we introduce a new feature into an application we may produce artifacts, such as useful methods or classes that could be reused in other areas of our applications. These artifacts are not necessarily documented as functional requirements as they are usually a side-effect of our implementation choices. Since we often develop in teams, it is important to share these pieces of code to prevent rework and duplication.

Examples:

• Utility methods and classes
• A Base class
• An Interface
• A GUI control

What have you found to be the most effective way of sharing these artifacts?

How do you convey the assumptions you made when you created them?

How do you ensure they are consumed correctly?

I am interested in best practices and proven techniques around documentation, code diagrams, meetings(?) to ensure code is reused correctly.

This question is very similar to: Finding Reusable code but I'm interested in a more proactive than reactive approach.

Answer 1

Our team has a number of helpful libraries that we use throughout our development. These libraries are kept in a common repository in sort of an "open-source" methodology. There is one person who oversees each library (or multiple libraries) and developers can submit patches.

The libraries are then released/built to a common location (we deploy to a web server) where people can then download them and use them in whatever project they would like. So far, it has worked pretty well. The only thing we have to watch out for is, if there is an API change, we must make sure we make sure everybody realizes this. We do this through version numbers and through information on our library wiki.

Edit: In addition, we publish the generated docs for our libraries (Javadoc, Crystal Report, whatever) so that developers can utilize those.

Answer 2

We're a .Net team, so this worked for us...

We created our own class library for functions that we think will be commonly used. Things like calculating a Luhn Mod 3 check digit, creating a regex to validate a an address that will fit into a database field that is n characters, etc. The trick is being able to recognize code that is likely to be reused and get it in there. And keep it organized.

Answer 3

Speaking from complete lack of experience in the matter, the ideal situation is probably to create a shared version control system between the teams. Then after a few initial organizational/awareness meetings, treat the shared depot as an opensource project that people can contribute to. So, looking at a couple of cases:

1. You write some code to be shared: this requires creating a new area in the depot for the code, adding some basic documentation, tests, code clean up, etc...but there's incentive to do it right if it's considered "public".

2. You want to use code and it's good quality: Sounds like a good library, but there's a few limitations. You add more documentation, tests, and extra functions, and so on.

3. You want to use code, but it's rubbish: You need to chat with the original developers. Then do a major rework of the code, but it's still slightly better than reinventing the wheel. Both teams benefit when you're done.

The trick is making it all public knowledge. So you need champions on each team to push people to reuse and contribute. That's what you get from the initial round of meetings. Assuming the opensource model is a proven practice, there's no reason it can't work if you have champions.