What techniques do you use to maximise code reuse?

Question

Some years ago I was told about a study into code reuse. Apparently it was found that, on average, programmers have a 7 minute window when searching for code to reuse. If they don't find code that suits their needs within that window they'll write their own.

This was presented in the context of needing to carefully manage your code for reuse to ensure that you can find what you need within the window.

How do you (individuals and organisations) manage your source to make it easier to reuse? Do you specifically maintain a reuse library? And if so, how do you index it to maximise your hit rate?

Answer 1

A complex question:

• Some parts of the code can be generalized as libraries or APIs. We have a common library which is kept up to date with solutions to common problems. Typically: validation, caching, data access classes, logging, etc...

• Some parts are application specific. They cannot be generalized easily. We convert them in HowTos and give internal presentations. Code is also recycled by use of an easily browsable SCM (in our case SVN).

• We also have tools that generate code that one one hand cannot be recycled, on the other it's always similar (think calling a stored procedure).

• Pair programming is also a useful way to spread knowledge of existing solutions. We use that when possible or appropriate.

• The last technique is tuition. Each coder has a tutor to refer to. Since the tutors are few, there is a lot of sharing between them and this knowledge can be diffused in a top down manner.

Answer 2

Refactor mercilessly and hope for the best.

Update (4 years later and hopefully wiser)

• Like S.Lott's comment says: Pay attention to Naming. Spread the word to all 'committers' in the team. Good names make things searchable and thereby reduces duplication.
• Have ONE way of doing something and keep it ACCESSIBLE and SEARCHABLE.
• Write code for the average (L.C.D.) programmer.. Don't be clever where simple would suffice. (That includes design-pattern shoe-horning compulsion and related disorders)
• Adopt a common set of conventions, styles, guidelines, standards, et.all early. Ensure buy-in and thereby compliance within the team. (This means everyone uses the tabs (or spaces)!). It doesn't matter what you choose - the goal is that the code should look consistent
• Have a gatekeeper (respected by the team), who eyeballs all check-ins for red-flags.
• Write code test-first / outside-in. This usually ensures that your code is usable by multiple clients. (See GOOS's bullet on context-independence)

Answer 3

• Have a framework that is actively supported.

• Know the existing code base / make the other developers know the code base. If your group/company is large enough, have somebody who knows the code base and can be asked for guidance.

• Document, document, document. Undocumented code is useless for re-use because it takes way too long to understand its inner workings.

• Have good interfaces. Easy types, easy structures or classes. The more complicated something is, the less it will be used in another project.

• Optimize and debug reusable code. Developers who experience bugs in other people's code for the n-th time will begin to code already existing code anew.

Answer 4

Try using TDD if your aren't already is my initial repsonse.

I think the use of TDD is a great way to keep code coupling low, amongst other benefits. While that inherently doesnt prevent the same behaviour from being implemented twice, it makes it a great deal easier when you DO identify an area in which you could remove duplication.

Another benefit, TDD has a step for removing dupication (refactoring) as part of the cycle.

Also, tests form part of your codes documentation, thus making it easier to identify duplicated behaviour.

Answer 5

Organization is key. If namespaces and intellisense is available, the right function can be narrowed down on, and eventually found. If they don't find what they want exactly, they may find something close or related. Code that is just mashed together in one huge group makes it easy to find, but people are never going to find the method they want fast enough.

Consistency is also critical, both with naming and location. If you decide to change your style at some point during the project, go back and change everything to fit that style. It can easily be a very long and boring process, but it is better than trying to have to use an inconsistent library.

Answer 6

Profile the whole application and start refactoring from the heavier section of code. (80% of time spent on 20% of most used code)

Use a profiling tool which has capability to identify memory leaks, repeated calls, lengthy calls, unfreed memory, undisposed resources etc,.

By rule, New code always uses best practice.

Answer 7

How do you (individuals and organisations) manage your source to make it easier to reuse? Do you specifically maintain a reuse library? And if so, how do you index it to maximise your hit rate?

I don't and I have an admittedly controversial opinion here but I find the idea of maximizing code reuse counter-productive (I'm interpreting "maximizing" as prioritizing it above all other things rather than considering it as having both pros and cons to balance in consideration). I prefer instead to allow a healthy amount of redundant efforts in teams to slide in favor of decoupling and isolating each developer's module better. First before everyone starts disagreeing with me left and right, I think we can agree upon some things:

