Communications of the ACM
Barriers to Refactoring
Credit: Justin Metz
Refactoring6 is something software developers like to do. They refactor a lot. But do they refactor as much as they would like? Are there barriers that prevent them from doing so? Refactoring is an important tool for improving quality. Many development methodologies rely on refactoring, especially for agile methodologies but also in more plan-driven organizations. If barriers exist, they would undermine the effectiveness of many product-development organizations. We conducted a large-scale survey in 2009 of 3,785 practitioners' use of object-oriented concepts,7 including questions as to whether they would refactor to deal with certain design problems. We expected either that practitioners would tell us our choice of design principles was inappropriate for basing a refactoring decision or that refactoring is the right decision to take when designs were believed to have quality problems. However, we were told the decision of whether or not to refactor was due to non-design considerations.
Key Insights
It is now eight years since the survey, but little has changed in integrated development environment (IDE) support for refactoring, and what has changed has done little to address the barriers we identified. We hope that presenting what we have learned will encourage improvement in refactoring support.
Comments
Bryan McKinley
Today, many agile teams are moving to DevOps technologies and practices (e.g., cloud). DevOps teams employ automated and continuous testing of system behavior and qualities, allowing for more frequent refactoring opportunities and trials (e.g., git pull request). Such test automation may reduce barriers to refactoring, such as risk. So, rather than focus solely on barriers to refactoring, why not include a focus on enablers of refactoring, such as DevOps technologies and practices?
Bryan McKinley
https://www.linkedin.com/in/bryan-mckinley-phd/
Displaying 1 comment