Recovering Design Technical Debt from Source Code Comments Department of Computer Science and Software Engineering Concordia University Montreal, Canada.

Slides:



Advertisements
Similar presentations
Unification and Refactoring of Clones Giri Panamoottil Krishnan and Nikolaos Tsantalis Department of Computer Science & Software Engineering Clone images.
Advertisements

Ranking Refactoring Suggestions based on Historical Volatility Nikolaos Tsantalis Alexander Chatzigeorgiou University of Macedonia Thessaloniki, Greece.
An empirical study on the use of CSS Preprocessors Davood Mazinanian - Nikolaos Tsantalis Department of Computer Science and Software Engineering Concordia.
Properties of Good Requirements Chapter 8. Understandable by end users End-users are not often software engineers. Terminology used must agree with end-
Min Zhang School of Computer Science University of Hertfordshire
Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.
Code Smell Research: History and Future Directions Second PLOW Installment - March 5, Nikolaos Tsantalis Computer Science & Software Engineering.
Reverse Engineering © SERG Code Cloning: Detection, Classification, and Refactoring.
Preventive Software Maintenance: The Past, the Present, the Future Nikolaos Tsantalis Computer Science & Software Engineering Consortium for Software Engineering.
1 Software Maintenance and Evolution CSSE 575: Session 8, Part 3 Predicting Bugs Steve Chenoweth Office Phone: (812) Cell: (937)
REFACTORING Improving the Design of Existing Code Atakan Şimşek e
Quality is about testing early and testing often Joe Apuzzo, Ngozi Nwana, Sweety Varghese Student/Faculty Research Day CSIS Pace University May 6th, 2005.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
Applied Software Project Management 1 Introduction Dr. Mengxia Zhu Computer Science Department Southern Illinois University Carbondale.
Chapter 9 – Software Evolution and Maintenance
Maintenance Refactoring and Code Smells. Where are we? Over the semester we have talked about Software Engineering. The overall goal of software engineering.
Karolina Muszyńska. Reverse engineering - looking at the solution to figure out how it works Reverse engineering - breaking something down in order to.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 Refactoring.
Program Refactoring Mitch Soden Union College. Agenda Definition –Unit Testing –Examples Why Refactor? Limitations Just Another SW Eng Practice? Automation.
Sample Size Determination Donna McClish. Issues in sample size determination Sample size formulas depend on –Study design –Outcome measure Dichotomous.
Advanced Programing practices
Project Tracking. Questions... Why should we track a project that is underway? What aspects of a project need tracking?
1 Welcome to CS 362 Applied Software Engineering What happens after (and during) design? Testing, debugging, maintaining programs Lessons for software.
Facts and Fallacies of Software Engineering (Rob Glass) CSE301 University of Sunderland Discussed by Harry R. Erwin, PhD.
Design and Programming Chapter 7 Applied Software Project Management, Stellman & Greene See also:
Version Control.
17-Oct-15 Refactoring. 2 Refactoring is: restructuring (rearranging) code......in a series of small, semantics-preserving transformations (i.e. the code.
Effective Detection of Self- admitted Technical Debt Everton S. Maldonado Emad Shihab Department of.
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Inoue Laboratory Eunjong Choi 1 Investigating Clone.
Refactoring1 Refactoring DEPARTMENT OF COMPUTER SCIENCE AND SOFTWARE ENGINEERING CONCORDIA UNIVERSITY February 6, 2009.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Refactoring1 Improving the structure of existing code.
Instructore: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Requirement engineering.
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
How to Improve the Safety of Signalling Systems with a Shortened Construction Period in Engineering Construction Projects Gao Guoliang Safety Assurance.
Department of Computer Science, Graduate School of Information Science & Technology, Osaka University 1 Towards an Assessment of the Quality of Refactoring.
Documentation. Your documentation must fit the needs of your audience. It’s always better to say one thing that is useful, as opposed to many things that.
Incremental Design Why incremental design? Goal of incremental design Tools for incremental design  UML diagrams  Design principles  Design patterns.
Software Engineering CS3003 Lecture 4 Code bad smells and refactoring.
Refactoring. Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative.
February 15, 2004 Software Risk Management Copyright © , Dennis J. Frailey, All Rights Reserved Simple Steps for Effective Software Risk Management.
Test-Driven Development Eduard Miric ă. The problem.
The Art of Programming. The process of breaking problems down into smaller, manageable parts By breaking the problem down, each part becomes more specific.
CSC 480 Software Engineering Test Planning. Test Cases and Test Plans A test case is an explicit set of instructions designed to detect a particular class.
SEG 4110 – Advanced Software Design and Reengineering Topic T Introduction to Refactoring.
Refactoring Advanced Software Engineering Dr Nuha El-Khalili.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 Extracting Sequence.
Refactoring1 Improving the structure of existing code.
Refactoring Agile Development Project. Lecture roadmap Refactoring Some issues to address when coding.
Presented by Lu Xiao Drexel University Quantifying Architectural Debt.
BIT 285: ( Web) Application Programming Lecture 14 : Thursday, February 19, 2015 SQL Database and LINQ Instructor: Craig Duckett.
Modularity Most useful abstractions an OS wants to offer can’t be directly realized by hardware Modularity is one technique the OS uses to provide better.
Why We Refactor? Confessions of GitHub Contributors
Testing More In CS430.
Naoya Ujihara1, Ali Ouni2, Takashi Ishio1, Katsuro Inoue1
A Refactoring Technique for Large Groups of Software Clones
Refactoring and Code Smells
: Clone Refactoring Davood Mazinanian Nikolaos Tsantalis Raphael Stein
Two-Liter Bottle Rocket
Software Refactoring Group
Improving the structure of existing code
Refactoring and Code Smells
Unit 6 Assignment 2 Chris Boardley.
Putting your solution into practice
Student name Student ID Degree program Area of specialization
Refactoring and Code Smells
Computational Thinking
How to allow the program to know when to stop a loop.
Why do we refactor? Technical Debt Items Versus Size: A Forensic Investigation of What Matters Hello everyone, I’m Ehsan Zabardast I am a PhD candidate.
Refactoring and Code Smells
Presentation transcript:

Recovering Design Technical Debt from Source Code Comments Department of Computer Science and Software Engineering Concordia University Montreal, Canada 1 Everton da S. Maldonado Emad Shihab Nikolaos Tsantalis

Research Goal 2 Taking shortcuts to achieve project goals will increase its maintenance cost. This is know as Technical Debt. Our goal is to extract comment patterns that effectively identify Design Debt, one of the most impacting type of Technical Debt.

Current solutions 3 SolutionLimitation Tools and techniques to detect bad code smells Design technical debt is more than just Bad Smells Using comments to detect Self-Admitted Technical Debt The approach is too general not addressing Design Debt in detail

4 Research Overview

Case study on ten open source projects 5 ProjectReleaseLOCClassesComments Contributors Ant ,88 1 1,47521,58770 Jmeter2.3281,3071,18120,08432 Argo UML ,83 6 2,60967,71687 Columba1.4100,20 0 1,71133,8959 EMF ,19 1 1,45825,22928 Hibernate3.3.2 GA 173,46 7 1,35611, Jedit4.288, ,99155 Jfreechart ,29 6 1,06523,12318 Jruby ,06 0 1,48611, Squirrel ,23 4 3,10827,47440

Examples indicating Design Debt 6 Comments: This can lead to code smell, meh! Do we care This is an absurdly long method! Break it up. there should be an interface, instead of the AbstractMessageFolder rethink where exactly some of the following methods belong Cyclic dependency with PersistenceManager hack to view title update replace with listener pattern What does the magic number 6000 represent here? Put it in an explanatory literal! Downcast to avoid using an interface? Yuck. unhappy about this being public... is there a better way? remove use of instance of! design flaw, it doesn't update properly

Research question 7 -What comment patterns indicate Self- Admitted design technical debt? How are these comment patterns different than previously proposed comment patterns? We found 176 patterns.

How patterns from both approaches are different ? 8 General TD patterns sample This is uncool Risk of this blowing up Remove this code Something’s gone wrong Certainly buggy Treat this as a soft error Probably a bug This isn’t very solid Is this line really safe Something serious is wrong VS Design TD patterns sample ‘%hack%’ ‘%todo%remove%’ ‘%not %sure %’ ‘%why%not%’ ‘%should%instead%’ ‘%todo%dependenc%’ ‘%better%way%’ ‘%ugly%’ ‘%todo%public%’ ‘%for%some%reason%’

Research question 9 -Can we effectively detect self-admitted design technical debt using the proposed comment patterns? How does the effectiveness of our approach compare to prior approaches? Our overall precision and recall was of 84.93% and 19.01%. While the prior approach achieved 34.52% and 12.00% precision and recall overall respectively.

Approach performance 10 Project Precision % Recall % Apache Ant Jmeter Jfreechart Columba EMF Hibernate Jedit Jruby Squirrel Sql Argo UML88.05-

Comparison between approaches 11 There is little overlap between both approaches. Our approach identifies more Design Technical Debt. ProjectsNumber of classes Number of God classes Self-Admitted Design TD classes Overlap between approaches All projects16,

Can automated refactoring mitigate Design Technical Debt? 12 We found that 24.58% of all files containing Self- Admitted design technical debt had at least one refactoring opportunity. Found refactoring opportunities: 90 “extract long method” 147 “move method”