REFACTORING
Mnats Karakhanyan


Senior iOS Developer at Buymie


Smart Talk June


June 30 2022
WHAT IS REFACTORING
Refactoring is the process of changing a
software system in a way that does not
alter the external behavior of the code yet
improves its internal structure
WHY SHOULD WE REFACTOR
• Refactoring Improves the Design of Software


• Refactoring Makes Software Easier to Understand


• Refactoring Helps Find Bugs


• Refactoring Helps Program Faster
WHY SHOULD WE REFACTOR
“I’m not a great programmer; I’m
just a good programmer with great
habits.”


Kent Beck
WHY SHOULD WE REFACTOR
• Quality


• Clean code


• Profesionalizm


• Right Thing
WHY SHOULD WE REFACTOR
• Quality


• Clean code


• Profesionalizm


• Right Thing
Economy
THE TWO HATS
• Adding Functionality


• Refactoring
WORKFLOWS OF REFACTORING
• TTD Refactoring


• Litter-Pickup Refactoring


• Comprehension Refactoring


• Preparatory Refactoring


• Planned Refactoring


• Long Term Refactoring
BAD SMELLS IN CODE
Indications that there is trouble that
can be solved by a refactoring
BAD SMELLS IN CODE
• Mysterious Name


• Duplicated Code


• Long Function


• Long Parameter List


• Global Data


• Mutable Data


• Divergent Change


• Shotgun Surgery


• Feature Envy
• Middle Man


• Insider Trading


• Large Class


• Alternative Classes with
Different Interfaces


• Data Class


• Refused Bequest


• Comments
• Data Clumps


• Primitive Obsession


• Repeated Switches


• Loops


• Lazy Element


• Speculative Generality


• Temporary Field


• Message Chains
BAD SMELLS IN CODE
• Mysterious Name


• Duplicated Code


• Long Function


• Long Parameter List


• Global Data


• Mutable Data


• Divergent Change


• Shotgun Surgery


• Feature Envy
• Middle Man


• Insider Trading


• Large Class


• Alternative Classes with
Different Interfaces


• Data Class


• Refused Bequest


• Comments
• Data Clumps


• Primitive Obsession


• Repeated Switches


• Loops


• Lazy Element


• Speculative Generality


• Temporary Field


• Message Chains
BLOATERS
Bloaters are code, methods and classes
that have increased to such gargantuan
proportions that they are hard to work with.
Usually accumulate over time
BLOATERS
• Primitive Obsession


• Data Clumps


• Large Class


• Long Parameter List


• Long Function
OBJECT-ORIENTATION ABUSERS
Object Oriented concept not fully
understood and utilized
OBJECT-ORIENTATION ABUSERS
• Temporary Field


• Repeated Switches


• Alternative Classes with


Different Interfaces


• Refused Bequest
CHANGE PREVENTERS
Make changing the system unnecessarily
difficult
CHANGE PREVENTERS
• Shotgun Surgery


• Divergent Change
DISPENSABLES
Something pointless and unneeded whose
absence would make the code cleaner,
more efficient and easier to understand.
DISPENSABLES
• Lazy Element (Dead code)


• Speculative Generality


• Duplicated Code


• Data Class
COUPLERS
Low coupling between objects/classes is
one thedesirable goals of OO software
COUPLERS
• Feature Envy


• Message Chains


• Middle Man


• Insider Trading
EXAMPLE RECIPE
• If you can obtain one parameter by asking another parameter for it, you can use Replace
Parameter with Query


• Rather than pulling lots of data out of an existing data structure, you can use Preserve Whole
Object


• If several parameters always fit together, combine them with Introduce Parameter Object


• If a parameter is used as a flag to dispatch different behavior, use Remove Flag Argument


• when multiple functions share several parameter values. Then, you can use Combine
Functions into Class
Long Parameter List
BIBLIOGRAPHY
Refactoring Improving the Design of Existing Code


by Martin Fowler, with Kent Beck


Clean Code: A Handbook of Agile Software Craftsmanship


by Robert C. Martin


The Pragmatic Programmer: From Journeyman to Master


by Andy Hunt


Head First Design Patterns


by Eric Freeman
THANK YOU

