tilllate.com is now all Zend Framework.
We made it! Last Friday we have replaced the last two legacy components with their Zend Framework based counterpart: The gallery an the user registration. The whole site tilllate.com is now running on Trevi, our extension of Zend Framework. With a reach of 2.5 million unique clients a month, tilllate.com is one of the world’s biggest installation of Zend Framework.
Ciprian, Ivan, Jia-Yong, Kevin, Leo, Riv, Roger, Sanja, Thilo, Vanja, Vladimir and project manager Maarten have done a wonderful job reverse engineering the old, smelly spaghetti code and refactoring everything in a clean and solid MVC architecture: 115’480 Lines of code (Thanks StatSVN).
Custom DB layer
The first components of the refactored code have been released in December 2007. We observed the code to be much easier to maintain due to its good, DRY structure. We were really impressed by the flexibility and modular structure of the Zend Framwork. Some stuff does really look complicated in ZF (and sometimes it is), but through the flexibility it was really easy to replace components we did not like (or which were too slow).
We used specially the Zend MVC components. For performance and flexibility reason we wrote our own very light weight database layer. For configuration we used plain php files and Zend_Config which we extended only a little. We did use the Zend_Cache layer with memcached to cache our queries. For mailing we used eZ Mail.
Memoization for performance
Often it was very easy to hook components in or extend stuff in an easy, flexible and object-oriented manner. We extended some stuff in Zend_Router and Zend MVC to make it more suitable for our needs. After profiling we also extended some functions with Memoization which specially get Zend_Date and Zend_Config a big performance boost. As the P in the LAMP stack scales pretty good, we did not a lot other performance optimization there. So far there was only one php function we did cache because of speed reason.
Software defects decreased partially due to consistent use of unit tests. We have a quick bug detection thanks to a consistent exception handling and a ActiveMQ based logging infrastructure. But most of all, the code performs much better than the spaghetti version. This is due a systematic use of caching with memcache. The number of queries needed per page have been reduced by 80%.
Keeping up the quality
So far, I am very happy with the outcome. But some questions still remain: How much more productive is our development team now with this better quality code? How will the code look in five years from now? How can we avoid it to become smelly like the year 2000 dated spaghetti code?
Congratulations! Deserves a lot of credits – 120k LOC certainly qualifies as a “big rewrite”, which is the type of project that usually fails
Comment by Harry Fuecks — 20. May 2008 @ 14:00
Nice
Congrats and I think that the site itself is really faster than before the rewrite.
Comment by mix — 20. May 2008 @ 14:16
Very cool! Congratulations and thanks for telling the story of how you used Zend Framework.
Comment by Andi Gutmans — 20. May 2008 @ 17:05
Congrats! I’ve been using ZF at work and for side projects for about 1 year now, and it seems to be a great fit for projects which don’t fit the “standard patterns” provided by other frameworks. This might be ignorance on my part, but being that the first 5 projects I did with ZF didn’t *have* a database (I know, how is that even possible?) a lot of the power of other frameworks was wasted on me.
I do have a question regarding user management / user registration. One of the things I *loathe* the most in the world is writing “yet another user management / registration system”. Is there any chance that you guys would ever release your user management / registration system as a Zend Module or simply open source? I dream of a day where that’s a “component I drop in.”
Comment by eduardo — 20. May 2008 @ 17:54
so you guys tripled your code size from 40K LOC in Dec 2007 to 120K LOC in May 2008? is this a good thing?
Steve Yegge says, “the worst thing that can happen to a code base is size.”
http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html
Comment by dv — 20. May 2008 @ 21:16
Thanks for all the congratulations!
@Eduardo: Our registration and user management is still very product specific. So the chance are very low that we go to publish it (if we would, it would be more or less usless for you).
But it’s not a lot of magic here. We use Zend_ACL, Zend_Auth, a mysql table for storing the user and Sharedance for the session (we’d like to get ride of the later, because of bad scalling). If you build new sites you should probably look at OpenId, which can help even if you don’t need the full functionality.
Comment by leo — 21. May 2008 @ 10:10
Mal ne doofe frage…
Managed ihr die short-url’s via mod-rewrite oder handled ihr das im php mit request_uri und dergleichen?!
Comment by Chriss — 2. July 2008 @ 12:01
Not sure how I missed this the first time around, but congrats from the ZF team on the full rewrite. Now, not to sound like a broken record, but about that giving back thing. . .
,Wil
Comment by Wil Sinclair — 2. July 2008 @ 12:04
@Chriss: Nur doofe Antworten, keine doofen Fragen. Die Antwort ist beides. Wir leiten alle “neuen” URL an den Bootstrap weiter und dieser “leitet” sie mit dem Zend_Router an den Richtigen Controller weiter.
@Wil: Thanks! A lot of our own components are just highly coupled with our requirements and infrastructure so the might hardly be usable for others. But we hope to release some of our more generic stuff (it’s I time thing, nothing else) and as soon as we migrated to 1.5 I think I will sumit some bugreports (this time with fixes). Thanks for all of the ZF Team. It’s great work!
Comment by leo — 8. July 2008 @ 11:09