Refactoring Chapter 1 — A First Example
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. — Martin Fowler
The early stages on refactoring are mostly driven by trying to understand what is going on. A common sequence is: Read the code, gain some insight, and use refactoring to move that insight from your head back into the code. The clearer code then makes it easier to understand it, leading to deeper insights and a beneficial positive feedback loop. In the end it may happen to still have some improvements you could make, but if you feel that you have done enough to pass the test of leaving the code significantly better than how you found it, mission accomplished.
But also you should know when to refactor: if the code works and doesn’t ever need to change, it’s perfectly fine to leave it alone. It would be nice to improve it, but unless someone needs to understand it, it isn’t causing any real harm. Yet as soon as someone does need to understand how that code works, and struggles to follow it, then you have to do something about it.
That's why the true test of good code is how easy it is to change it. A healthy code base maximizes our productivity, allowing us to build more features for our users both faster and more cheaply. To keep code healthy, pay attention to what is getting between the programming team and that ideal, then refactor to get closer to the ideal.
The key to effective refactoring is recognizing that you go faster when you take tiny steps because the code is never broken, and you can compose those small steps into substantial changes.
Remember that — and the rest is silence.
Continue to Chapter 2 — Principles in Refactoring (Part I)
