tags:

views:

276

answers:

5

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?

+6  A: 

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.

Sklivvz
+2  A: 

Refactor mercilessly and hope for the best.

Gishu
Good names for the refactored stuff. Not where it came from or what it used to do, or where it's currently used, but what it REALLY is.
S.Lott
+1  A: 

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.

Jim Burger
+2  A: 
  • 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.

Thorsten79
+1  A: 

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.

Spodi