• Code decays at a non-linear rate and refactoring helps preserve the shape of code to prevent rapid decay.
  • Refactoring aims to improve the structure of the code without affecting any observable functionality.
  • When refactoring the code we want to make sure the software keeps working as expected. The best way to achieve this is with the help of a good set of tests.
    • We must make sure that our tests cover the areas we touch during refactoring.
    • If they do not, we must stop now, and start adding those tests before even starting to rename a single method.
  • We should make changes in steps as small as possible and test those changes. This way we know what and when we messed up and it is easier to revert as our step was small.
  • When you refactor, you refactor in small steps.
    • You test your changes.
    • And then, you commit that change to your favorite version control system.
    • Now you have a clear history of well-tested changes.
  • Refactoring before adding new functionality will help with the thought process. And leaving the codebase better than you have found it is a bonus.
  • The point of renaming should be to use descriptive names that save us time.
    • A good name for a variable saves us from reading how it got here to understand what value it holds.
    • A good name for a method saves us from reading its entire implementation to understand what it does.
  • Performance might get affected during the refactoring process.
    • Even if it does, it usually does in small scales with no significant loss.
    • But, it is a good habit to take note of possible performance degrading points.