車輪の再発明を防ぐポイント！

プログラマは制限されてラクになる！

　よく「自由」はすばらしいと言いますが、こと開発に限っては、制約があった方がラクな場合があります。個々人の自由度を下げて制約を作ることで、共通の認識を促進したりソースコードを追う上でも重要な役割を果たします。

　フレームワークも同様に、いわゆるお手製スクリプトのみで構築されている場合だと、「どういった規則で命名がなされているか？」「モジュールの粒度は？」「ディレクトリ構成は？」「設定箇所は？」と大小さまざまですが、把握する分量が増えていくことになり、非常に非効率です。

　これは筆者の経験ですが、symfonyを利用して初期開発を行い、他の方へ引き継ぎを行った際には非常にスムーズに引き継げた経験があります。これはフレームワークを利用すれば、豊富なドキュメントから命名規則や粒度、設定箇所など、どのプロジェクトでもある程度共通な部分が揃っており、引き継ぎの手間や変更を伝えたりするなどの、アナログな分野で非常に役立ってくれるはずです。

　それだけにとどまらず、社内で共通のフレームワークのノウハウを共有していけば、今後フレームワークを利用した開発を行う際にも、非常にスムーズに進むことでしょう。

PHP 4から5へ

　第3回でCakePHPを除いたsymfonyとZend Frameworkの2つのフレームワークは、PHP 5専用であることを紹介しました。2007年7月13日に「PHP: Hypertext Preprocessor（www.php.net）」で発表された通り、PHP 4の開発は重要なセキュリティフィックスがない限り打ち切られることとなりました。またセキュリティフィックスについても、2008年8月8日を持って終了する運びとなり、今後はPHP 5（またはPHP 6）を利用して開発が進むことになると思います。

　このことからも、今後新たなフレームワークが登場する場合には、恐らくPHP 5専用が大半になっていくのではないかと予想しています。

　現状PHP 4で動作しているフレームワークを利用している場合は、セキュリティパッチを独自に開発して継続利用することも1つです。しかし、当初はPHP 4に比べて動作速度が遅いと言われたPHP 5が、最近では徐々に速度も改善されており、今後新規開発する案件については、PHP 5の機能を活用したフレームワークを利用していくのが最適解になるのではないかと思っています。