Brian van den Broek wrote:
<SNIP>
I had been thinking better to get everything working and then refactor. Is that an unsound approach? My worry about refactoring now is that I feel like I am rearranging deck-chairs when I should be worried about getting the ship to float :-)
It's a hard question because it really comes down to programming style and judgement.
I like to work in a very incremental style - design a little, code a little, test a little, repeat as needed. I believe in 'Refactor Mercilessly' - another XP slogan. I have many years experience and a well-developed opinion of what is good design and bad design.
One consequence of this style is, I usually have working code and tests to go with it. It may not do very much, but it works.
So for me, if I smell something, and think that refactoring into subclasses - or some other change - is the best design for the problem as I understand it, I will probably do the refactoring. It's not going to be easier tomorrow :-) If it just smells a little, or the refactoring is major, I might think about how to get rid of the smell but put it off until I'm pretty sure it is a good idea.
I don't think of this as rearranging the deck chairs - it's more like building the right foundation. Clean, expressive, well-designed code is a pleasure to work with.
For you, it's probably not so cut-and-dried. If you don't have the experience to judge how bad a smell is, or to think through the possibilities so clearly, it's harder to know how to proceed. If you are in part dabbling with OOP design to learn about it, maybe you want to put off some changes until the code is working; then you could make the change and do a comparison and see which one feels cleaner to you.
I hope this helps at least a little :-)
Kent
Hi Kent,
I see my `strike that' msg. didn't get through in time, to save you from the reply. But, from the selfish perspective, I'm glad enough about that; the above does indeed help more than a little.
I get, in the abstract at least, how Test Driven Development would make these refactorings much easier to do with confidence. (Somewhere near half the point, isn't it?) The goal of my current project, beyond the given of having useful code, is to write a medium sized project in OOP. At the outset, I felt I had to choose between getting a handle on OOP or TDD. I felt I could only tackle one new paradigm at a time. I went with OOP as I didn't want to spend the effort of getting procedural code down using TDD and then have to redo it in OOP. But, not having test does make the refactoring more scary than I imagine it would be tests in hand.
And I would have had the need to redo it, I think. The file format I am working with is from an application I've been using as a PIM/Knowledge manager for several years. So, I've got tons of data and tons of plans. I'm not certain if the term is the right one, but I'm thinking of the code I am working on as a base toolset or `framework' for all the other things I want to do with the files of that format. Thus, subclassing and other OOP techniques are sure to be important for those plans.
But, I think you hit it right on the head -- my inexperience with OOP doesn't provide me with any metric for judgement about these things. Browsing through things like Fowler, Beck, Brant, & Opdyke's _Refactoring_, while fun, doesn't help much without my having struggled with my own OOP code first. Hey, yesterday I proved that having read about setattr numerous times is no guarantee I'll remember it the first time a use case comes up :-)
Thanks for the continued efforts to help me `get' it. Best to all,
Brian vdB
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
