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?