recommending refactorings based on team co-maintenance patterns
DESCRIPTION
Refactoring aims at restructuring existing source code when undisciplined development activities have deteriorated its comprehensibility and maintainability. There exist various approaches for suggesting refactoring opportunities, based on different sources of information, e.g., structural, semantic, and historical. In this paper we claim that an additional source of information for identifying refactoring opportunities, sometimes orthogonal to the ones mentioned above, is team development activity. When the activity of a team working on common modules is not aligned with the current design structure of a system, it would be possible to recommend appropriate refactoring operations|e.g., extract class/method/package|to adjust the design according to the teams' activity patterns. Results of a preliminary study conducted in the context of extract class refactoring show the feasibility of the approach, and also suggest that this new refactoring dimension can be complemented with others to build better refactoring recommendation tools.TRANSCRIPT
04/09/2023
Recommending Refactorings based on Team Co-
Maintenance Patterns
Gabriele Sebastiano Nikolaos Massimiliano Rocco Gerardo
Bavota Panichella Tsantalis Di Penta Oliveto Canfora
04/09/2023
Outline
Context and Motivations- Software Development- Team based Refactoring (TBR) for restructuring
source code
Case Study- User Study: releases of the Android APIs
Results- Evaluation of TBR and comparison with the state of the art
04/09/2023
Refactoring is…
‘‘…a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior’’. [Fowler 1999]
04/09/2023
Refactoring Sources of Information
- Refactoring operation need to capturing relation between code components.
- Various are the explored sources of information:
- Structural (Static and Dynamic);
- Semantic;
- Historical.
04/09/2023
Structural Information
- calls between methods, shared attributes, call relationships occurring during program execution.
Pros: - precise
information;- easy to capture;- always available.Cons:- may be imprecise;- may miss some kinds of dependencies.
04/09/2023
Semantic Information
04/09/2023
Semantic Information
- Textual similarity between code components.
04/09/2023
Semantic Information
Pros: - easy to capture;- always available.Cons:- Assumption that
terms are consistently used in the code
- Textual similarity between code components.
04/09/2023
Historical Information
Fabio Palomba et al. in ‘’Detecting bad smells in source code using change history information.’’’ - ASE 2013.
04/09/2023
Historical Information
Fabio Palomba et al. in ‘’Detecting bad smells in source code using change history information.’’’ - ASE 2013.
04/09/2023
Historical Information
Fabio Palomba et al. in ‘’Detecting bad smells in source code using change history information.’’’ - ASE 2013.
Pros: - precise information.Cons:- too strong to capture.
04/09/2023
Are we Missing other Kinds of Dependencies?
04/09/2023
Software development is a very human intensive activity….
Are we Missing other Kinds of Dependencies?
04/09/2023
Social Dimension
Time interval considered
04/09/2023
Social Dimension
Time interval considered
04/09/2023
Team-based Refactoring Opportunity
04/09/2023
Extract Class
Team-based Refactoring Opportunity
04/09/2023
Our ContributionTeam Based Refactoring (TBR):Information derived from teams to identify refactoring opportunities.
04/09/2023
Our Contribution
1) Teams identification
2) Detection of Refactoring opportunities (e.g. extract class refactoring)
Team Based Refactoring (TBR):Information derived from teams to identify refactoring opportunities.
04/09/2023
Teams Identification
Time
04/09/2023
Teams Identification
Time
Time window considered
04/09/2023
Teams Identification
Time
Time window considered
Class 1
Class 3
Class 2
Class 4
04/09/2023
Teams Identification
Time
Time window considered
Class 1
Class 3
Class 2
Class 4
04/09/2023
Teams Identification
Time
Time window considered
Class 1
Class 3
Class 2
Class 4
04/09/2023
Teams Identification
Time
Time window considered
Class 1
Class 3
Class 2
Class 4
04/09/2023
Teams Identification
Time
Time window considered
Class 1
Class 3
Class 2
Class 4
Ward's hierarchical clustering
04/09/2023
Detection of Refactoring Opportunities
Time window considered
1) Existence of a set of methods owned by a Team
Class 1
Class 3
Class 2
Class 4
04/09/2023
Detection of Refactoring Opportunities
Time window considered
1) Existence of a set of methods owned by a Team
2) Splitting classes with many responsabilities
Class 1
Class 2
Class 4Class 3
Class 2 –a)
Class 2 –b)
04/09/2023
Detection of Refactoring Opportunities
Time window considered
1) Existence of a set of methods owned by a Team
2) Splitting classes with many responsabilities
Class 2 –a)
Class 2 –b)
Class 1
Class 3
Class 2
Class 4
04/09/2023
Case Study
Goal: evaluate and compare the quality of the refactoring solutions identified by TBR with approaches based on more traditional sources.
Research questions:
• RQ1: Is the information derived from teams useful to identify refactoring opportunities?
• RQ2: Is the information derived from teams complementary to the sources of information typically exploited to identify refactoring opportunities?
04/09/2023
Context
•Objects:
•Subjects:
2 PhD students1 Industrial developer
Project from Andr. Api Period KLOC
framework-opt-telephony
Aug 2011-Jan 2013 73-78
framework-base Oct 2008-Jan 2013 534-1,043
framework-support Feb 2011-Nov 2012 58-61
sdk Oct 2008-Jan 2013 14-82
tool-base Nov 2012-Jan 2013 80-134
04/09/2023
RQ1: Is the information derived from teams
useful to identify refactoring opportunities?
Medium/Low perceived effort
Useful Refactoring solutions
78%
74%
22%
26%
NO YES
04/09/2023
RQ1: Is the information derived from teams
useful to identify refactoring opportunities?
Medium/Low perceived effort
Useful Refactoring solutions
78%
74%
22%
26%
NO YES
04/09/2023
RQ1: Is the information derived from teams
useful to identify refactoring opportunities?
Medium/Low perceived effort
Useful Refactoring solutions
78%
74%
22%
26%
NO YES
RQ2: TBR complementarity with other sources typically used for identifying refactoring
opportunities
Evaluation: MoJoFM
RQ2: TBR complementarity with other sources typically used for identifying refactoring
opportunities
Evaluation: MoJoFM
C1 C2
1
2 34
1
2 54
6
MoJoFM = 0 move + 0 join = 0= 1= 21 move 2 move
3
6
5
RQ2: TBR complementarity with other sources typically used for identifying refactoring
opportunities
Evaluation: MoJoFM
C1 C2
1
24
1
2 54
MoJoFM = 2 move + 0 join = 2= 3= 41 join2 join
63
3
6
5
3 move = 5
5
RQ2: TBR complementarity with other sources typically used for identifying refactoring
opportunities
Evaluation: MoJoFM
C1 C2
1
24
1
2 54
MoJoFM = 3 move + 3 join = 5= 63 join
3
6
5
63
max(∀ mno(Ci,Cj)max(∀ mno(Ci,Cj)
Structural U Semantic U Historical
Structural Semantic Historical0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
70%
30%
43%35%
RQ2: TBR complementarity with other sources typically used for identifying refactoring
opportunities
Structural U Semantic U Historical
Structural Semantic Historical0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
70%
30%
43%35%
30%
RQ2: TBR complementarity with other sources typically used for identifying refactoring
opportunities
04/09/202341
Conclusion
04/09/202342
Conclusion
04/09/202343
Conclusion
04/09/202344
Conclusion
04/09/202345
Conclusion