Sustainable Refactoring: Techniques for Detecting and Preventing Code Clones Mercilessly
•
6 likes•506 views
Code clones (duplicates) is one of the most painful enemies of clean code. Teams transitioning to Agile find it very hectic to chase code clones and fix scattered chunks of unstructured business logic.
Recommended
More Related Content
Similar to Sustainable Refactoring: Techniques for Detecting and Preventing Code Clones Mercilessly
Similar to Sustainable Refactoring: Techniques for Detecting and Preventing Code Clones Mercilessly (20)
Recently uploaded
Recently uploaded (20)
Sustainable Refactoring: Techniques for Detecting and Preventing Code Clones Mercilessly
- 1. Sustainable Refactoring: Techniques for Detecting and Preventing Code Clones Mercilessly Amr Noaman Abdel-Hamid Agile Academy
- 2. About Amr • Agile practitioner, coach, trainer, & consultant • Co-Founder of Agile Academy • SCEA, CSP, 6σ black-belt for IT • Co-Author of the ‘Process Increments’ method, for software process improvement • Initiator of Egypt’s GoAgile program at 2011, a Government initiative to boost lean & agile software development in Egypt • Agile Egypt meetup organizer, the largest agile community in the Middle East
- 4. 4
- 5. What’s Evil about Dead Code? Out of the $100 Billion spent on software in the 90’s, $70 Billion are spent on Maintenance 5 Cost of New Development 30% Cost of Maintenance 70% Reference: Dennis D. Smith, Designing Maintainable Software, Springer, 1999.
- 6. Cost of locating bugs 6 60% 40% Everything else! Fixing Testing Reviews Integration Integration & system testing Deployment User Acceptance . . . . Cost of Maintenance
- 7. What’s Evil About Dead Code? • Creates noise when locating bugs • Extremely easy to pinpoint and remove: – 4-7% of the code is dead – Removing dead code removed 10% of duplicate code as well! – Removing dead code takes 1-3 days Reference: http://www.agilealliance.org/files/2113/8134/26 17/5076a129.pdf 7
- 8. Removing Dead Code Also Removes 10% of Duplicate Code!
- 9. Types of Code Clones • Exact – Duplicated chunks of code • Similar – No added/changed/deleted lines of code – Renames exists • Gapped – Exact or Similar Clones – One or two lines of code are added/changed/deleted
- 10. Exact Clones!
- 11. Similar Clones
- 13. Dormant Bugs • 30% of detected bugs are dormant* • You don’t know when they will hit, and what are the side effects Ref: An Empirical Study of Dormant Bugs Queen’s University, Canada, Rochester Institute of Technology, USA
- 14. Code Clones Hard Numbers Overall, 20% effort increase in maintenance due to code clones 14 Reference: https://www.cqse.eu/publications/2009-do-code-clones-matter.pdf System Code 40% Code clones 52% Inconsistent clones 18% faults in system
- 15. Removes 18 production Dormant bugs Removing 100 gapped (inconsistent) clones
- 16. 16 This Stuff is Risky Isn’t It?
- 17. No, It’s Not! 17 Metric Release 5.5 (Before refactoring) Release 5.6 (During Refactoring) Total bugs detected 128 176 % of Regression bugs 29.7% 25.1% Average bug fixing cost (hours) 1.97 1.8 29.7% 25.1% 70.3% 74.9% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Release 5.5 Release 5.6 % New Bugs % Regression Bugs
- 18. 18
- 19. Continuous Review • Don’t nag for quality! • Continuously monitor the code quality
- 20. Questions ? 20
- 21. Keep In Touch! amr@agileacademy.co amr.noaman@gmail.com www.agileacademy.co Blog: amr.agileegypt.org @amrnoaman
Editor's Notes
- The driving habits and practices are the same The car is different, the tool, the apparatus
- Notes: In the quick-wins stage, it is advisable to work in the same order, remove dead code, then code duplicates, then apply coding style
- Technical Dept: You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place. Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
- Technical Dept: You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place. Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
- Would it make any difference? 60% of time spent on maintenance is consumed in locating the bug
- Notes: In the quick-wins stage, it is advisable to work in the same order, remove dead code, then code duplicates, then apply coding style
- Notes: The effort spent on both releases is the same (4 months each) The number of bugs increased, but this does not indicate less quality, because it depends on many factors like the complexity of the new feature requests. Anyway, the raise in the number of bugs is not dramatic The percentage of regression bugs is the very interesting, because it dropped from about 30 to 25%. This drop may not be a strong indication of good quality, but for sure it is an indication that the applied refactorings did not affect the code quality negatively, which is very interesting. Also, the average bug fixing cost dropped, which may give an indication that code quality is better, or at least the code didn’t go bad due to applied refactorings.
- Notes: In the quick-wins stage, it is advisable to work in the same order, remove dead code, then code duplicates, then apply coding style
- Notes: In the quick-wins stage, it is advisable to work in the same order, remove dead code, then code duplicates, then apply coding style