How do you ensure code is reused correctly?

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: http://stackoverflow.com/questions/869364/finding-reusable-code but I'm interested in a more proactive than reactive approach.

Answer 1

Test your preconditions with asserts.

Besides that, think of some unit tests to check that your code is robust enough to deal with uncommon or unintended situations.

For the rest, make sure that everyone actually understand what the code does, at least on a black-box level. Have a short meeting with a whiteboard and do a little pair programming once people have to start out using code that's new to them.

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

We are a Java development team and the same applies to us. We created utility projects in our SVN under various headings e.g. XML parsing, Vector processing and the reusable code is checked into these utility libraries and reused in other projects.

Answer 4

Check out a book on best practices in your programming language. Apply them and see what works and adapt accordingly. Basically a good, clean and concise interface/api goes a long way. Also write lots of unit tests to cover different kind of functionality. Also take a look at built in libraries in your language/platform or look for good examples of libraries and see how their interfaces are.

Answer 5

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.

Answer 6

Use SOLID and keep your code clean. Check: http://www.lostechies.com/content/pablo%5Febook.aspx

If you see something that's likely to be implemented, ask to the team. Always keep in mind your knowledge of previous projects, if you know project x has that feature then start from there ;)

Reuse is important and avoiding duplication too, specially when you are in the Same product / maybe even subsystem. Its important to always look for it, but don't let that get in the way of progress in the projects.

Answer 7

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.