Re: reworking a large program

Replies are listed 'Best First'.
Re: Re: reworking a large program by flyingmoose (Priest) on Feb 09, 2004 at 21:18 UTC
I find Fowler's process to be highly-mechanized. I took some courses that were sub'bed for a few weeks by one of his fellow disciples (hardcore into eXtreme Programming too), and have been to one of Fowler's guest lectures. It seemed rather obvious, but also mechanical in a bad way. He tends to propose doing things very incrementally, and uses the compiler too often to double check that his code is valid. He doesn't state general concepts insofar as much as he wants to shorten L.O.C. 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 :)	[reply]
Re: Re: reworking a large program by saberworks (Curate) on Feb 09, 2004 at 21:05 UTC
I have just finished reading this book. I bought it because I have just inherited a mountain of shoddy perl code and I was hoping it could help. I found it to be the biggest waste of my time ever. The author has a tendency to "talk down" to the reader, and furthermore, spends most of his time bragging about himself and his friends. I found the writing style to be very annoying. Once I got past that and into the "meat" of his "refactorings," it seemed like all he wanted to do was place labels on things that are (or should be?) common sense. He refers quite a bit to various "patterns" which of course can be found in other books. It seems like he wants his "refactorings" to be remembered as people remember the patters from these other books. Unfortunately, while I did find a lot of the patterns useful (or at least interesting), none of his refactorings seemed to have any basis in reality, or if they did, they were so blatantly obvious that it seems pointless to devote 6 pages to it. For example, many of his refactorings are things like "move method" or "move field" - and of course he spends pages and pages discussing how to move a method. COME ON. Of course there are probably a few meaningful and useful things in this book. His insistence that you edit in small steps and test regularly to make sure things keep working is of course a great thing to do. I think something more useful would be to think of how you would design the program if you were starting from scratch. Thus, read up on program design and separation of business logic from presentation and object design and what have you. Once you have an idea of how you would program it were you to start from scratch, start examining what you have so far and think of what small steps you could take to bring your current "design" in line with your ideal design.	[reply]
Re: Re: reworking a large program by Art_XIV (Hermit) on Feb 09, 2004 at 20:50 UTC
Ditto to Fletch. There is also a nice article from Perl.com here. Hanlon's Razor - "Never attribute to malice that which can be adequately explained by stupidity"	[reply]
Re: Re: Re: reworking a large program by gri6507 (Deacon) on Feb 10, 2004 at 12:54 UTC
This article seems very useful. Moveover, the concept of Refactoring is quite novel, but I'd think its usefulness decreases with the size of the program while the time spent on refactoring increases, in, what I would guess, an exponencial manner.	[reply]