On Wednesday 14 December 2005 11:24 am, Jacob F. wrote:
Hence the need for continuous refactoring. If that’s not taking
place, it management’s and/or the developers’ fault, not the
break statement’s.
It’s definitely not the break statement’s fault. It might not be the
developer’s or management’s either. It might be the fault of the
marketplace, which in turn is nobody’s fault – it is what it is.
If taking the time to understand the code, in preparation for
refactoring, will cause a loss of customers, refactoring can wait
(and unfortunately usually waits until a clean rewrite).
That being said, I’ve always tried to refactor when possible. A lot
of times management doesn’t even know – you just rewrite
problematic parts.
By the way, how do you like often maintained, never refactored code
where they have three different variables representing essentially
the same thing, and you need to decide which one to use and which
one to set?
SteveT
Steve L.
[email protected]
On Wed, Dec 14, 2005 at 10:36:50AM +0900, James Edward G. II wrote:
I’ve got two words for you: Unit tests. They were invented to
address every single issue you just listed (plus some!) and I assure
you, they work. You really, really should give them a try. It will
be the best gift you ever give yourself, I promise.
It’s certainly good policy to use unit tests. On the other hand, coding
in a manner that is in any way less easy to maintain because you know
that the way you write code will ensure that the problem is taken care
of doesn’t address the issue of what happens if someone else, with less
ingrained good habits, comes along and takes over.
Um. I’m not entirely certain that was coherent.
–
Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]
unix virus: If you’re using a unixlike OS, please forward
this to 20 others and erase your system partition.
On 12/14/05, Steve L. [email protected] wrote:
If taking the time to understand the code, in preparation for
refactoring, will cause a loss of customers, refactoring can wait
(and unfortunately usually waits until a clean rewrite).
That’s unfortunate if you feel that you’re in that position (and I can
sympathize, I’ve been there).
In my mind, refactoring is part of code maintenance. When you need
to fix a bug or add functionality, watch for opportunities to
refactor. Refactoring is part of writing the new code, not something
that’s applied after the new code is added.
If you’re understanding of the code insufficient to make necessary
refactorings while making the change, your understanding of the code
is insufficient to be making the change in the first place.
That being said, I’ve always tried to refactor when possible. A lot
of times management doesn’t even know – you just rewrite
problematic parts.
Exactly.
By the way, how do you like often maintained, never refactored code
where they have three different variables representing essentially
the same thing, and you need to decide which one to use and which
one to set?
I assume that’s a rhetorical question… 
Jacob F.
P.S. Thanks for the discussion; I don’t mean to be attacking you or
your practices, just evangelizing.