1. Definition by Martin Fowler
a.The purpose of refactoring is to
make the software easier to understand and modify
b.Refactoring
does not change the observable behavior of the software
2. Why Refactor? To make software easier to understand
a. You can refactor it to make it more readable for future developers
b. You can even refactor other’s code when trying to understand it
3. When to Refactor
a. Don’t set aside time to do refactoring. Instead do refactoring only because you want to do something else better.
b. So when?
i. I’m adding a new feature and I need to understand the existing code.
ii.I’m adding a new feature but existing code is hard for me to do that
iii. We are doing code review and we received a suggestion. We refactor the code to implement the suggestion to see whether it works.
4. Problems of re-factoring
a. DB is hard to refactor
b. Changing Publised Interface is not Easy (Web Service Interface, etc.)
i. In this case, provide the new method while retaining the old one (Deprecate it)
ii. Try not to publish interfaces if not required
5. Refactoring as an Alternative to Upfront Design
a. Strict Upfront Design doesn’t work because problems usually show up when coding
b. Programming and refactoring without any upfront design can work but it is not the most efficeint way
c. The right way to go: Do some upfront design to have a plausible solution, then refactor
d. Q: Shall I have a flexible solution for this feature?
A: What if I just have a simple solution here? If it is easy for me to refactor the simple solution to a flexible solution in the future, then we stick to the simple solution; Or else, we create a flexible version now.
6. Refactoring & Performance
Refactoring may lead to slow software since it introduces more indirection, however, it makes the software easier to tune because it leads to finer granularity, which helps you find the exact hot spot.