| || || |
| || |
| || || |
The book starts out with an awesome quote by Donald Knuth:
Programs are meant to be read by humans and only incidentally for computers to execute. (Page 14 of 360)
I absolutely love this perspective! Too often, we as developers worry about micro-optimizations where readability is placed second to the shaving-off of milliseconds of execution time. But, as Zakas points out, 80% of the lifetime of software goes towards its maintenance. Making sure that we have clear, consistent, readable, decoupled code is an investment that is critical to the long-term success of a project. As such, it is no wonder that the first third of the book goes into defining and discussing all aspects of code formatting. This includes everything from commenting, to white-space, to loops, to property look-ups, to comparison operators, and to when its considered appropriate to use NULL values.
The second 3rd of the book is about Programming "best practices." This is the part of the book that I was initially hoping to find. And, as much as this section did have some really great insights, it was definitely more focused on high-level and language-specific best practices than it was on actual application architecture. For example, Zakas talks about how Event objects should not be passed around in order to avoid ambiguous APIs; but, he doesn't go into much detail about how a user interface (UI) widget (which handles events) should communicate with the application in which it is being used.
As I reflect on this section, I am realizing that there is actually a lot of gold here. Zakas makes me think about things that I hadn't really considered before. I guess I just wanted a little more hand-holding with tying all of the concepts together in a single application. I suppose that's where I am currently feeling the most pain in my understanding of programming.
The last 3rd of the book, which felt like the bulk of the book, dealt with Automation: testing, building, compressing, compiling, and deploying. A lot of this talks about Ant and about all of the automation tasks can be done inside of Ant. Zakas also demonstrates a custom Ant library that he built - Buildr - which simplifies many of the Ant tasks that we'd want to run when automating a project's lifecycle.
I've never used Ant (or any kind of automation) before; so, this section felt a bit foreign to me. That said, since I've never used Ant, this is probably the most valuable section of the book for me personally. As I was reading, I was definitely having a strong emotional reaction to the fact that this felt so "meta" to any of my current programming problems; but, in hindsight, this kind of automation is a huge gap in my software development workflow and is something that I should really start to take more seriously.
Right now, I feel like I have a fairly good understanding of the languages that I use; but, I definitely feel shaky when it comes to building complex, modular, decoupled applications. As such, I was hoping this book went into more depth in terms of actual architecture. When it didn't, I think I started to get distracted by my own emotional reaction and insecurities. This prevented me from seeing and appreciating all of the great information that Zakas discusses. In hindsight, I can see there was a lot of value that I failed to absorb properly. Understanding the goal of the book, I need to go back and read it again so I that I can really internalize all of the knowledge Zakas was laying down.
Looking For A New Job?
- IT Manager - ColdFusion/SQL web application developer at ARELLO
- DevOps Engineer at Linode
- Software Engineer at Linode
- Web Applications Developer (Remote / Telecommute) at SiteVision, Inc.
Ben, thanks for the review, I look forward to reading this book.
Excellent - hope you like it!
Might give this book a crack, love the quote and it's so true!
Definitely; and for me, it's a reminder that I *have* to start looking into this stuff.
Another quote I really liked at the beginning of Part II was:
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way way is to make it so complicated that there are no obvious deficiencies." - C.A.R. Hoare, The 1980 ACM Turning Award Lecture (Page 96 of 360)
Thank you for this review. Maintainable JS is on my reading shelf, so I was very interested by your post.
It was the first time I had really read anything in-depth about Backbone.js or Spine.js. Now that you mention it, I should probably go back and re-read it. There so much freaking information out there and there's only so much my brain can absorb at a time. Unfortunately, this requires a sort of iterative approach on learning :)
Speaking of iterative reading, I'm thinking of looking at Head First Object Oriented Analysis & Design... which I don't think I've read (I might be confusing it with Head First Design Patterns or Head First Java).
Brain hurt :D