Refactoring
COMP2511
Refactoring
Prepared by
Ashesh Mahidadia
Refactoring: Motivation
v Code refactoring is the process of restructuring existing computer code without
changing its external behavior.
v Originally Martin Fowler and Kent Beck defined refactoring as,
“A change made to the internal structure of software to make it easier to understand
and cheaper to modify without changing its observable behavior… It is a disciplined
way to clean up code that minimizes the chances of introducing bugs.”
v Advantages: improved code readability, reduced complexity; improved maintenance
and extensibility
v If done well, helps to identify hidden or dormant bugs or vulnerabilities, by simplifying
code logic.
v If done poorly, may change external behavior, and/or introduce new bugs!
v Refactoring is different to adding features and debugging.
COMP2511: Refactoring 2
Refactoring: Motivation
v Refactoring is usually motivated by noticing a code smell (possible bad design/coding
practices).
v Code Smell is a hint that something might be wrong, not a certainty.
v Identifying a Code Smell allows us to re-check the implementation details and consider
possible better alternatives.
v Automatic unit tests should be set up before refactoring to ensure routines still behave
as expected.
v Refactoring is an iterative cycle of making a small program transformation, testing it to
ensure correctness, and making another small transformation.
COMP2511: Refactoring 3
Software Maintenance
v Software Systems evolve over time to meet new requirements and features.
v Software maintenance involve:
• Fix bugs
• Improve performance
• Improve design
• Add features
v Majority of software maintenance is for the last three points!
v Harder to maintain code than write from scratch!
v Most of the development time is spent in maintenance!
v Good design, coding and planning can reduce maintenance pain and time!
v Avoid code smells to reduce maintenance pain and time!
COMP2511: Refactoring 4
Code Smells: Possible Indicators
v Duplicated code
v Poor abstraction (change one place → must change others)
v Large loop, method, class, parameter list; deeply nested loop
v Class has too little cohesion
v Modules have too much coupling
v Class has poor encapsulation
v A subclass doesn’t use majority of inherited functionalities
v A “data class” has little functionality
v Dead code
v Design is unnecessarily general
v Design is too specific
COMP2511: Refactoring 5
Low-level refactoring
v Names:
v Renaming (methods, variables)
v Naming (extracting) “magic” constants
v Procedures:
v Extracting code into a method
v Extracting common functionality (including duplicate code) into a class/method/etc.
v Changing method signatures
v Reordering:
v Splitting one method into several to improve cohesion and readability
(by reducing its size)
v Putting statements that semantically belong together near each other
v For more, see http://www.refactoring.com/catalog/
COMP2511: Refactoring 6
IDEs support low-level refactoring
v Renaming:
• Variable, method, class.
v Extraction:
• Method, constant
• Repetitive code snippets
• Interface from a type
v Inlining: method, etc.
v Change method signature.
v Warnings about inconsistent code.
COMP2511: Refactoring 7
Higher-level refactoring
v Refactoring to design patterns.
v Changing language idioms (safety, brevity).
v Performance optimization.
v Generally high-level refactoring is much more important,
but unfortunately not well-supported by tools.
COMP2511: Refactoring 8