in reply to Re: reworking a large program
in thread reworking a large program
I am a huge proponent of refactoring code (and do so constantly), but Fowler gets too much credit, IMHO, for spearheading the effort.
One of the scarier attributes of Fowler's style (and his disciples) is to decompose methods until they are as small as possible. What was the stat? Methods averaging 2-4 lines of code average? That's rather inefficient due to system-call overhead and can often go too far. I think that also makes debugging rough. Depending on the method, 2-4 may be just right, but this is not to say 10 lines is overkill.
His disciple, for instance, had a holy war against using the "if" statement, and wrote entire programs using trinaries and anonymous inner classes to avoid the if. Ack! Run away!
I haven't read the book, but his 2 hours of lecture (which had the goal of selling the book) kept me from having any interest in the book (or at least paying for the dead trees). I'm very much into clean OO, but Fowler takes clean and somehow makes it feel dirty.
The above post by saberwolf pretty much sums up my opinion of the lecture. It was like a lecture coding for people that should have never been coders.
Aside: My favorite engineering professor ever (not C.S., but that doesn't matter), once had a very interesting "how people learn" lecture, where he stipulated that C.S. folks, more so than other engineers, tend to think globally rather than iteratively. It's sort of this "a ha!" process rather than something mathematical like a proof. This kind of thinking makes us good at what we do (analyzing huge systems without getting bogged down by details), and to me, I can't learn from Fowler's iterative mechanical steps. Give me basic concepts, no instructions, and I like bullet points and lots of pictures. Thanks, Dr. Porter :)
|
|---|