I disagree that Patterns of Enterprise Application Architecture is an excellent book. I found it to be poorly written and appallingly edited. (Martin Fowler is capable of much better.) More importantly, the patterns themselves give an impression of coherence and well-understoodness to a space that is in fact incoherent and poorly understood. This results in people thinking and talking more about patterns than about the problems they're actually trying to solve with software. In other words, the whole enterprise (pun intended) is premature optimization at a meta level.
Refactoring is better because it's on a smaller scale and thus able to deliver roughly what it promises.
As far as the enterprise-OO space goes, though, the best book by far IMO is Eric Evans' Domain Driven Design. One reason it's better (apart from being superbly written) is that it's much more exploratory: it doesn't pretend to have figured things out, but rather offers principles you can use to figure things out. Also, the principles, though deep, are easy to understand (as opposed to "enterprise application architecture patterns" which get more confusing the more you try to understand them). In fact, the only weak spots in DDD are the points at which it veers closer to the PEAA approach.
(Disclosure: I worked with Eric for several years. But my high opinion of his book was not caused by this; it was the other way around.)
God don't read anything about patterns or refactoring. That'll sap all of your creativity and cover you in a tight fitting straight jacket. Read a language spec. That gives you the building blocks. Then go away and play with them.
I read the Gang of Four Design Patterns book straight out of college when I had a job as a dev lead at a small lifestyle software startup. Man, I tried to make every problem fit into that mindset.
I'd do things like hand-roll my own XML parser in PHP (never mind LibXML bindings, etc) while trying to make sure I was observing the Visitor and Command patterns, oblivious to the silliness of the situation.
I also missed the understanding of dependency injection (or just management in general) that would have made that hellishly large Flash project so much easier to test and assemble.
Somehow I still managed to get a lot done. I feel in retrospect, that the Design Patterns are good to know about, but I don't know about whether anyone should intend to implement them.
> don't read anything about patterns or refactoring
Actually, I wish I had done so. Then, after dumping it in disgust, I wouldn't have allowed programming to burn my youth, and would perhaps now be in an honest and not yet intellectually-stunted field like chemistry - where cube farms are unknown and the subject has some actual (vs. accidental) depth (see: http://tinyurl.com/lfzb58)
Glad to hear I'm not the only one with a copy of The Pragmatic Programmer on its way to tatters as a result of chronic re-reading; I'd begun to think I wasn't getting out of it what I should be. I likewise recommend it to other programmers, new or otherwise.
I avoided The Passionate Programmer when it was called My Job Went To India, deterred by the title and lack of reader recommendation. Maybe I'll give it a look now. Somewhat related, I found Land The Tech Job You Love to be a comprehensive and insightful resource.
I avoided the first edition too. Dave Thomas' blog post about the new edition is what got me to read it.
I've yet to read Land the Tech Job You Love. I know I should, I just sort of have the tech job I love :-) At any rate, they're both supposed to be very complimentary.
How does one know a great book with out consuming some junk? We learn when we do it wrong up much more often than when do it right. It is not always clear in the beginning that putting business logic in with the view or the data layer code will later be impossibly difficult to untangle. I would suggest read what you want then do what you think is best. It doesn't matter if it is completely correct. (whatever correct is) Some good peer review will keep the bad trouble away, or at least the decision to keep it will be made with the eyes open. Nothing will create a great programmer faster than untangling those darn tangles.
I understand that this is off-topic, but is it really necessary to downvote it to invisibility? It's a silly joke. It costs you two seconds of your life to read it, and none for laughing if you don't find it funny. Just move on.
[+] [-] gruseom|16 years ago|reply
Refactoring is better because it's on a smaller scale and thus able to deliver roughly what it promises.
As far as the enterprise-OO space goes, though, the best book by far IMO is Eric Evans' Domain Driven Design. One reason it's better (apart from being superbly written) is that it's much more exploratory: it doesn't pretend to have figured things out, but rather offers principles you can use to figure things out. Also, the principles, though deep, are easy to understand (as opposed to "enterprise application architecture patterns" which get more confusing the more you try to understand them). In fact, the only weak spots in DDD are the points at which it veers closer to the PEAA approach.
(Disclosure: I worked with Eric for several years. But my high opinion of his book was not caused by this; it was the other way around.)
[+] [-] bumblebird|16 years ago|reply
[+] [-] fizx|16 years ago|reply
I'd do things like hand-roll my own XML parser in PHP (never mind LibXML bindings, etc) while trying to make sure I was observing the Visitor and Command patterns, oblivious to the silliness of the situation.
I also missed the understanding of dependency injection (or just management in general) that would have made that hellishly large Flash project so much easier to test and assemble.
Somehow I still managed to get a lot done. I feel in retrospect, that the Design Patterns are good to know about, but I don't know about whether anyone should intend to implement them.
[+] [-] asciilifeform|16 years ago|reply
Actually, I wish I had done so. Then, after dumping it in disgust, I wouldn't have allowed programming to burn my youth, and would perhaps now be in an honest and not yet intellectually-stunted field like chemistry - where cube farms are unknown and the subject has some actual (vs. accidental) depth (see: http://tinyurl.com/lfzb58)
[+] [-] TrevorBramble|16 years ago|reply
I avoided The Passionate Programmer when it was called My Job Went To India, deterred by the title and lack of reader recommendation. Maybe I'll give it a look now. Somewhat related, I found Land The Tech Job You Love to be a comprehensive and insightful resource.
[+] [-] tswicegood|16 years ago|reply
I've yet to read Land the Tech Job You Love. I know I should, I just sort of have the tech job I love :-) At any rate, they're both supposed to be very complimentary.
[+] [-] tmikew|16 years ago|reply
[+] [-] joblessjunkie|16 years ago|reply
[+] [-] tswicegood|16 years ago|reply
[+] [-] Kirby|16 years ago|reply
Oh, you meant _programming_ books. Never mind!
[+] [-] telemachos|16 years ago|reply
This place can be awfully humorless at times.
[+] [-] unknown|16 years ago|reply
[deleted]