Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
An Empirical Study on the Risks of Using Off-the-Shelf Techniques for Processing Mailing List Data
Next
Download to read offline and view in fullscreen.

Share

Cloning Considered Harmful Considered Harmful

Download to read offline

A presentation of Mike Godfrey's work I gave at a reengineering course.

  • Be the first to like this

Cloning Considered Harmful Considered Harmful

  1. 1. Cloning Considered Harmful Considered Harmful? presented by Nicolas Bettenburg 1
  2. 2. 10-15% cloned! 2
  3. 3. Intentional e.g., Copy & Paste { Unintentional } e.g., Language Idioms 3
  4. 4. Cloning = additional maintenance effort B B B B A A A A A 1.1 1.2 1.3 1.4.0 1.4.1 4
  5. 5. Clones considered harmful! 5
  6. 6. But Wait! Is that the right thing to do? 6
  7. 7. Example: Cloning to experiment without risk experimental stable 7
  8. 8. Understand Reason behind duplication before deciding! 8
  9. 9. Catalogue of High-Level Cloning Patterns 9
  10. 10. 8 general cloning patterns Forking Templating Customization 10
  11. 11. Hardware Variations Clone existing driver + No risk of changing existing driver - Code growth ~ Dead code can creep into system 11
  12. 12. Platform Variations Clone existing code and fix low level platform interaction + Avoid complexity of virtualization layer - Hard to propagate bug fixes ~ Ensure consistent behavior of all clones 12
  13. 13. Experimental Variations Clone existing code and experiment + Maintain stable code - Merging later may be difficult ~ Consistent maintenance becomes difficult 13
  14. 14. Boiler-plating Cloning due to language constraints + Make reuse of trusted code possible - Increased maintenance (close evolution) ~ Explicit and rigorous linking of all duplicates 14
  15. 15. API/Library Protocols Clone reoccurring call sequences + Learn from code and reduce effort - Degradation of Code Quality ~ Changes to API require maintenance of all clones 15
  16. 16. Language Idioms a = malloc(64); if (a == null) { out(“Error!”); } ... Idioms provide standardization + Selfdocumenting and improve comprehensibility - Faulty implementations are easily overlooked ~ no long term issues 16
  17. 17. Bug Workarounds ... ... a = sqroot(81); a = sqroot(81); ... if (a != 9) { a = 9; } ... Clone to provide work arounds + Clone buggy code and fix - Source of the bug is not addressed ~ Remove clone when bug is fixed 17
  18. 18. Replicate & Specialize Clone to reuse and adapt existing solutions + Less effort needed - Long-term cost outweighs short-term benefit ~ Cost of refactoring rises over time 18
  19. 19. Conclusions •Templating requires synchronization •Variation requires monitoring of changes •Forking need outlining •Not all clones require refactoring •Some situations warrant the effort •Measure risk vs. long-term cost 19
  20. 20. Considering Cloning harmful in general can be harmful! 20

A presentation of Mike Godfrey's work I gave at a reengineering course.

Views

Total views

1,792

On Slideshare

0

From embeds

0

Number of embeds

30

Actions

Downloads

31

Shares

0

Comments

0

Likes

0

×