Refactoring.pdf

  • 1.
    REFACTORING Mnats Karakhanyan Senior iOSDeveloper at Buymie Smart Talk June June 30 2022
  • 2.
    WHAT IS REFACTORING Refactoringis the process of changing a software system in a way that does not alter the external behavior of the code yet improves its internal structure
  • 3.
    WHY SHOULD WEREFACTOR • Refactoring Improves the Design of Software • Refactoring Makes Software Easier to Understand • Refactoring Helps Find Bugs • Refactoring Helps Program Faster
  • 4.
    WHY SHOULD WEREFACTOR “I’m not a great programmer; I’m just a good programmer with great habits.” 
 Kent Beck
  • 5.
    WHY SHOULD WEREFACTOR • Quality • Clean code • Profesionalizm • Right Thing
  • 6.
    WHY SHOULD WEREFACTOR • Quality • Clean code • Profesionalizm • Right Thing Economy
  • 7.
    THE TWO HATS •Adding Functionality • Refactoring
  • 8.
    WORKFLOWS OF REFACTORING •TTD Refactoring • Litter-Pickup Refactoring • Comprehension Refactoring • Preparatory Refactoring • Planned Refactoring • Long Term Refactoring
  • 9.
    BAD SMELLS INCODE Indications that there is trouble that can be solved by a refactoring
  • 10.
    BAD SMELLS INCODE • Mysterious Name • Duplicated Code • Long Function • Long Parameter List • Global Data • Mutable Data • Divergent Change • Shotgun Surgery • Feature Envy • Middle Man • Insider Trading • Large Class • Alternative Classes with Different Interfaces • Data Class • Refused Bequest • Comments • Data Clumps • Primitive Obsession • Repeated Switches • Loops • Lazy Element • Speculative Generality • Temporary Field • Message Chains
  • 11.
    BAD SMELLS INCODE • Mysterious Name • Duplicated Code • Long Function • Long Parameter List • Global Data • Mutable Data • Divergent Change • Shotgun Surgery • Feature Envy • Middle Man • Insider Trading • Large Class • Alternative Classes with Different Interfaces • Data Class • Refused Bequest • Comments • Data Clumps • Primitive Obsession • Repeated Switches • Loops • Lazy Element • Speculative Generality • Temporary Field • Message Chains
  • 12.
    BLOATERS Bloaters are code,methods and classes that have increased to such gargantuan proportions that they are hard to work with. Usually accumulate over time
  • 13.
    BLOATERS • Primitive Obsession •Data Clumps • Large Class • Long Parameter List • Long Function
  • 14.
    OBJECT-ORIENTATION ABUSERS Object Orientedconcept not fully understood and utilized
  • 15.
    OBJECT-ORIENTATION ABUSERS • TemporaryField • Repeated Switches • Alternative Classes with 
 Different Interfaces • Refused Bequest
  • 16.
    CHANGE PREVENTERS Make changingthe system unnecessarily difficult
  • 17.
    CHANGE PREVENTERS • ShotgunSurgery • Divergent Change
  • 18.
    DISPENSABLES Something pointless andunneeded whose absence would make the code cleaner, more efficient and easier to understand.
  • 19.
    DISPENSABLES • Lazy Element(Dead code) • Speculative Generality • Duplicated Code • Data Class
  • 20.
    COUPLERS Low coupling betweenobjects/classes is one thedesirable goals of OO software
  • 21.
    COUPLERS • Feature Envy •Message Chains • Middle Man • Insider Trading
  • 22.
    EXAMPLE RECIPE • Ifyou can obtain one parameter by asking another parameter for it, you can use Replace Parameter with Query • Rather than pulling lots of data out of an existing data structure, you can use Preserve Whole Object • If several parameters always fit together, combine them with Introduce Parameter Object • If a parameter is used as a flag to dispatch different behavior, use Remove Flag Argument • when multiple functions share several parameter values. Then, you can use Combine Functions into Class Long Parameter List
  • 23.
    BIBLIOGRAPHY Refactoring Improving theDesign of Existing Code by Martin Fowler, with Kent Beck Clean Code: A Handbook of Agile Software Craftsmanship 
 by Robert C. Martin The Pragmatic Programmer: From Journeyman to Master by Andy Hunt Head First Design Patterns by Eric Freeman
  • 24.