arborint wrote:Also, can you elaborate on "reuse is not free and not linear when it comes to modification." I can see that reuse is not free because it will force design decisions. But what does "not linear when it comes to modification" mean?
Basically, small changes to the code cost a lot. [Found a reference to the non-linear graph:
http://citeseer.ist.psu.edu/cachedpage/258439/13 ] The two major costs are understanding the code in order to modify it and testing it to make sure you didn't break it.
arborint wrote:Are there things a programmer can do when designing/coding a class/module could increase that threshold of 20% to something higher? I wonder what all the Refactoring guys would say about this? Or conversely, might it be better to lower the percentage to 5%-10% which might make the code more brittle with regards to large changes (since you have to rewrite anyway), but easier to fix for common cases because it is cleaner/clearer?
arborint wrote:In that 20%, can you make it work harder for you so you get more out of it? I know Lastcraft sometimes talks about choosing when and when not to build in "flex points" which I always took to mean a part of the code that is purposely built to allow for more changablity.
For me, the trick is to design for reuse. I use the word "design" because it really should be planned. Reuse requires more thought and effort, there's an initial investment to be made in time and resources.
I pointed out the
types of reuse before but might be a good link to post again:
http://www.ambysoft.com/essays/typesOfReuse.html
We talk a lot about code reuse but different types of reuse can be used together and to some extent can even complement each other.
The Secrets to Reuse Success
So how do you actually achieve object-oriented reuse? I wish I could say that all you need to do is go out and buy a few tools and a repository to store your reusable work to get a good start. Unfortunately, reuse is about far more than tools. In fact, many organizations have failed miserably because of their focus on tools and not on process. Here are some reuse tips:
*
You can't call something reusable unless it's been reused at least three times on three separate projects by three separate teams. You can attempt to design for reuse, but you can't claim success until some element of the application has been reused at least three times. Reusability is in the eye of the beholder, not in the eye of the creator.
*
Reusable items must be well-documented and have one or more real-world examples of how to use them. In addition, the documentation should indicate when and when not to reuse an item so developers can understand the context in which it is to be used.
*
The only way you'll make reuse a reality is if you plan for it. You must allocate the time and resources necessary to make your work reusable. If you don't step back and take the time to generalize your work, then it will never happen-project pressures will motivate you to put that work aside until you have the time to do it. The bottom line is that if reuse management-the act of specifically reusing existing items and constantly adding to the store of reusable items-isn't part of your development process, then reuse won't happen.
*
Reuse is an attitude. When you begin a project, the first thing you should do is determine what portions of your application can be reused from somewhere else. Perhaps someone else has built what you need, or perhaps you can purchase components or other reusable items. The other side of the coin is that you must be willing to share your work with other people so they can reuse it. A good team lead will constantly be on the lookout for opportunities for reuse and will promote and reward reuse within his or her team. An excellent approach is to look for reuse during inspections: during model walkthroughs, look for opportunities for inheritance and pattern reuse; during code walkthroughs, look for component and code reuse.
-
http://www.ddj.com/dept/architect/184415594
[The original study I referred to was, Richard W. Selby, Empirically Analyzing Software Reuse in a Production Environment, in Will Tracz, editor, Software Reuse: Emerging Technology, IEEE Computer Society Press, 1988. Kind of old but still in good standing AFAIK. Can't find a free link though.]