Refactoring Quotes

“I’m not a great programmer; I’m just a good programmer with great habits.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“If you can get today’s work done today, but you do it in such a way that you can’t possibly get tomorrow’s work done tomorrow, then you lose.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“A heuristic we follow is that whenever we feel the need to comment something, we write a method instead.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Now I'm a pretty lazy person and am prepared to work quite hard in order to avoid work.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Other than when you are very close to a deadline, however, you should not put off refactoring because you haven’t got time. Experience with several projects has shown that a bout of refactoring results in increased productivity. Not having enough time usually is a sign that you need to do some refactoring.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“In almost all cases, I’m opposed to setting aside time for refactoring. In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Code should be obvious: When someone needs to make a change, they should be able to find the code to be changed easily and to make the change quickly without introducing any errors. 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. But the most important thing to learn from this example is the rhythm of refactoring. Whenever I’ve shown people how I refactor, they are surprised by how small my steps are, each step leaving the code in a working state that compiles and passes its tests. I was just as surprised myself when Kent Beck showed me how to do this in a hotel room in Detroit two decades ago. The key to effective refactoring is recognizing that you go faster when you take tiny steps, the code is never broken, and you can compose those small steps into substantial changes. Remember that—and the rest is silence.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code (Addison-Wesley Signature Series

“Life being what it is, you won't get your names right the first time. In this situation you may well be tempted to leave it—after all it's only a name. That is the work of the evil demon Obfuscatis; don't listen to him. If you see a badly named method, it is imperative that you change it. Remember your code is for a human first and a computer second. Humans need good names.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“I write them to improve my productivity as a programmer. Making the quality assurance department happy is just a side effect. Unit tests are highly localized. Each test class works within a single package. It tests the interfaces to other packages, but beyond that it assumes the rest just works.

Functional tests are a different animal. They are written to ensure the software as a whole works. They provide quality assurance to the customer and don't care about programmer productivity. They should be developed by a different team, one who delights in finding bugs.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Parallel inheritance hierarchies is really a special case of shotgun surgery. In this case, every time you make a subclass of one class, you also have to make a subclass of another.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“I’ve found that refactoring helps me write fast software. It slows the software in the short term while I’m refactoring, but it makes the software easier to tune during optimization. I end up well ahead.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“If you have to spend effort looking at a fragment of code and figuring out what it's doing, then you should extract it into a function and name the function after the "what".”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“It reminds me of a statement Kent Beck often makes about himself: “I’m not a great programmer; I’m just a good programmer with great habits.” Refactoring helps me be much more effective at writing robust code.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code (Addison-Wesley Signature Series

“It's more than a little ironic that many of us preach safety first to our children, nieces, and nephews but in our roles as programmers scream for freedom, a hybrid of the Wild West gunslinger and teenage driver. Give us freedom, give us the resources, and watch us fly.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“People sometimes ask me what length I look for in a method. To me length is not the issue. The key is the semantic distance between the method name and the method body. If extracting improves clarity, do it, even if the name is longer than the code you have extracted.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“A statement Kent Beck often makes about himself, "I'm not a great programmer; I'm just a good programmer with great habits.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“So, my overall advice on performance with refactoring is: Most of the time you should ignore it. If your refactoring introduces performance slow-downs, finish refactoring first and do performance tuning afterwards.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code (Addison-Wesley Signature Series

“Most programmers, even experienced ones, are poor judges of how code actually performs.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code (Addison-Wesley Signature Series

“As I suggested before, temporary variables can be a problem. They are only useful within their own routine, and therefore they encourage long, complex routines.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code (Addison-Wesley Signature Series

“If oy have to spend effort looking at a fragment of code and figuring out what it's doing, then you should extract it into a function and name the function after the "what".”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“It’s hard to figure out what the right amount of hiding is. Fortunately, with Hide Delegate (189) and Remove Middle Man, it doesn’t matter so much. I can adjust my code as time goes on. As the system changes, the basis for how much I hide also changes. A good encapsulation six months ago may be awkward now. Refactoring means I never have to say I’m sorry—I just fix it.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code (Addison-Wesley Signature Series

“An intuitive definition is that a safe refactoring is one that doesn't break a program. Because a refactoring is intended to restructure a program without changing its behavior, a program should perform the same way after a refactoring as it does before.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Leaving nots in a conditional like that twists my mind around at a painful angle”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Repetition is the root of all software evil”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Notice how I'm playing the part of an enemy to code. I'm actively thinking about how I can break it. I find that state of mind to be both productive and fun. It indulges the mean-spirited part of my psyche. When you are doing tests, don't forget to check that expected errors occur properly.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“The lesson is: Even if you know exactly what is going on in your system, measure performance, don't speculate. You'll learn something, and nine times out of ten, it won't be that you were right!”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Code that communicates its purpose is very important. I often refactor just when I'm reading some code. That way as I gain understanding about the program, I embed that understanding into the code for later so I don't forget what I learned.”
― Martin Fowler, Refactoring: Improving the Design of Existing Code

“Even so the program works. Is this not just an aesthetic judgment, a dislike of ugly code?”
― Martin Fowler, Refactoring: Improving the Design of Existing Code