Refactoring and stop sign Thread

Do you use refactoring and agile in development?

How you stop it. I'm almost lost in it. This thing bog me down.

I believe in constant refactoring.

Could you explain a bit more what bogs you down ?
Is your issue not knowing when to stop refactoring ?

When I'm refactoring I can not stop. Redoing and improving architecture, managing classes and messages, optimizing algorithms e.t.c

And when you look at work - nothing done, but all beautifully clean and organized.

How to get stop sign for refactoring?

I think that if you are refactoring, you should have a goal to work towards. So you should stop once you have reached that goal.
It sounds a bit like you just start refactoring without having a clear reason or problem to solve, so you don't have a definition of 'done', is that correct?

I try to work in agile style. And in agile cycle: test - write - refactor, does not support goals to finish.

When test light is green I can refactor until perfect code arrived. But it newer comes.

Refactoring is fuzzy matter. How you can define goal if you do not know which kind of beast you meet in process?

Of course you have goals when using agile! How else would you know what you are developing and what you are going to do in a cycle/when a cycle is done? It does not mean that a feature has to be fully completed to never be looked at again, but you can still have the goal to complete certain parts of a feature.
There also can be goals while refactoring. Usually you start refactoring because there is a problem. For example, if the current architecture makes some essential parts of the system difficult to reach or to use, I would first define what I consider 'sufficiently usable' and change the code to make it according to that definition. Even when the code could be improved even more in other areas that don't cause any problems at that point, the problem I had was solved, so I would stop refactoring. If I would continue to refactor, just because I think things would get better/more optimized that way even though I don't notice the impact at that moment, I would consider that premature optimization. Which, as we all know, is the root of all evil.

This is my personal view on it though, but it works for me and prevents me from getting stuck in the refactoring phase. And else I definitely would get stuck there, because I am a perfectionist.

Edited by: SIGILL

Thank you for advice. I will look how to apply it to my work. Refactoring only when needed.

I'm very upset how Kent Beck write about TDD and not mention this: refactor when only problem arises.

His cycle: Write test - write code - refactor without stop sign can end in refactor phase. And I stumble about it.

Your help is very very important.

After 20 years learning something new is encouraging for new achievments.

Good luck.

If you find yourself refactoring 101 times it may because you're still learning to code.

This is a good thing as iterativly updating and changing your code will help improve your understanding of how it works.

Agree 100% with Metalspy's post regarding need for a goal. You could invest some time in learning some good code design patterns, this would no doubt provide a bit of a framework and a goal for you to work towards when writing code.

Edited by: ccbytes

Fun thing that I'm learning for twenty years now. And each year has new methodology or instrument to learn and use.

Patterns so enforcing. I use them only when it fits well into code.

Sorry if I renew this outdated post.

My personal approach to the question is opposed to yours, stoarch.

I have goals but lack of time to refactor my code. I end up always coding a lot of junk until goal is reached, then a little bit of refactoring of everything is done. But the agile methods (if I got it correctly what it is refered to) is what I apply in my approach to code an idea, since i haven't already planned everything.

There is absolutely no need, in my opinion, to starve into refactoring until perfect code is reached. There is no need of perfect code (don't get me wrong, it helps but it must not demand too much time).

bst rgrds!

Thanks.

I am programmer with degree in computer science. Mostly projects was planned top-down and implemented bottom-up. Not so far I found new discipline of TDD and curious about it.

After several years of trying to use it properly I fall back to my method of development. Too tough to make tests before you understand what you want to (and how to) implement.

Refactoring is good technique, but with flaws also.