PHP フレームワーク作りのポイント
 プログラム

　PHPにはいろんなフレームワークがあって、その中のどれが一般的！というのはたぶん、あまり決まっていない。たくさんあるし、どれも長所と短所がある。選ぶのが難しい。
「別にフレームワークなんかいらない」というのも一つの選択肢だし（そしてそれがけっこう採用されている）、フレームワーク自作！というのもいいだろう。

　個人的な現状での結論は、フルスクラッチだ。なぜなら、既存のモノを選ぶと高級すぎるから。できるだけ機能の少ないフレームワークをまず作る。
　PHPで仕事をする以上、PHPの技術者が集まってるはずで。しかし標準的なフレームワークは決まっていないから、みんな共通で知っているのはネイティブPHPだけなんである。そんな状況で、フレームワーク独自の記法とか、大量のライブラリのAPIをみんなに読んでもらうとか、そんなことは現実的じゃない。
　誰もが知っているフレームワークとかが、あるなら考えるけど。Zend Frameworkとかがそういうものになってくのかもしれないけど。あれはそんなに悪くなさそうとは思うんだけど、なんか好きじゃない(笑)。

　個人的な意見ですよあくまで。経験も浅いし。
　経験十年！なんて人たちの意見と食い違っていることもあると思いますが。そのときは、どれが説得力あるか判断するのは読者諸氏です。

　フレームワークを選ぶ/改造するときは、次にあげるような基準で考えるといい。と思う。または、自作するときは次のような機能を作る。

　まず一番大切なこと。

• グローバルスコープを使わない
  　あまりにあたりまえのことだ。変数だろうと関数だろうと、グローバルにはなにも置いてはならない。置いていいのはクラス定義だけ。
  　定数も同じだ。define文はできる限り使わないようにする。
  　グローバルをひとつでも使うと、そこから汚染が拡がっていくことになる。できる限り早い段階で撲滅しておきたい。
  　選んだフレームワークやライブラリがグローバルを使っているならしかたないけど。それ以外では、絶対に使わないようにしなければいけない。
  　ただ、これをフレームワークの選定基準にしてしまうと、けっこうな数が落第になってしまうわけだが(笑)。
  

• ネイティブPHPを活かす
  　フレームワークを使う以上、本当なら、できるだけフレームワークが用意したモノを使うべきだ。と思う。
  　でもたとえば「Util::dateFormat()」という関数があったとき。それはPHP標準のdate()関数じゃダメなのか？
  　そもそも日付の整形処理を書くときに、このUtil::dateFormat()を、APIリファレンスの中から発見できるのだろうか？　開発メンバー全員が？
  　はっきりいってムリ。
  　本当なら、たとえまったく同じ機能だとしても、ラップしてあることには意味がある。本当なら、採用したフレームワークが用意したモノをできるだけ使うべきなんだけど。現実的にムリなんだからしかたない。
  　フレームワークにはたいてい、いろんなライブラリが付属している。なぜなら、そうしておけば「これもできます！」といえるから。
  　客寄せのためなんである。
  　というか一般に「あれもこれもできます！」系のものでないと、選ばれないんである。残念なことに。
  　だから、有名な奴はたいてい、過剰だ。
  　わたし自身はわりと、リファレンスを必死で読むほうだ。でもしょうじきなところ、いつも徒労感がある。いっそのこと、それらを使わないことにしてしまっていい。
  

• 配列を使わない
  　フレームワークには、たとえばO-Rマッピング用のライブラリとかがついているかもしれない。でも、それを使う前にちょっと待とう。find()メソッドが、２次元の連想配列を返していないだろうか？
  　そうなっていたら、その部分は自作したほうがいい。連想配列ではなく、データを格納するためにはオブジェクトを使うべきだ。
  　たとえ全部publicメンバだったとしても、オブジェクト指向には、クラスで宣言していないメンバを追加したくないインセンティブが働く。いっぽう連想配列は、あとから勝手にいろいろ追加されてしまう。
  「基本型への固執」（『リファクタリング』）は本当に、最悪の病理だ。汚染はあっという間に拡がる。PHPは特に。
  　アクティブレコードにするかどうかはなんでもいいけど、とにかく連想配列は撲滅しておいたほうがいい。
  

