Please enable JavaScript.

Coggle requires JavaScript to display documents.

Refactoring - Coggle Diagram

- - - - Benefits
        
        supports CD
        
        Flexible code
        
        Produces easy to test code
        
        No waste of effort -> thanks to clear reqs
      - Starts from well defined requirements
        
        Needs management buy-in
  - - - Extract method
        
        redundancy
      - Inline method
        
        when logic is trivial
      - Extract variable
        
        self documented names
        
        block with complex logic, diff to follow
      - Inline variable
        
        simple values, simplify
      - Split temporary variables
        
        no reuse
      - remove parameter assignation
        
        use a local variable in method body instead
      - replace temporary variables
        
        with a method call
        
        if sole purpose is receiving value (nah)
      - replace method
        
        complex logic
        
        dependency between variables
        
        could work better as a class
      - Substitute algorithm
        
        favor simple logic
  - - - Via
        
        Change unidirectional to bidirectional to association when needed
        
        Change bidirectional to unidirectional association when only 1 is used
        
        Pull up
        
        Pull up field
        
        When a field is used in subclasses
        
        Move field up in hierarchy to superclass
        
        Pull up method
        
        Same method in subclasses
        
        If not identical but similar, factor up the common funcionality and pull that up
        
        Pull up constructor body
        
        If common constructor code is shared, move it up
        
        Create interim superclasses if not all derived from super share the same members
        
        Push down
        
        Method
        
        Method used in a few subclasses, move it from superclass
        
        Field
        
        Move it from superclass if only used by some sub classes
        
        Create interim subclass (of super) if not all classes derived from super share the same members
        
        Extract interface
        
        Interface seggregation
        
        Combine collapse hierarchy
        
        When hiearchy goes too far
        
        Super classes are almost identical
        
        Level of abstraction is not really useful
        
        Form template method in super
        
        When several subclasses implement same steps of algorithm
        
        Only internal code of steps change
        
        subclases define actual steps logic
        
        Replace inheritance with Delegation
        
        If you violate Liskov
        
        Use internal instance of previous super in previous subclass
        
        Replace delegation with inheritance
        
        If class A wraps B in internal field
        
        And uses all of B functionality
      - Bring back cohesion
    - - Encapsulation
        
        SELF encapsulation
        
        Using properties even within same class methods
        
        EXTERNAL
        
        Collections too
        
        Primitive
      - Replace data value with object
        
        if value depends on complex logic, replace with a class
      - Change value to reference
        
        for multiple copies of same stuff (flighweight pat)
      - Chance reference to value
        
        when no reuse is intended
        
        isolate copies
      - Replace array with Object
        
        array = poor man's class
      - duplicate observed data
        
        separate data from UI and domain backend
        
        should be decoupled and duplicated/copied
        
        Separation of concerns
        
        i.e. model -> view model
      - Replace magic string / numbers
      - Replace type code
        
        Primitive type props
        
        Replace type code with (static) class methods (RLY?)
        
        With subclasses
        
        i.e. Car class creating VIN for differen subclass models
        
        with state / strategy
      - Replace thin classes with field values
  - - - remove unnecessary parameters
        
        if parameter is the same, use a constant instead
      - Renaming for descriptiveness
      - avoid too many params
      - Separate query from modification
      - parametrize method
        
        merge similar funcionality when logic is the same for a varying number of params
        
        i.e. param1, param2, param3
      - Replace parameter with explicit methods
        
        Split into explicit methods
        
        Added value: reduce number of parameters
        
        When Portions of method depend on a parameter value
      - Parameter object
        
        if values belong to a single object
        
        let method pick the values it needs
        
        preserve whole object, pass the reference
        
        If different objects
        
        Create a parameter object
      - Replace parameter with method call
        
        When temp variable is only used to store value to pass it as arg
        
        just use the method call in method invocation
      - Remove unused setters / getters
      - Hide methods
        
        That are public but in fact are never used from outside
      - Replace constructor with factory method
        
        Ctor must be simple, just initialize stuff
        
        All other heavy lifting should be moved
      - Exceptions
        
        Exceptions are not for logic flow control
        
        Replace with conditions
        
        Replace error codes with exceptions
  - - - introduce null object
        
        If some methods return null, use null object instead
      - introduce assertion
        
        validate before anything else
        
        Defensive coding
  - - - complex condition -> decompose in separate methods
      - multiple conditions -> consolidate into a single expression
      - duplicated conditions -> consolidate outside conditions
      - replace control flag
        
        with break / continue/return flow control
      - replace nested conditional
        
        break down the most specific conditionals into separate, before the main / parent cond
      - Replace with polymorphism
        
        if action bsed on props of object
        
        break actions in subclasses
- - - - Documented, voluntarily "todo"
    - - Each going their way
      - Improper training from Sr. to Jr.
  - - - i.e.Agreed due to deadline
      - Document it in backlog
      - Associate it (tag or otherwise) to the original task
    - - i.e. N00bs
      - Ignoring the recommended patterns at first
      - Review periodically design to detect and plan refactor
    - - i.e. Scope change
      - Bit rot debt
        
        Constant move to entropy systems do over time
        
        Should be covered by code reviews daily to slow it down
- - - - Decompose single install into several, for eachservice
        
        EAR in java
        
        Install in win
      - Container per service pattern
      - CI/CD each service on their own
      - They are completely independent apps
    - - Own Repo
      - how is code organized?
        
        REST= Resource mapped, easy scenenario
        
        Function based: SOAP, EJB
    - - Independent, isolated db
      - How data is managed
        
        Different tiers according to usage
        
        warm
        
        cold
        
        hot
        
        Batch data updates between tiers
        
        Denormalization
  - - - Large
      - Not single purpose
      - does everything
    - - Breakdown into atomic funcional services
      - Maybe still share db
      - more manageable
    - - Completely self contained
    - - Scale up
      - Spin down
- - - - i.e. a class tries to get too much knowledge of another
      - Solve with "Tell, Dont ask"
        
        Move logic to actual owner of info
        
        Results in better encapsulation
        
        But beware of God Object
- - - - easier to add it on refactored code
    - - Since you're already there...
      - Rule of 3
    - - Las heroic line of defense
      - reducing bit rot debt
  - - - Better to start from scratch
    - - Refactors take time
      - A bit unpdredictable