- 締切済み
PHPのレガシーな設計について
あるお仕事でフレームワークを使えないという状況に陥っております。 月々数千円のホスティングサーバーでの運用になるのですが、今となってはレガシーなSmarty+Pearの組み合わせでの設計を指定されています。 PHPバージョンは5.3です。ホスティングなので変えられません。 CakeやFuelがそのホスティングで使用できるかはテストしないと分からない状況です。 過去の遺産でSmarty+Pearのコードはいろいろあるのですが、DBの接続もPear::MDB2を使っていたりといまいちです。PDO使いたいけどいちいち書き換えが面倒・・。 また、ホスティングなので気まぐれに5.4や5.5などに上げられると、レガシーな設計だと動作が心配です。 どうのように思われますでしょうか。識者の方からのご意見をお待ちしてます。
- みんなの回答 (2)
- 専門家の回答
みんなの回答
- shockatz
- ベストアンサー率80% (153/191)
レガシー php 指定での開発案件? 私の所でも、大手 SIer がらみの php 案件は全部それですわwww これがjavaとかc#、RoRですと、全部 MVC フレームワークになるんですが、何で php だけ? と思うのですが、やはりフレームワーク自身の安定性や成長性、バージョン変更時のコード互換性など、言われてみれば思いあたるフシもあります。 CakePHP や FuelPHP はコミュニティが活発なのは日本だけ、Laravel など海外の有名フレームワークは日本で全然実績がないとか、継続性を指摘されることが多いです。 でもまあ、発注者の立場ですと、納品されたコードを部分的に保守するのが仕事なので、思い切りスキルの低いチームでも対応できるように、という事は理解できます。 いっそのこと(当社のように)普段の開発がフレームワーク一色なら、思い切ってレガシー php 案件は全部社外スタッフに発注されたらいかがですか? 変な話ですが、開発難度の高いはずのレガシー php のほうがずっと容易に人員を調達できますし、請負先のコストだって3割以上低いし。 不条理と言えば不条理な話なんですが、レガシー php に我々が合わせる必要もないのと違います?
- yambejp
- ベストアンサー率51% (3827/7415)
PEARはPHP5.4あたりからSTRICTで運用しようとすると 挙動があやしくなってきていますね ただしPEAR自体は強力なライブラリ群なので、使わない手はないでしょう。 (PHPマニュアルの中でさえPEARを推奨する記載があるくらいですから) またDBの接続については「書き換えが面倒」レベルなら少しがんばって PDOに切り替えた方が今後のことを考えるとベターだと思います 本来SQL自体が環境に左右されにくい仕様なのですから、 接続方法の変更はさほど負担にならないかと思います。 肝心のフレームワークについては利用している方にとっては 使用しないことによる非効率具合は相当なものでしょう。 そればっかりはクライアントにメリットをアピールして説き伏せるしかないですが 逆に導入してしまうとその環境をクライアントに強要することになるので 別の業者が入った時に「こんな使えない環境を利用しやがって」と 同じようなトラブルの原因になりかねません。 クライアントが望むのであればソリッドな環境をベースにするしかないと思います。
お礼
ご意見ありがとうございます。 確かにPEARは大変便利なライブラリですね。これまでいろいろ助けられました。 クライアントを納得させるほどのメリットを語ることが出来ればいいのですが・・。 フレームワークも最初は規約を覚えるのが大変でしたけど、慣れると非常に有効ですね。 クライアントはその規約を理解するコストを嫌がっているようですが。 Cake+Smartyという手で納得してもらおうかとも思ったのですが、それもダメでした。
お礼
放置してました。すみません。 ご意見ありがとうございました。 クライアントの意向に沿った開発というのが大前提ではありますので、今回は仕方なくノンフレームワークでいきます。 しかし、PHPではデファクトとなるフレームワークが定まらないですよね。その辺りもPHPでの受注開発を面倒にしている要因かもしれませんね。 一時Ethna使ってたこともありますが、今はほとんどすたれちゃってますし・・。