About a year ago, I was introduced to Zend Framework as the framework I was going to be working with almost every day. And for nearly a year now, every day I have worked closely with Zend Framework, learning it’s intricacies and dealing with its warts. I sat down in March of last year and wrote a case study about learning Zend Framework. A year after adopting it seemed like a good time to reevaluate the framework and reflect.
Learning Zend Framework was a daunting, challenging experience that tested myself and those I worked with. I learned a few lessons that I think are important, and I think are worth sharing.
In November of 2009, I wrote about why developers should write their own frameworks. I pointed out at the time that often developing a framework forces developers to make the kinds of architectural choices that frameworks require, which helps them better understand the architectural choices in the most popular frameworks.
I haven’t stopped believing in the power of doing as a learning tool. But in the past few months I’ve had an opportunity to move into more of an understanding of frameworks like Zend Framework, and I’ve come to another realization:
Recently I’ve been immersed into a Zend Framework project in a way that I’ve never been immersed before. This immersion experience has brought out a few thoughts and lessons that I’ve learned through the process about how to get into a framework, how to start a new project using a framework you’ve never used before, and the best way to learn without losing your sanity. Here are my findings.
Don’t fight the framework.
Various frameworks out there have varying degrees of integration with one another. While an argument can be made as to whether or not tightly integrated frameworks are better or worse than loosely integrated frameworks, when starting a new framework it’s best to accept it lock, stock and barrel (in other words, accept it completely).