{"id":5003295,"date":"2015-12-16T23:40:07","date_gmt":"2015-12-17T07:40:07","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&#038;p=5003295"},"modified":"2022-08-30T11:22:51","modified_gmt":"2022-08-30T18:22:51","slug":"refactoring","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/refactoring\/","title":{"rendered":"Refactoring"},"content":{"rendered":"<p>Refactoring consists of improving the internal structure of an existing program\u2019s source code while preserving its external behavior.<\/p>\n<p>The noun \u201crefactoring\u201d refers to one particular behavior-preserving transformation, such as \u201cExtract Method\u201d or \u201cIntroduce Parameter.\u201d<\/p>\n<h2>Common Pitfalls<\/h2>\n<p>Refactoring does \u201cnot\u201d mean:<\/p>\n<ul>\n<li>rewriting code<\/li>\n<li>fixing bugs<\/li>\n<li>improve observable aspects of software such as its interface<\/li>\n<\/ul>\n<p>Refactoring in the absence of safeguards against introducing defects (i.e. violating the \u201cbehavior preserving\u201d condition) is risky. Safeguards include aids to regression testing including automated unit tests or automated acceptance tests and aids to formal reasoning such as type systems.<\/p>\n<h2>Expected Benefits<\/h2>\n<p>The following are claimed benefits of refactoring:<\/p>\n<ul>\n<li>refactoring improves objective attributes of code (length, duplication, coupling and cohesion, cyclomatic complexity) that correlate with ease of maintenance<\/li>\n<li>refactoring helps code understanding<\/li>\n<li>refactoring encourages each developer to think about and understand design decisions, in particular in the context of\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/collective-ownership\/\" target=\"_blank\" rel=\"noopener noreferrer\">collective ownership \/ collective code ownership<\/a><\/li>\n<li>refactoring favors the emergence of reusable design elements (such as design patterns) and code modules<\/li>\n<\/ul>\n<h2>Signs Of Use<\/h2>\n<ul>\n<li><a href=\"https:\/\/agilealliance.org\/glossary\/version-control\/\">version control<\/a>\u00a0records (such as CVS or git logs) include entries labeled \u201cRefactoring\u201d<\/li>\n<li>the code modifications corresponding to such entries can be verified to be behavior-neutral: no new unit tests or functional tests are introduced, for example<\/li>\n<\/ul>\n<h2>Skill Levels<\/h2>\n<ul>\n<li>Beginner<\/li>\n<li>knows the definition of \u201crefactoring\u201d<\/li>\n<li>can use some automated refactorings from the IDE<\/li>\n<li>can perform some refactorings by hand<\/li>\n<li>is aware of the risks of regression from manual and automated refactorings<\/li>\n<li>is aware of code duplication and can remove it by refactoring<\/li>\n<li>Intermediate<\/li>\n<li>knows and is able to remedy a broader range of \u201ccode smells\u201d<\/li>\n<li>can chain several refactorings to carry out a design intention, in awareness of the dependencies between refactorings<\/li>\n<li>refactors continuously, rather than in sporadic and lengthy sessions<\/li>\n<li>Advanced<\/li>\n<li>has an acute sense of code duplication and coupling<\/li>\n<li>applies refactorings to non-code elements such as database schema, documents, etc.<\/li>\n<li>uses refactoring to guide large bodies of code toward design styles intentionally chosen from a broad palette: object-oriented, functional, or inspired by known design patterns<\/li>\n<\/ul>\n<h2>Further Reading<\/h2>\n<ul>\n<li><a href=\"http:\/\/www.amazon.com\/dp\/0201485672\">Refactoring<\/a>, by Martin Fowler<\/li>\n<li><a href=\"https:\/\/www.manning.com\/books\/the-mikado-method\">The Mikado Method\u00a0<\/a>by Ola Ellnestam and Daniel Brolund<\/li>\n<\/ul>\n<h2>Origins<\/h2>\n<ul>\n<li>1984: the notion of \u201cfactoring\u201d, anticipation of refactoring, is described in Brodie\u2019s <a href=\"http:\/\/thinking-forth.sourceforge.net\/\">\u201cThinking Forth\u201d<\/a>, where it is presented as \u201corganizing code into useful fragments\u201d which \u201coccurs during detailed design and implementation\u201d.<\/li>\n<li>1990: Bill Opdyke coins the term \u201crefactoring\u201d in an ACM SIGPLAN paper with Ralph Johnson, \u201cRefactoring: An aid in designing application frameworks and evolving object-oriented systems\u201d<\/li>\n<li>1992: a comprehensive description of \u201crefactoring\u201d is presented in Opdyke\u2019s thesis,\u00a0<a href=\"http:\/\/www.laputan.org\/pub\/papers\/Opdyke-Thesis.pdf\">\u201cRefactoring object-oriented frameworks\u201d<\/a><\/li>\n<li>1999: the practice of \u201crefactoring\u201d, incorporated a few years earlier into\u00a0<a href=\"https:\/\/agilealliance.org\/glossary\/xp\/\">Extreme Programming<\/a>, is popularized by Martin Fowler\u2019s book of the same name<\/li>\n<li>2001: refactoring \u201ccrosses the\u00a0<a href=\"http:\/\/martinfowler.com\/articles\/refactoringRubicon.html\">Rubicon<\/a>\u201c, an expression of Martin Fowler describing the wide availability of automated aids to refactoring in IDEs for the language Java<\/li>\n<\/ul>\n<h2>Academic Publications<\/h2>\n<p>Although the practice of refactoring has become popular, rigorously establishing its benefit in an academic context has proven thorny, illustrating a common gap between research and common practice.<\/p>\n<ul>\n<li><a href=\"http:\/\/win.ua.ac.be\/~qsoeten\/other\/data\/Soetens2010QUATIC.pdf\">Studying the Effect of Refactorings: a Complexity Metrics Perspective<\/a>, a 2010 study, finds surprisingly little correlation between refactoring episodes, as identified by version control logs, and a decrease in cyclomatic complexity<\/li>\n<\/ul>\n<p>Such studies may be affected by methodological issues, such as identifying what counts as a \u201crefactoring\u201d when examining code histories after the fact; the above paper, for instance, finds that programmers often label \u201crefactorings\u201d sets of code changes which also include additional functionality or bug fixes.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Refactoring consists of improving the internal structure of an existing program&#8217;s source code, while preserving its external behavior.<\/p>\n","protected":false},"author":8027401,"featured_media":8067461,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[906],"tags":[],"class_list":["post-5003295","aa_glossary","type-aa_glossary","status-publish","has-post-thumbnail","hentry","category-technology"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003295","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_glossary"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/8027401"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=5003295"}],"version-history":[{"count":0,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_glossary\/5003295\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8067461"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=5003295"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=5003295"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=5003295"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}