Just how frequently is 'refactor frequently'?

I was asked what I meant by refactor frequently on the guidelines and could not locate a good answer to that... to me the question was wrong. When should not you refactor is more along the lines of my thinking. Not that I think there's a great answer to that either, but then I did skip over the google results that implicated when to stop refactoring or when not to refactor while searching for these quotes.

I tend to refactor with support from the DRY principle of as soon as you notice something is redundant or repeated. I refactor either on the first noticed redundancy or the 2nd when I'm primarily coding, when I'm reviewing, I try to refactor any redundancy I find. I also refactor based on the other Code Smells. I will also refactor when I notice violations of SOLID,  Domain Driven Design (DDD for short), and now I've started to think about Command-Query Seperation (CQS).

When I see code that looks ugly but fits these I'll shoot for refactoring towards a Fluent Interface  with Method Chaining

I think I already do command query separation but I haven't been looking for it in particular.

And here's the email I sent out to the team, it appears that what I just wrote here probably should been included at the top... oh well. A little context, the email was generated in response to a meeting on the coding standards I put forth.

... asked me for guidelines in our meeting about how frequent is ‘refactor frequently’? I had difficultly answering the question and I think everyone here was aware of that. I hope to address this question with some support from the blogosphere/industry.

·         Before any redesign

o   Helps you get familiar or re-familiarize yourself with the existing code

o   Helps solidify the existing design for the addition of new features.

·         Before any new project that builds on top of the old one

·         Before adding new features to a stable build

·         Semi-continuous refactoring

o   Code a little, test a little, refactor a little.

·         Make it your goal to leave the code in better shape at the end of the day than at the beginning

Ideas from Elliotte Rusty Harold – from The Cafes – When to Refactor author of the book Refactoring HTML

Refactoring throughout the entire project life cycle saves time and increases quality.

Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity. Keep your code clean and concise so it is easier to understand, modify, and extend. Make sure everything is expressed once and only once. In the end it takes less time to produce a system that is well groomed.

From - Refactor Mercilessly

When?

The sooner the better as is easier, faster and less risky to refactor over a recently refactored code rather than waiting to refactor for the code to be almost completed.

From Alberto Gutierrez’s blog Making good software – Refactoring: The 5 main questions: Why? When? What? How? Who?

What is refactoring and why?

XP Practices: Refactoring

Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior. Un-refactored code tends to rot. Rot takes several forms: unhealthy dependencies between classes or packages, bad allocation of class responsibilities, duplicate code, and many other varieties of confusion and clutter. (Check out this list of such "design smells.")

Rot is what makes code difficult to maintain or extend. Every time we change code without refactoring it, rot worsens and spreads. Code rot frustrates us, costs us time, and unduly shortens the lifespan of useful systems.

Refactoring code ruthlessly prevents rot, by keeping code easy to maintain and extend. This extensibility is the reason to refactor and the measure of its success. This is what enables XP teams to embrace arbitrary and drastic change. Note that the XP practice of Test-driven Development (TDD) is essential to refactoring. The exhaustive tests produced by TDD are what make it safe and orderly to make changes of any kind. This is why Adaption always teaches TDD and refactoring together.

Code Hygiene

What does "refactor ruthlessly" mean? It means striving as a matter of routine to keep the code's design simple and crystal clear. It means knowing the design principles and patterns that are vital to keeping code extensible, and knowing when to "refactor toward" them. It means refactoring both production code and test code frequently during the day, eliminating all forms of the "code smells" that are precursors to true rot.

Mainly it means never going home at the end of the day with "code debts" that need paying tomorrow (smelly sections that need cleaning up). This level of code hygiene may at first seem like a lot of extra work, but it pays you such dividends so soon and so regularly that you soon become addicted to it -- rather like TDD.

From adaption