This post contains the best, in my opinion, quotes from the must-read book "Refactoring: Improving the Design of Existing Code" by Martin Fowler.
refactoringBook

Software developers are professionals. Our job is to build effective software as rapidly as we can. My experience is that refactoring is a big ait to building software quickly. If I need to add a new function and the design does not suit the change, I find it's quicker to refactor first and then add the function. If I need to fix a bug, I need to understand how the software works - and I find refactoring is the fastest wat to do this.

The interesting thing about performance is that if you analyze most programs, you find that they waste most of their time in a small fraction of the code. If you optimize all the code equally, you end up with 90 percent of the optimizations wasted, because you are optimizing code that isn't run much. The time spent making the program fast, the time lost because of lack of clarity, is all wasted time.

If you look at how most programmers spend their time, you'll find that writing code actually is quite a small fraction. Some time is spent figuring out what ought to be going on, some time is spent designing, but most time is spent debugging.

I should mention that often when I'm writing tests, I start by making them fail. (...) I do this because I like to procve to myself that the test does actually run and the test is actually testing what it's supposed to (...).

I write them [unit tests] to improve my productivity as a programmer. (...) Functional tests are a different animal. They are written to ensure that software as a whole works. They provide quality assurance to the customer and don't care about programmer productiviy.

The essence of polymorphism is that instead of asking an object what type it is and then invoking some behavior on the answer, you just invoke the behavior. The object, depending on its type, does the thing.

One of the most valuable conventions I've used over the years is to clearly separate methods that change state (modifiers) from those that query state (queries).

Another thing to realize about there refactorings is that they take time. [...] We have worked at some of the big refactorings for months or years on running systems.

Ralph Johnson taught me an important lesson about research: if someone (a reviewer of a paper, an attendee at a talk) comments, "I don't understand or just doesn't get it, it's our fault.

How does one safely refactor? There are several options:

  • Trust your coding abilities.
  • Trust that your compiler will catch errors that you miss.
  • Trust that your test suite will catch errors that you and your compiler miss.
  • Trust that code review will catch errors that you, your compiler, and your test suite miss.