• 高級なファクトリー機構は使わない
  　フレームワークが、オブジェクトを生成するためのファクトリー機構を用意しているかもしれない。
  　名前を文字列で渡すと対応するオブジェクトが作られるとか（……まあ、こんなアホな仕組みをなぜ作っちゃうのか知らないけど）。
  　実際のところ、よほどよくできたメンバーが集まっていない限り、そういうのは結果的に無視されることになる。みんなわりと、newと書きたがる。
  　本当にnewと書かせたくないのなら、newできない仕組みを組みこまなければならないだろう。
  

　あとは、たぶん自作じゃないと組みこまれていないけど必要なからくりを作る。

• 本番環境用と開発環境用、二つの設定ファイル置き場（ディレクトリ）を作る
  　本番環境用の設定行をコメントアウトしてその下に開発環境用の設定を書くとか、なんであえてそんなリスクを犯すの？という話だ。
  　はじめから分けておき、$_SERVERかなにかを見て、自動的にディレクトリを差し替える仕組みを作っておく。
  

• 設定ファイルは細かく分ける
  　何百行もある設定ファイルとか。管理できると思うほうがどうかしてる。
  　そういうのはすぐに「使わなくなったけど怖くて消せない設定」が溜まっていくことになる。
  　DB用ならDB用と、できる限り細かく分割する。そうすれば、影響範囲が特定しやすいから、あとで不要になったときに消せる。いややっぱり怖くて消せないかもしれないけど、可能性があるだけマシ。
  　もちろん、グローバルスコープも定数も使わない。static変数またはクラス定数だけを書いたクラスになるだろう。ほんとにconst１行しか書いてないクラスとかでいいから、細かく細かく分けるべき。いくら細かくしても、あとでどうせ勝手に追加されて大きくなっていくんだし。
  　.iniファイルとかXMLとかでもいいけど、あまり高級なものをつかうと、不具合が出たときに疑う対象が増えてしまう。かえって手間になる。コアな部分ほどシンプルな実装を採用したほうがいいと思う。
  　高級なフレームワークを敬遠する理由は、そういうところにもある。
  

• テストコード置き場を作る
  　リリース用のファイルとテストコードが同じ場所に混在しているとか、それこそ管理できるはずがない。
  　リリースのときには消さなきゃならないわけだから、プロジェクトリーダーにとっては、そういうのも管理対象に含まれているんである。
  　というわけで、テストコード専用のディレクトリをはじめから作っておく。
  　とはいえ、置き場を作ったとしても、そこを使ってくれるのは理解のある少数だけかもしれない。それがしょうじきなところだ。だけどそれでも、ないよりはマシなのだ。
  

• バックアップのとりかたを考えておく
  　ソースのバックアップはできるだけ毎日とる。
  　これはあとで戻せるようにするためじゃなくて「いつでも戻せるから」と宣言するため。ソース中にコメントアウトを残すとか、そういう愚かな行為をさせないためにバックアップをとるんである。
  　SVNを使うとか、いろいろやれることはあると思う。
  

　ようするに、開発メンバーはつねに予想以上にフリーダムだ。でも、それでもプロジェクトリーダーは管理しなければならない。開発前に手間を減らす工夫をしておかなければ大変なことになる。
　有名なフレームワークをダウンロードしてきて使うのは、もちろんいい。けど、それで手間が増えてしまうくらいなら、簡単なものを自作したほうがいい。
　けっこう、できの悪いフレームワークがあったりするし。
　機能を限定したライブラリじゃなくてフレームワークの開発ばかりが盛んなところが、PHPの現状をよくあらわしている。つまり、けっきょくどう使っていいのかが決まっていないんである。
　いわゆるアーキテクトたちにとっては、腕の見せどころ！といえなくもない。
　じつは、そこらのJavaだの.NETだのの開発よりもよほど、高い技術力を持ったアーキテクトの存在を必要としてる。
　しかし、PHPはどうもバカにされる言語なので。技術力に見あう報酬は約束できませんがねー。