1. Reusing buggy code that will have you spending hours debugging other people's code is not desirable.
2. Reusing code that balances such a wide range of disparate needs that it barely satisfies your own needs and requires you to jump through a lot of hoops to ultimately get an awkward and inefficient solution is undesirable.
3. Reusing code that constantly requires design changes and goes through deprecations of a kind which will require you to rewrite the code using it every 6 months is undesirable if you could have just implemented the solution yourself in half an hour in ways that don't need design changes in the future since it's only serving your precise needs.
4. A codebase filled with alien-looking code is undesirable over one that uses more of the language and standard library in idiomatic and familiar ways, even if that requires slightly more code.
5. Developers stepping all over each other's toes because both of them want to make incompatible changes to the same design while fighting and arguing and making changes which cause bugs in each other's implementations is undesirable.
6. Throwing a boatload of dependencies to immature designs that have not proven themselves (not had thorough test coverage, not had the time to really soundproof the design and make sure it effectively satisfies user-end needs without requiring further design changes) is undesirable.
7. Having to include/import/link a boatload of libraries and classes/functions with the most complex build script to write something simple is undesirable.
8. Most of all, reusing code in a way that costs far more time both in the short and long run than not reusing it is undesirable.

Hopefully we can at least agree on these points. The problem I've found with maximizing code reuse from overly-enthusiastic colleagues was that it often lead to one or more of the problems above. It wasn't directly the enthusiasm for code reuse that was the fundamental problem but that the priorities were skewed towards code reuse rather than test coverage, soundproofing designs, making sure things are mature enough before we reuse them like crazy, and so forth.

Naturally if all the code we reused worked beautifully, had thorough test coverage, was proven to fulfill the needs of everything using it in ways that were far more productive than not reusing it, and didn't have to go through any design changes for years on end, I would be ecstatic about code reuse. But my experiences often found things falling far short of this ideal in ways where code reuse was arguably becoming the maintenance problem rather than the solution.

How do you (individuals and organisations) manage your source to make it easier to reuse? Do you specifically maintain a reuse library? And if so, how do you index it to maximise your hit rate?

So, again I don't seek to "maximize" code reuse among proprietary code written internally among the team. I seek to make sure the team doesn't spend enormous amount of time on redundant effort, but I let things slide quite a bit if both the physicists and the rendering guys both implement their own axis-aligned bounding box class, e.g. It's not necessarily even that redundant, since the physicist might use min/max representations which are more efficient for his purpose while the rendering developer might use center/half-size representations. I do try to make sure we reuse as much of the standard library when possible, because that's code reuse of a kind that is practically guaranteed to be solid, ultra well-tested, and not require further design changes (other teams are spending a boatload of their time to make sure of that).

Instead I shift the focus on testing. A module duplicating a little bit of code here and there is totally fine if you ask me if it's working beautifully in ways that make users really happy, has thorough test coverage, and doesn't warrant endless changes. We accept such duplication all the time when we use third party libraries who likely duplicate some code that we also have in our internal codebase. It's not an issue there when the redundancy doesn't lead to redundant maintenance efforts.

So I suggest just relaxing the idea of maximizing code reuse just a little bit. But if you want to make it easy as possible to reuse the really solid, well-tested, non-trivial code, then I've found it far more helpful to organize very singular-purpose libraries, like a "math" library, an "image" processing library, etc. -- instead of trying to fuse them all together into something like "core" or "common". The latter types tend to tempt developers to throw in all kinds of eclectic utility functions which barely benefit the team using them, and mostly it tends to become messy in ways where it starts to become difficult to find anything of interest.