Quotes About Refactoring

Seibel: Have you heard of refactoring? Cosell: No, what is that? Seibel: What you just described. I think now there's perhaps a bit more acceptance, even among the project managers of this idea.

Build what you need as you need it, aggressively refactoring as you go along; don't spend a lot of time planning for grandiose, unknown future scenarios. Good software can evolve into what it will ultimately become.

Don't be a slave to history. Don't let existing code dictate future code. All code can be replaced if it is no longer appropriate. Even within one program, don't let what you've already done constrain what you do next -- be ready to refactor... This decision may impact the project schedule. The assumption is that the impact will be less than the cost of /not/ making the change.

maintaining good regression tests is the key to refactoring with confidence.

Why don´t you fix bad code when you see it? Your first reaction upon seeing a messy function is ´This is a mess, it needs to be cleaned' . Your second reaction is ´I'm not touching it!´. Beacuse you know that if you touch it you risk breaking it; and if you break it; it becomes yours

It is a myth that we can get systems "right the first time." Instead, we should implement only today's stories, then refactor and expand the system to implement new stories tomorrow. This is the essence of iterative and incremental agility. Test-driven development, refactoring, and the clean code they produce make this work at the code level.

Duplication is the primary enemy of a well-designed system.

1. "First make it work." You are out of business if it doesn't work. 2. "Then make it right." Refactor the code so that you and others can understand it and evolve it as needs change or are better understood. 3. "Then make it fast." Refactor the code for "needed" performance.

Factories are a complexity that can often be avoided, especially in the early phases of an evolving design.

When classes lose cohesion, split them!

Duplication and expressiveness take me a very long way into what I consider clean code, and improving dirty code with just these two things in mind can make a huge difference. There is, however, one other thing that I'm aware of doing, which is a bit harder to explain.

refactored)    /**

highway through the middle of a small town that anticipates growth? Who would want such a road through their town? It is a myth that we can get systems "right the first time." Instead, we should implement only today's stories, then refactor and expand the system to implement new stories tomorrow.

Refactoring is a lot like solving a Rubik's cube. There are lots of little steps required to achieve a large goal. Each step enables the next.

Keeping the design good as it changes is called refactoring.

If developers don't realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it.

Here's a summary list of the valid reasons to create a class: Model real-world objects Model abstract objects Reduce complexity Isolate complexity Hide implementation details Limit effects of changes Hide global data Streamline parameter passing Make central points of control Facilitate reusable code Plan for a family of programs Package related operations Accomplish a specific refactoring

One indication that a routine needs to be broken out of another routine is deep nesting of an inner loop or a conditional. Reduce the containing routine's complexity by pulling the nested part out and putting it into its own routine.

If a class contains more than about seven data members, consider whether the class should be decomposed into multiple smaller classes (Riel 1996). You might err more toward the high end of 7±2 if the data members are primitive data types like integers and strings, more toward the lower end of 7±2 if the data members are complex objects.

Spend your time on the 20 percent of the refactorings that provide 80 percent of the benefit.

When it's hard to work on. I do it much quicker than most people do. I'll throw away code as soon I want to add something to it and I get the feeling that what I have to do to add it is too hard. I'll throw it away and start over and come up with a different partitioning that makes it easy to do whatever I wanted to do. I'm really quick on the trigger for throwing stuff out.

Although now that I'm in middle management I'm supposed to call it refactoring the strategic value proposition in real time with agile implementation," or, if I'm being honest, "making it up as I go along.

If your code needs comments, consider refactoring it so it doesn't.

Instead of commenting sections in long functions, extract smaller functions whose names capture the former sections' intent.