On PolyBloodyHardReuse, AlistairCockburn has identified some common problems in managing reuse across projects. But PeterMerel doesn't think they're all that hard. In fact, he thinks they're easy:
-
Configuration Management - How and when, if ever, do you migrate changes in the reused class among the various applications using it?
-
You don't. You use TestInjection to migrate behaviour from the projects into the core code. You do this iteratively and the projects are responsible for refactoring to accommodate each new core release.
- This is a major issue where I work, on the specific project I work on. Not the test injection stuff, but rather configuration management. However, work is underway to improve this aspect.
-
Class Extension - What do you do when the reused class needs a new capability? You can extend the class (easy). The other option is to inherit the class, but without the correct virtual declarations and without exposing encapsulated data (C++ specific references), it is often impossible to add the desired functionality without still having to go back and modify the base class.
-
If you've used AlternateHardAndSoftLayers, all your encapsulation has happened in the soft language - typically one of the DynamicLanguages or a WebService layer. It's trivial for projects to extend class behaviours here without altering the core code.
-
Close, But No Cigar - Related to the above, what do you do when the class you want to reuse almost does what you want? If you are doing white box (source code) reuse, no problem. If you are doing black box (binary) reuse, you may find yourself most of the way through a development cycle and realize you have to recreate the class from scratch or burn lots of effort in reverse engineering the class and coding work arounds.
-
ClassExtension in a soft language covers these issues for the project and TestInjection ensures that the variant behaviour finds its way back into the core. No problem.
-
Not-for-long Reuse - Hardware capabilities change. Protocols change. *Egads*: requirements change. Reused code might not weather this change as nimbly as code that you have complete control over. Does BitRot apply to reused code? At least one Wikizen thinks so.
-
The responsibility of the core developers is to iteratively consume all relevant FunctionalTests in all reusing projects. Relevance is prioritized by a PlanningGame using the project PMs as customers to the core developers.
-
Premature Publishing - Change rates for a given module tend to be wildly troublesome at first. If you try to reuse code across projects at the beginning of its life, you'll likely experience PolyVeryExtremelyBloodyHardOwieOwieDoctorItHurtsWhenIDoThisReuse.
-
Then don't do that. With TestInjection the core code either satisfies the designated tests or it doesn't. Since the injected tests are already sufficient for regression on the projects, they're sufficient to drive quality into the core code up front. Again, no problem.
-
Nominal Reuse - Here's a class that everyone can use. It achieves its poly bloody universal reuse ability from the fact that it doesn't do anything interesting. But y'all can use it, and we're about to write a departmental policy that says you have to.
-
YagNi - the core developers never produce any class that doesn't meet needs prioritize by their customers, the project PMs.
Sorry Alistair, I think you're making a mountain out of several molehills with one slightly larger molehill in the middle. -- Pete
See also: GenericBusinessFrameworkUnobtainable