# notes on martin fowler, refactoring: improving the design of existing code, 2nd edition, 2018

## currently reached page

page 58

## chapter 1:
- set up small tests to verify that your refactoring isn't causing harm
- refactor in small steps
- compile-test-commit between every small step
- squash commits into a solid commit before pushing

## chapter 2:
- refactoring definitions:
    - noun:
        > Refactoring (noun): a change made to the internal structure of software to make it
        > easier to understand and cheaper to modify without changing its observable behavior.
        > This definition corresponds to the named refactorings I’ve mentioned in the earlier
        > examples, such as Extract Function (106) and Replace Conditional with Polymorphism
        > (272).

    - verb:
        > Refactoring (verb): to restructure software by applying a series of refactorings
        > without changing its observable behavior.
- refactoring focuses on small steps that dont break behaviour:
    > Over the years, many people in the industry have taken to use “refactoring” to mean any
    > kind of code cleanup—but the definitions above point to a particular approach to
    > cleaning up code. Refactoring is all about applying small behavior preserving steps and
    > making a big change by stringing together a sequence of these behavior preserving
    > steps. Each individual refactoring is either pretty small itself or a combination of small
    > steps. As a result, when I’m refactoring, my code doesn’t spend much time in a broken
    > state, allowing me to stop at any moment even if I haven’t finished.

    - tip:
        > If someone says their code was broken for a couple of days while they are
        > refactoring, you can be pretty sure they were not refactoring.