Ah, so you do it to learn the program at hand.

Aren't you really saying that you prefer to "learn" a program that way than to read the code carefully?... and probably because the coding style of the original is not to your liking?

Your "refactoring" and testing in little bits is a reasonable strategy, but you've surely got to agree that this method results in much longer development time than simply learning the existing code and changing as needed.
And testing little bits at a time works nicely for the program at hand, but what about the application in its entireity?... a thorough system test? Are those charged with that duty even aware that you've chose to re-write a whole bunch of code? I bet that often goes unnoticed.

I still see this as being done FOR YOUR PERSONAL CONVENIENCE, to the detriment of the client and the project as a whole. And worst of all, of course, is that the next guy having to work on the same code ALSO "refactors" it to learn it and to get it into his style! Since when has the price of fixing/enhancing an application included rewrites of all those components that need attention?!?!?

This buzzword - agile - essentially justifies an activity that has no business being justified except in extreme circumstances. We'll kill our business if we continue to let things like this become the norm.




>I don't agree with you here. I've refactored lots of applications that functioned just fine, but I had to grasp the interals of what it was doing (as is typical, the apps weren't documented well or not at all). By refactoring, I was able to do that. I also found areas that got performance improvements by doing so. Was it dangerous to do this? Yup, it was, but by following Martin Fowler's recommendations of only changing little bits at a time and then testing, you can avoid problems.
>
>
>>I've followed the "Agile series" articles by MartinS in the UT magazine.
>>
>>The most recent article has the statement "The Agile idea is that code should be kept as clean and flexible as possible, and then, each time that corruption starts to happen - and it happens very frequently if you're not very attentive - you have to improve it. And always remember that Refactoring means improving the code that already works, not fixing any function. ".
>>In essence the current article, as well as its predecessor, constitute a license to change any code that you don't like and I think this is absolutely wrong-headed!
>>
>>What is preached in these articles certainly is a programmer's dream, but it is my contention that it really is a project manager's nightmare.
>>
>>Except in extreme circumstances it is never (repeat: NEVER) sensible or practical to "refactor" running production code. Never!!! The "extreme circumstances" would only include very poorly written code that is extremely difficult to amend for the purpose of either fixing a bug or adding some enhancement.
>>
>>In the near universal case of an adequately written (coded) application any bug fixing or enhancement addition is best done by amendments within the existing code. Of course new methods/functions/form/reports/etc can be introduced in such situations.
>>
>>With an adequately coded application "refactoring" can only buy you trouble with a capital "T".
>>The "decision" to "refactor" brings with it necessity to perform much more stringent unit testing as well as absolutely thorough system testing. I contend that in most cases the refactoring programmer will not develop the required unit tests to adequately prove the new code. Confidence that the new code is functionally equivalent to the old code will result in minimum testing rather than complete testing.
>>Refactoring for the sake of refactoring results in either extended development time or extended test time, and neither is good from the client's perspective.
>>
>>Of course the temptation to "refactor" is great. Virtually any code done by someone else is difficult to work with. We all have our personal foibles when it comes to coding "style". And there can be no doubt that rewriting code is a legitimate way to learn just what the code is doing.
>>But the functionality of code *can* be learned by carefully reading the code too. Sure, this may be more difficult to do if the code at hand uses lots of multi-compounded IF statements that you detest, but it is totally unreasonable to rewrite code simply because it aggravates you personal sensibilities. After all, why wouldn't the next person charged with fixing/enhancing the same code not also feel the need to refactor because of his distaste of your style?????
>>
>>To me this blessing of refactoring - which really is on a willy-nilly for-whatever-reason basis - is a delight for programmers who love to code and feel that their own coding style is the only good one, but it is very bad medicine for delivering anything on time and within a reasonable budget. It is a rare case indeed where you will be the first and only programmer of an application, so you will be much better off developing the skill of reading other people's code with a view to amending it rather than reproducing it in your own style.
>>
>>Comments?