Going through in free preview mode, this caught my attention:
Christian Clausen wrote:There are many possible reasons to refactor:
Making code faster
This contradicts Michael Feathers' assertion in "Working Effectively with Legacy Code" that refactoring and optimization are two different things: the former is to make code easier to work with while the latter improves the use of computing resources. The two may often look the same or very similar but they have very different goals.
In its pure definition "Refactoring" does not care about intention, only effect. It simply means "Changing code without changing what it does".
That being said just a few sentences later I specify that the rest of my book uses this definition of refactoring:
Our definition: Refactoring
Changing code to make it more human-readable and maintainable
without changing what it does.
This definition mirrors the sentiment of the two other authors you mention. I also have a chapter (to be written) about how we should be very careful about optimization; A point with is also mentioned in chapter 2.
Btw. I love the quote in your signature, I actually tweeted the same quote a few months back.
Christian Clausen wrote:In its pure definition "Refactoring" does not care about intention, only effect. It simply means "Changing code without changing what it does".
But Fowler's article states the exact opposite: the distinction between refactoring and optimization is precisely because of different intents. Also, I believe it's "... without changing its observable behavior." Performance is observable though.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
Yes, observable behavior. That is also explained in the book, I was just being brief.
"What does the code do?" is an interesting, albeit somewhat metaphysical, question. Our
first instinct is to think of code as a black box and say that we may change whatever goes
on inside as long as it is indistinguishable from the outside. If we put a value in, we should
get the same result before and after a refactoring — even if the result is an exception.
This is mostly true, with one notable exception: we may change performance.
Fowler writes that he sees them as different. I completely agree, I see them as different processes as well. I also find it more useful to use the two separate words so we can embed intention, which is why I specify that my book also uses the definition that includes intention. However, I stand by my statement that the word "refactoring" does not suggest intention.
Trust God, but always tether your camel... to this tiny ad.
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop