Hi, Jim.

>RETRACTION: Article correct on refactoring, my reading was wrong!
>
>Martin and Ken,
>
>With the additional background provided by both of you I see now that I was overly literal in my interpretation of the article. I MISconstrued it to be saying that it is perfectly justifiable to rewrite (the original of the new-fangled "refactor") any code you dislike, the "Agile" principle giving one open license to do so.
>
>I am pleased to now understand that it is a decision to only be taken for good (and non-personal) reasons to improve the application's design, performance, reliability, maintainability or readability. The last one specifically should have nothing to do with personal preferences.

I'm really glad that you get the point and reconsidered the technique as worthwile -at least worth the try. In any case, as I said before, it is comforting to get someone debating over one's wotk, because this is though provoking and also a signal that we -at least- made some noise! 8-)

How frequently you apply reactoring is a matter of methodology. You may take your aproach of having Refactoring at hand when you "smell" something rotten around. Indeed, the ideal thing at first is to have Fowler's book handy, then say: "Hmmmm... this stinks to an overly large class. How could be the best refactoring approach?", and then you can go to the book, search for "Long Class smell" on the last two pages (this is a great index), and see the list of common refactorings associated with that smell (including the page number beside each). Then you may take a look at the different alternatives or just get the obviously better solution. Now you jump to the page, and follow the simple procedures (most refactorings take just a 2/3 pages). Then you can figure out how to write your tests, run them to ensure that the original code is actually working (this in itself ALONE could be an englihtening experience), and then follow the discrete steps of the standardize procedure, running the test on each step until you come to your cleaner implementation.

I know! This sounds like a painful process! But it really isn't, and you quickly get familiar with the mechanics and you don't need the book anymore. And of course, I don't recommend (neither Fowler does it) to take everything in he book for granted. But it is a very good starting point.

Next in the article series I'll explain more about unit testing in general and talk about some tools to help with that, and then I'll devote a separate article to Test-Driven Development, wich is a more radical methodology that uses Unit Testing and Refactoring as CONSTANT steps in the development process. Be prepared because the idea is even more difficult to digest at first, but once you think about it, and if you try it, you'll quickly realize its potential.

Sorry for not entering in more detail here, but I don't want to move the megazine to the forum. 8-D

Best regards, Jim, and thanks again for being a careful reader,