An Empirical Investigation into the Role of API-Level Refactoring during Software Evolution, Miryung Kim, Dongxiang Cai, Sunghun Kim, ICSE' 11: Proceedings of the 2011 ACM and IEEE 33rd International Conference on Software Engineering
Congratulations Graduate! Eleven Reasons Why I Will Never Hire You.Mark O'Toole
Over the past 20 years, I’ve been in hiring roles and have received thousands of resumes from new college graduates. I’ve interviewed many for real jobs and done my share of informational interviews. Sometimes I’ve hired people into entry-level positions. More often though, I haven’t.
Those who did not get the job were sometimes just not the right fit. Other times, they were trumped by a more impressive candidate or victim to some other random event mostly out of their control.
Too many had the background to make the cut or at least garner a second interview. But disastrous interviewing skills brought you down.
Here are my top reasons why I will never hire you.
OSGi Semantic Versioning with Baselining in enRoute - P Kriensmfrancis
OSGi Community Event 2014
Abstract:
Most people consider versions tedious and boring. And they are right! However, that does not make them less important. Unless you always compile all your code together and never have to go back in time, versions are the threads that keep the systems together in a stable way. That is, if people did not make those stupid mistakes with versions ...
Meet semantic versioning and baselining. Semantic versions provide a framework to automate version handling. This framework is used in bnd(tools) to automate most version handling.
This presentation will show what OSGi semantic versions are and its extension to also semantically version contracts. It will demonstrate the bnd(tools) support which is part of enRoute to detect semantic version violations in real time as well as in the continuous build.
Speaker Bio:
Peter Kriens is an independent consultant since 1990.He currently works for the OSGi Alliance and jpm4j. During the eighties he developed advanced distributed systems for newspapers based on microcomputers based on, at the time very novel, object oriented technologies. For this experience in Objects he was hired by a number of international companies, including Adobe, Intel, Ericsson, IBM, and many others. During his work at Ericsson Research in 1998 he got involved with the OSGi specification; Later he became the primary editor for these specifications. In 2005 he was awarded the OSGi Fellows title. After taking a sabbatical in 2012 to develop jpm4j he returned to the OSGi Alliance to help increasing adoption. He is Dutch but decided to live in France.
Historical and Impact Analysis of API Breaking Changes: A Large-Scale StudyLaerte Xavier
Change is a routine in software development. Like any system, libraries also evolve over time. As a consequence, clients are compelled to update and, thus, benefit from the available API improvements. However, some of these API changes may break contracts previously established, resulting in compilation errors and behavioral changes. In this paper, we study a set of questions regarding API breaking changes. Our goal is to measure the amount of breaking changes on real-world libraries and its impact on clients at a large-scale level. We assess (i) the frequency of breaking changes, (ii) the behavior of these changes over time, (iii) the impact on clients, and (iv) the characteristics of libraries with high frequency of breaking changes. Our large-scale analysis on 317 real-world Java libraries, 9K releases, and 260K client applications shows that (i) 14.78% of the API changes break compatibility with previous versions, (ii) the frequency of breaking changes increases over time, (iii) 2.54% of their clients are impacted, and (iv) systems with higher frequency of breaking changes are larger, more popular, and more active. Based on these results, we provide a set of lessons to better support library and client developers in their maintenance tasks.
Early Identification of Future Committers in Open Source Software ProjectsSAIL_QU
RQ1: The activities of future committers, such as patch and comment submissions, are higher than developers before becoming committers.
RQ2: Rapidly-promoted committers perform more activities than regularly-promoted committers. Regularly-promoted committers actively work for 1-1.5 years before becoming committers.
RQ3: A machine learning model using developer activities like number of patches and comments can predict future committers with over 80% accuracy, higher than a random predictor.
Bug fixing is a time-consuming and tedious task. To reduce the manual efforts in bug fixing, researchers have pre- sented automated approaches to software repair. Unfortunately, recent studies have shown that the state-of-the-art techniques in automated repair tend to generate patches only for a small number of bugs even with quality issues (e.g., incorrect behavior and nonsensical changes). To improve automated program repair (APR) techniques, the community should deepen its knowledge on repair actions from real-world patches since most of the techniques rely on patches written by human developers. Previous investigations on real-world patches are limited to statement level that is not sufficiently fine-grained to build this knowledge. In this work, we contribute to building this knowledge via a systematic and fine-grained study of 16,450 bug fix commits from seven Java open-source projects. We find that there are opportunities for APR techniques to improve their effectiveness by looking at code elements that have not yet been investigated. We also discuss nine insights into tuning automated repair tools. For example, a small number of statement and expression types are recurrently impacted by real-world patches, and expression-level granularity could reduce search space of finding fix ingredients, where previous studies never explored.
This document discusses maintaining assertions across code refactorings. It proposes classifying refactorings into three categories based on their effect on assertions: trivial, manual, and automatable refactorings. Self-encapsulate field is presented as an example of an automatable refactoring. A procedure is described for extracting a setting method's precondition from the class invariant by applying logical rules to a predicate tree representation. The procedure is demonstrated formally and with a proof-of-concept application. Future work includes improving the data extraction and integrating the approach into a refactoring tool to automate more refactorings while preserving assertions.
Transformation-based Refactorings: a First AnalysisESUG
This document discusses refactoring transformations in Smalltalk. It defines key terms like refactoring, transformation, and preconditions. It aims to understand how transformations could share code with refactorings and be composed from simpler transformations. The document analyzes refactorings in the Refactoring Browser engine to identify atomic refactorings, precondition types, and potential opportunities to turn the program modification API into first-class transformations.
This document proposes a new metric for measuring the reusability of object-oriented software components. It discusses various class, attribute, method, and parameter metrics that could indicate reusability. The paper describes two experiments where code samples were analyzed based on these metrics. The results show that factors like low coupling between classes, simple attribute and method structures, and meaningful names correlate with more reusable code. A new reusability metric formula is proposed that combines several of these metrics.
Congratulations Graduate! Eleven Reasons Why I Will Never Hire You.Mark O'Toole
Over the past 20 years, I’ve been in hiring roles and have received thousands of resumes from new college graduates. I’ve interviewed many for real jobs and done my share of informational interviews. Sometimes I’ve hired people into entry-level positions. More often though, I haven’t.
Those who did not get the job were sometimes just not the right fit. Other times, they were trumped by a more impressive candidate or victim to some other random event mostly out of their control.
Too many had the background to make the cut or at least garner a second interview. But disastrous interviewing skills brought you down.
Here are my top reasons why I will never hire you.
OSGi Semantic Versioning with Baselining in enRoute - P Kriensmfrancis
OSGi Community Event 2014
Abstract:
Most people consider versions tedious and boring. And they are right! However, that does not make them less important. Unless you always compile all your code together and never have to go back in time, versions are the threads that keep the systems together in a stable way. That is, if people did not make those stupid mistakes with versions ...
Meet semantic versioning and baselining. Semantic versions provide a framework to automate version handling. This framework is used in bnd(tools) to automate most version handling.
This presentation will show what OSGi semantic versions are and its extension to also semantically version contracts. It will demonstrate the bnd(tools) support which is part of enRoute to detect semantic version violations in real time as well as in the continuous build.
Speaker Bio:
Peter Kriens is an independent consultant since 1990.He currently works for the OSGi Alliance and jpm4j. During the eighties he developed advanced distributed systems for newspapers based on microcomputers based on, at the time very novel, object oriented technologies. For this experience in Objects he was hired by a number of international companies, including Adobe, Intel, Ericsson, IBM, and many others. During his work at Ericsson Research in 1998 he got involved with the OSGi specification; Later he became the primary editor for these specifications. In 2005 he was awarded the OSGi Fellows title. After taking a sabbatical in 2012 to develop jpm4j he returned to the OSGi Alliance to help increasing adoption. He is Dutch but decided to live in France.
Historical and Impact Analysis of API Breaking Changes: A Large-Scale StudyLaerte Xavier
Change is a routine in software development. Like any system, libraries also evolve over time. As a consequence, clients are compelled to update and, thus, benefit from the available API improvements. However, some of these API changes may break contracts previously established, resulting in compilation errors and behavioral changes. In this paper, we study a set of questions regarding API breaking changes. Our goal is to measure the amount of breaking changes on real-world libraries and its impact on clients at a large-scale level. We assess (i) the frequency of breaking changes, (ii) the behavior of these changes over time, (iii) the impact on clients, and (iv) the characteristics of libraries with high frequency of breaking changes. Our large-scale analysis on 317 real-world Java libraries, 9K releases, and 260K client applications shows that (i) 14.78% of the API changes break compatibility with previous versions, (ii) the frequency of breaking changes increases over time, (iii) 2.54% of their clients are impacted, and (iv) systems with higher frequency of breaking changes are larger, more popular, and more active. Based on these results, we provide a set of lessons to better support library and client developers in their maintenance tasks.
Early Identification of Future Committers in Open Source Software ProjectsSAIL_QU
RQ1: The activities of future committers, such as patch and comment submissions, are higher than developers before becoming committers.
RQ2: Rapidly-promoted committers perform more activities than regularly-promoted committers. Regularly-promoted committers actively work for 1-1.5 years before becoming committers.
RQ3: A machine learning model using developer activities like number of patches and comments can predict future committers with over 80% accuracy, higher than a random predictor.
Bug fixing is a time-consuming and tedious task. To reduce the manual efforts in bug fixing, researchers have pre- sented automated approaches to software repair. Unfortunately, recent studies have shown that the state-of-the-art techniques in automated repair tend to generate patches only for a small number of bugs even with quality issues (e.g., incorrect behavior and nonsensical changes). To improve automated program repair (APR) techniques, the community should deepen its knowledge on repair actions from real-world patches since most of the techniques rely on patches written by human developers. Previous investigations on real-world patches are limited to statement level that is not sufficiently fine-grained to build this knowledge. In this work, we contribute to building this knowledge via a systematic and fine-grained study of 16,450 bug fix commits from seven Java open-source projects. We find that there are opportunities for APR techniques to improve their effectiveness by looking at code elements that have not yet been investigated. We also discuss nine insights into tuning automated repair tools. For example, a small number of statement and expression types are recurrently impacted by real-world patches, and expression-level granularity could reduce search space of finding fix ingredients, where previous studies never explored.
This document discusses maintaining assertions across code refactorings. It proposes classifying refactorings into three categories based on their effect on assertions: trivial, manual, and automatable refactorings. Self-encapsulate field is presented as an example of an automatable refactoring. A procedure is described for extracting a setting method's precondition from the class invariant by applying logical rules to a predicate tree representation. The procedure is demonstrated formally and with a proof-of-concept application. Future work includes improving the data extraction and integrating the approach into a refactoring tool to automate more refactorings while preserving assertions.
Transformation-based Refactorings: a First AnalysisESUG
This document discusses refactoring transformations in Smalltalk. It defines key terms like refactoring, transformation, and preconditions. It aims to understand how transformations could share code with refactorings and be composed from simpler transformations. The document analyzes refactorings in the Refactoring Browser engine to identify atomic refactorings, precondition types, and potential opportunities to turn the program modification API into first-class transformations.
This document proposes a new metric for measuring the reusability of object-oriented software components. It discusses various class, attribute, method, and parameter metrics that could indicate reusability. The paper describes two experiments where code samples were analyzed based on these metrics. The results show that factors like low coupling between classes, simple attribute and method structures, and meaningful names correlate with more reusable code. A new reusability metric formula is proposed that combines several of these metrics.
ICSME14 - On the Impact of Refactoring Operations on Code Quality MetricsOscar Chaparro
Slides of the ICSME 2014 submission:
Chaparro, O.; Bavota, G.; Marcus, A.; Di Penta, M., "On the Impact of Refactoring Operations on Code Quality Metrics," Software Maintenance and Evolution (ICSME), 2014 IEEE International Conference on , vol., no., pp.456,460, Sept. 29 2014-Oct. 3 2014
The Calc core code in LibreOffice underwent a major refactoring which changed the underlying data model. This caused regressions across many areas that affected Calc functionality. While the initial expectation was that the worst was over after fixing initial bugs, ongoing refactoring work and additional regressions were discovered. Extensive unit testing will be key to ensuring fixes are not broken again in the future.
Recording Finer-Grained Software Evolution with IDE: An Annotation-Based Appr...Shinpei Hayashi
This document proposes an annotation-based approach to recording finer-grained software evolution using an IDE. Developers can classify their edit operations according to different modes, and the system structures the edits to generate source code deltas for each intentional change. A prototype implementation as an Eclipse plug-in automates reordering edits based on the modes. This approach aims to avoid mixed changesets and better capture the relationships between changes.
Generators take a high-level software specification and produce an implementation. GenVoca is an approach to building generators that composes reusable component layers. It models software as realms of components with vertical and horizontal parameters. Components are implemented as C++ templates containing member classes. Composition validation ensures semantics are correct. Aspect-oriented programming (AOP) and GenVoca both aim to improve code reuse but differ in focus, concepts, and implementation mechanisms like aspect languages versus type expressions. Generators automate implementation through transformations while GenVoca provides a systematic approach through composable and customizable components.
Generators take a high-level software specification and produce an implementation. GenVoca is an approach to building generators that composes reusable component layers. It models software as realms of components with vertical and horizontal parameters. Components are implemented as C++ templates containing member classes. Composition validation ensures semantics are correct. Aspect-oriented programming (AOP) and GenVoca both promote code reuse but differ in focus, concepts, and implementation mechanisms like aspect languages versus type expressions. Generators automate implementation through transformations while GenVoca provides a systematic approach through composable, standardized components.
Approximating Change Sets at Philips Healthcare: A Case StudyRahul Premraj
Talk presented on March 4, 2011 at the 15th European Conference on Software Maintenance and Reengineering in Oldenburg, Germany.
Abstract: A single development task such as solving a bug or implementing a new feature often involves changing a number of entities, also known together as a change set. Change sets can be approximated from the version control system. They are then used by the architects and developers to take important decisions. So change sets need to be approximated carefully. It is common to assume that two entities checked-in less than a small time interval from each other, and having the same meta-data associated with them, belong to the same transaction. Transactions may be good approximations of change sets if developers commit change sets in one go and if the required meta-data is available. This is however not the case in the industrial environment (Philips Healthcare) we study. Our paper presents a case study in which we investigated how change sets can be approximated in an environment with a complex workflow and limited meta-data in the version repositories. We found that, dependent on the commit practices used, a suitable time intervals between check-in timestamps of files has to be determined and leveraged to reliably approximate change sets.
The document discusses reasons for maintaining and modifying software solutions such as changing user requirements, upgrading interfaces, introducing new hardware/software, changes in organizational focus or government requirements, and improving poorly implemented code. It also outlines features that improve a code's maintainability like meaningful variable names, comments, standard structures, and logical subroutines. Maintainability is important so software can adapt to changing needs and standards over time.
More Related Content
Similar to ICSE 2011 Research Paper on Refactorings and Bug Fixes
ICSME14 - On the Impact of Refactoring Operations on Code Quality MetricsOscar Chaparro
Slides of the ICSME 2014 submission:
Chaparro, O.; Bavota, G.; Marcus, A.; Di Penta, M., "On the Impact of Refactoring Operations on Code Quality Metrics," Software Maintenance and Evolution (ICSME), 2014 IEEE International Conference on , vol., no., pp.456,460, Sept. 29 2014-Oct. 3 2014
The Calc core code in LibreOffice underwent a major refactoring which changed the underlying data model. This caused regressions across many areas that affected Calc functionality. While the initial expectation was that the worst was over after fixing initial bugs, ongoing refactoring work and additional regressions were discovered. Extensive unit testing will be key to ensuring fixes are not broken again in the future.
Recording Finer-Grained Software Evolution with IDE: An Annotation-Based Appr...Shinpei Hayashi
This document proposes an annotation-based approach to recording finer-grained software evolution using an IDE. Developers can classify their edit operations according to different modes, and the system structures the edits to generate source code deltas for each intentional change. A prototype implementation as an Eclipse plug-in automates reordering edits based on the modes. This approach aims to avoid mixed changesets and better capture the relationships between changes.
Generators take a high-level software specification and produce an implementation. GenVoca is an approach to building generators that composes reusable component layers. It models software as realms of components with vertical and horizontal parameters. Components are implemented as C++ templates containing member classes. Composition validation ensures semantics are correct. Aspect-oriented programming (AOP) and GenVoca both aim to improve code reuse but differ in focus, concepts, and implementation mechanisms like aspect languages versus type expressions. Generators automate implementation through transformations while GenVoca provides a systematic approach through composable and customizable components.
Generators take a high-level software specification and produce an implementation. GenVoca is an approach to building generators that composes reusable component layers. It models software as realms of components with vertical and horizontal parameters. Components are implemented as C++ templates containing member classes. Composition validation ensures semantics are correct. Aspect-oriented programming (AOP) and GenVoca both promote code reuse but differ in focus, concepts, and implementation mechanisms like aspect languages versus type expressions. Generators automate implementation through transformations while GenVoca provides a systematic approach through composable, standardized components.
Approximating Change Sets at Philips Healthcare: A Case StudyRahul Premraj
Talk presented on March 4, 2011 at the 15th European Conference on Software Maintenance and Reengineering in Oldenburg, Germany.
Abstract: A single development task such as solving a bug or implementing a new feature often involves changing a number of entities, also known together as a change set. Change sets can be approximated from the version control system. They are then used by the architects and developers to take important decisions. So change sets need to be approximated carefully. It is common to assume that two entities checked-in less than a small time interval from each other, and having the same meta-data associated with them, belong to the same transaction. Transactions may be good approximations of change sets if developers commit change sets in one go and if the required meta-data is available. This is however not the case in the industrial environment (Philips Healthcare) we study. Our paper presents a case study in which we investigated how change sets can be approximated in an environment with a complex workflow and limited meta-data in the version repositories. We found that, dependent on the commit practices used, a suitable time intervals between check-in timestamps of files has to be determined and leveraged to reliably approximate change sets.
The document discusses reasons for maintaining and modifying software solutions such as changing user requirements, upgrading interfaces, introducing new hardware/software, changes in organizational focus or government requirements, and improving poorly implemented code. It also outlines features that improve a code's maintainability like meaningful variable names, comments, standard structures, and logical subroutines. Maintainability is important so software can adapt to changing needs and standards over time.
Similar to ICSE 2011 Research Paper on Refactorings and Bug Fixes (7)
2. It is believed that refactoring improves
software quality and maintainability.
The role of refactoring has not been
systematically investigated using fine‐
grained revision history at the method level.
3. We studied the relationships between API‐level
refactorings, bug fixes, the time taken to fix
bugs, and release cycles.
• The number of bug‐fixes increases after API‐level
refactorings.
• A large number of refactoring revisions include
bug fixes or are related to later fixes.
• Bug fix time tends to be shorter after than before.
• API‐level refactorings occur more frequently
before major releases than after.
5. Refactoring improves software quality and
maintainability [Opdyke, Griswold, Mens, etc.]
A lack of refactoring incurs technical debt.
[Cunningham, Lehman]
Refactor mercilessly [Beck, eXtreme
Programming]
Productivity improves after re‐architecting a
system [Carriere et al.]
Defect density decreases after refactoring
[Ratzinger et al.]
6. The number of bug reports increases after
refactorings [Weißgerber & Diehl]
Incomplete or inconsistent refactorings cause
bugs [Görg and Weißgeber]
Code churns are correlated with defect
density [Nagappan & Ball]
9. Q1: Are there more bug fixes after API‐level
refactorings?
Q2: Are API‐level refactorings correlated to
bug fixes?
Q3: Do API‐level refactorings reduce the time
taken to fix bugs?
Q4: Are there relatively fewer API‐level
refactorings before release dates?
10. API‐level
Refactoring Fix Revision
[ICSE 2007,
Reconstruction S. Kim et al.]
[ICSE 2007, M. Kim et al.]
Identify Refactoring Identify
Revisions Fix Revisions
Introducing
Change Distilling
Change [TSE 2007,
[MSR 2005, B. Fluri et al.]
Sliwerski et al.]
Identify Bug Life Time Map line‐level changes
to methods
12. API‐level
Refactoring Rename, move, and signature changes
Reconstruction at or above the method header level
[ICSE 2007, M. Kim et al.]
Foo.mA(int)
Foo.mA()
Foo.mB(int)
Foo.mB()
Foo.mC()
Foo.mC()
Bar.mA(long)
Boo.mA(long)
Baz.mA(int)
Boo.mB(long)
Baz.mB(int)
15. Fix Revision Use heuristics to identify bug fix revisions
[ICSE 2007,
e.g., [bug] [id #], [fixed]
S. Kim et al.]
r1 r2 r3 r4 r5 r6 r7 r8
Ref Fix Ref/Fix Fix
16. Introducing
Change Use SVN blame (diff) to track down
[MSR 2005, the changes that led to fixes.
Sliwerski et al.]
Bug‐introducing changes
r1 r2 r3 r4 r5 r6 r7 r8
Ref Fix Ref/Fix Fix
18. Change Distilling Map line‐level location to a method level location
[TSE 2007, Filter out meaningless changes.
B. Fluri et al.]
r1 r2 r3 r4 r5 r6 r7 r8
Ref Fix Ref/Fix Fix
19. Eclipse JDT jEdit Columba
core
Type IDE Text editor Email client
Period June 5th, 2001 to Sep 2, 2001 to July 9th, 2006 to
May 16th 2007 Apr, 2009 Jan 31st 2010
# revisions 15000 11102 421
# of API‐level 6755 3557 424
refactorings
# of bug fix 3752 1073 150
revisions
# of refactoring 1089 423 36
revisions
20. GT source # Prec. recall
API 14 API‐level refactoring detection 14 0.93 0.93
Refactoring [M. Kim et al. ]
revision
Inspection of change logs only 2 0.50 0.07
Inspection of bug reports only 5 0.75 0.21
Fix 62 Fix‐revision detection [S. Kim 49 0.96 0.76
Revision et al.]
Inspection of change logs only 55 0.92 0.81
Inspection of bug reports only 49 0.94 0.74
Automated techniques vs. Manual Inspection
26. Study Method 1: We measure a fix rate (# fix
revisions / K) within K sliding window after
each refactoring revision. K revision windows
Ref Ref Fix Ref Fix Fix Ref Fix
Study Method 2: We measure a fix rate at
the method level
M.foo()=>M.bar()
Ref Fix Fix
28. Results: fix rates at the method level also
increase after refactorings
Fix rate at a method level
0.40% 1.00% 8.00%
0.30% 0.80% 6.00%
0.60%
0.20% 4.00%
0.40%
0.10% 0.20% 2.00%
0.00% 0.00% 0.00%
‐30 ‐20 ‐10 0 10 20 30 ‐30 ‐20 ‐10 0 10 20 30 ‐30 ‐20 ‐10 0 10 20 30
Refactoring timing
JDT jEdit Columba
There is a short term increase in the number of bug fixes
after refactorings
29. 20 revision windows
Ref Fix Fix
In Eclipse, 208 refactoring revisions are followed by at least
one bug fix to the same method location within 20 revisions.
30. 20 revision windows
Ref Fix Fix
We randomly sampled 50 revision pairs and manually
inspected them.
31. R F
Types Frequency
1. To fix several related bugs, a developer first refactors 6%
code.
2. Incorrect refactorings cause a bug, inducing a later fix. 6%
3. After a developer performs refactorings, she discovers a 2%
new bug and fixes it.
4 Refactoring with a bug fix is incomplete. A developer 50%
applies a supplementary fix later.
5. A bug fix happened after a refactoring in the same 36%
location, but they are not related.
34. Probability of fixes and refactorings at the revision level
Project P(F) P(R) P(R|F) P(R|not F) P(F|R) P(F|not R)
Eclipse 25% 7.3% 12% 5.7% 41.5% 23.7%
JDT
JEdit 9.7% 3.8% 11.5% 3.0% 29.1% 8.9%
Columba 35.7% 8.6% 10.7% 7.4% 44.4% 34.8%
Refactorings and bug fixes often occur together in the same
revisions.
35. Results:
# of Ref‐revisions that were # of Non‐ref revisions that were
related to fix within (0,K] related to fix within (0,K]
2245
(14.0%)
495 (32.0%)
1053 13847 (86.0%)
(68.0%)
K=20
Refactoring revisions are followed by related bug fixes more
often than non‐refactoring revisions.
41. Results:
average fix
K=100
time (days)
25 120 250 230.2
19.7 98.6
20 100 200
80 149.6
15 150
60 42.6
10 7.3 100
5.6 40
4.4 21.5
12.2 38.4 48.4
5 20 50
0 0 0
BB AA XB BA BB AA XB BA BB AA XB BA
JDT jEdit Columba
When it comes to fixing bugs introduced near the time of
refactorings, the average fix time tends to decrease after
refactorings
43. Results
30% Eclipse JDT
25%
refactoring rate
20%
15%
10%
5%
0%
K=‐20 K=20 K=‐30 K=30 K=‐40 K=40
window size (K)
There are more refactorings prior to major version releases.
44. Study intra‐method refactorings and
complex refactorings (e.g., use RefFinder
[Prete et al.])
Account for the size of edits and the number
of refactorings
Phase & activity level
Micro‐commit practices
45. API‐level refactoring and bug fixes are
correlated temporally and spatially.
API‐level refactoring serves the role of both
facilitating bug fixes and introducing bugs.
API‐level refactoring occurs as a part of
behavior correcting edits
Refactoring engines must support safe application of
refactorings and semantic changes together.
The result calls for an in‐depth study on the cost and
benefit of refactorings.