Lecture
Elements of reuse
Any software product (program text, architecture, a scenario, or documentation) can be reused. As was said in Chapter 3, in object-oriented programming languages the primary linguistic vehicle of reuse is the class: a class may give rise to subclasses that specialize or extend it. Further, Chapter 4 discussed the reuse of patterns of classes, objects and design elements in the form of idioms, mechanisms and frameworks. The reuse of patterns is at a higher level of abstraction than the use of individual classes and yields a greater payoff (although it is harder to achieve).
One should not trust figures that characterize reuse . In the successful projects we have encountered, the amount of reused elements has reached as much as 70% (that is, almost three quarters of the system's software was taken unchanged from some other source), but it has also been zero. One should not think that reuse must reach some obligatory figure; the opportunity for reuse depends heavily on the problem domain and on nontechnical factors such as, for example, the degree of schedule pressure, the nature of relations with subcontractors, and security considerations.
Certainly, any percentage of reuse is better than none, since it saves resources that would otherwise have to be spent all over again.
How is reuse achieved?
Reuse within a project, or even within an entire organization, must not be left to chance. Opportunities have to be sought out deliberately and successes have to be rewarded. That is precisely why we included the search for recurring patterns in the macro process.
It is best to make reuse someone's personal responsibility. As was described in the previous chapter, one must look for possible commonalities, usually revealed while reviewing the architecture, realize them by creating new components or adapting old ones, and then champion them before the other developers. Even simple forms of encouragement, such as giving equal recognition to the author of the original code and to the person who discovered the opportunity to borrow it, have a stimulating effect. One can devise something more substantial - dinner at a restaurant or a weekend trip for two - and award these prizes to the developers whose solutions were borrowed most often, or to those who borrowed the largest amount of code in a given period of time [People close to the developers often suffer a certain amount of moral damage in the final rush of development, and such compensation will be very welcome to them].
Reuse may not bring short-term benefits, but it pays off in the long run. It makes sense to pursue it in an organization that has extensive, far-reaching software development plans and looks beyond the interests of the current project.
Comments