A Gentle Introduction to Refactoring

Episode Breakdown

• 12:52 Refactoring Defined

  “Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software.”

  This means making the internals of an application less painful to work with for developers. Refactoring is reconfiguring code to best survive the environment it lives in, it’s an evolutionary process.

• 14:42 Why Refactor Code

  Refactoring improves the ability of developers to troubleshoot problems in code base. It also allows for increases in the speed at which new features can be surfaced and tested. Decoupling the internal components keeps dependency changes from causing major rework. Code may need to reorganized in preparation for future operations or components broken apart for separate iteration.



• 27:55 Hindrances to Refactoring

  “This code works! Why mess with it?”

  Organizational inertia is caused by managers and owners who do not see the value in refactoring or the potential dangers of not refactoring. Interpersonal disputes about how to proceed may hinder refactoring efforts. The originators of the code may not want to see it changed. Inability to test for regressions or comprehend existing systems also pose hindrances to refactoring.

• 39:38 Strategies for Refactoring

  • Small locus of control

    Start refactoring with something small. Don’t start a refactoring that takes days because you will miss something, or get distracted or discouraged. These processes take place while still delivering a product or service. Do a small piece then go back to the work that is bringing in a paycheck and come back later for another small slice.

  • Testability of changes

    Write things so that the piece you are changing it is testable. This protects against the possibility of creating breaking changes in other parts of the code. If that happens testable code will help show if or where the refactored code breaks.

  • Reference architecture

    Build a piece of code that’s complete end to end. This sets the cleaned up design so that the next person to come in will know how it works. It also helps to make sure there are not major holes in the refactoring due to a cross cutting refactor.

  • Small changes at a time (small wins)

    Psychologically small wins develop confidence in the refactoring process. Also small changes when implemented correctly help reduce organizational inertia by showing management the benefits of refactoring without making major changes to the code.

  • Short iterations before integration

    Make a branch, refactor, push it back to the main branch. Small changes and short iterations because checking out a branch for six months then pushing it back will make breaking changes for other developers on the team.