I consider it is almost impossible to give perfect names on the first shoot, so there are few option available, make it "on the fly" as soon as you see it might be good, but it cuts the 'building/make it work stuff' momentum, and i feel i dont get enough global view for take the good refactoring decisions,<p>Right now i try to take one full day of work each week only refactoring, good habit?<p>Maybe i will try do it everyday before continue work, refreshing yersterday code by refactoring seems good idea,<p>When and how do you refactor your code?
One full day a week is a great start, we had "refactor fridays" at one of my previous jobs.<p>I'd say for me, its when I can see that I can make something more efficient or spot obvious mistakes or slipshod code. So it could be once a week, once a day, once an hour.. or months later when I come back to something and see that I could approach it differently.<p>Regardless, I like where your thought process is going on this, that you're always looking to make your code a bit better whenever you can. :)
When? The second time I start typing almost the same thing.<p>If I <i>anticipate</i> typing the same thing again I'll prefactor and head it off at the past.<p>If you can get official refactoring time that's great; I've only worked at one place where we had official refactoring time built into our sprints, which can be frustrating.<p>"How" is impossible to answer in a general way other than restating all the usual refactoring patterns.
My trigger is when I realize that I'm trying to avoid working on/with
a particular subsystem (usually because it feels brittle or complicated or
difficult).