私は、大規模なプロジェクトに PHP を使用すべきではないと人々が述べている (提案も、議論も、提供もされていない) いくつかの投稿を読みました。
主に PHP 開発者として、2 つの質問をします。
私は小さな開発チームを運営しており、経験から、品質の高い構築、組織、ドキュメント、コメント、およびカプセル化が最優先事項であることを知っています。私たちは独自のフレームワークとアプローチを使用して優れたプロジェクトを開発できますが、時間を無駄にしているのであれば、それ以上の投資はしたくありません。
考え？
PHP はプレゼンテーションとロジックを組み合わせたコードを記述できるため、または SQL インジェクションを可能にするため、PHP はひどい言語であると人々が率直に言うのは、私は本当に嫌いです。それは言語とはまったく関係ありません。それは開発者です。
PHP は非常にスケーラブルであることが証明されています。ウィキペディアは、インターネット上で最大かつ最も人気のあるサイトの 1 つであり、PHP を実行しています。十分に言った？
作業用のフレームワークを提供するツール/ライブラリがたくさんあります。これにより、誰かが貧弱で保守性の低いコードを書く可能性が低くなります: CakePHP、Symfony、PDO、Smarty などを参照してください。
参入障壁が非常に低い言語であるため、悪い評判を受けています。無料で、非常に安価な PHP ホスティングを利用できます。ドキュメントは最高であり、オンラインにはたくさんのチュートリアルがあり、さらに多くのことができます。非常に簡単です (例: URL を開いてファイルの内容を取得します: file('http://www.google.com');)。これは、多くの初心者がそれを手に取り、それを使って多くの非常に危険なサイトを作成したことを意味しますが、それはあなたが最初に選択した言語に関係なく起こります.
堅固な ORM フレームワーク (SO にはどれが最適かについての約 30 の質問があります) を使用すると、うまく処理されます。
PHP 4 を使用しないと言う人の多くは、実際には PHP 4 を使用しないと言っているのです。
どんな言語でも良いコードを書ける
と
どんな言語でも悪いコードを書くことができる
PHP は、絡み合ったスパゲッティ コード ライブラリになることがよくあり、「アプリケーション」を単なる一連のスクリプトにします (この良い例については、Moodle を参照してください...)。
「大規模なものにPHPを使用しないでください」の多くは、PHPが本来の目的であるテンプレート言語からハッキングされていることに起因していると思います。それは理解できますが、それができることを証明するプロジェクトがたくさんあります (Drupal、mediawiki、Facebook)。
大規模なプロジェクトに PHP を使用できない理由はありません。結局のところ、Facebook は PHP 上に構築されています。ただし、問題はありますが、大規模なプロジェクトには問題があります。
PHP が普及している理由は、参入障壁が低く、ホスティングが安価であることです。これは Apache 拡張機能として実行され、ほとんどコーディングを開始できます。.Net や Java などのより多くのエンタープライズ プラットフォームに移行すると、参入障壁がはるかに高くなりますが、スケーリング可能なアプリケーションを作成するのに役立つ多くのインフラストラクチャも付属しています。
たとえば、PHP でのデータベースの抽象化は (私見ですが) 悲惨です。ベンダー固有です。MySQL では、人々は次のようなことをする傾向があります。
function get_users($surname) {
mysql_query("select * from users where surname = '$surname'");
...
}
これはいくつかの理由で悪いです:
mysql_escape_string()ですが、そうしない人が多いことに驚かれることでしょう)。と個人的には、上記のすべての理由から mysqli を好みますが、独自の問題があります。つまり、LONGTEXT フィールドを使用すると mysql がクラッシュし、少なくとも 2005 年以降、まだ修正されていません (はい、私と他の何人かがバグを提起しました)。
これを Java (私がよく知っている) と比較してください。JPA または Ibatis は、起動コストが高く、はるかに優れた ORM ソリューションですが、エンタープライズ規模で役立ちます。
したがって、PHP で大規模なプロジェクトを行うことは禁止されていません。他のプラットフォームが提供するものを複製するために、ますます多くの作業を自分で行う必要があるという点で、単純に難しくなっています。
そうは言っても、PHP + memcached/APC + beanstalkd は大いに役立ちます。
ああ、それはもう 1 つの問題です。PHP はバックグラウンド処理やスレッド化を実際にはサポートしていません。そのためには何か他のもの (またはスタンドアロン スクリプト) が必要です。他のものを使用している場合は、それを Web 用にも使用してみませんか (Java、Ruby、.Net など)。
リンクした質問が削除されたので、その一部をここに置きます。
私は、別の質問スレッドで、PHP をひどい言語と呼ぶ皮肉なコメントをしたところ、狂ったように反対票を投じられました。ここには、PHPが好きな人がたくさんいるようです。
だから私は本当に興味があります。私は何が欠けていますか？PHP が優れた言語である理由は何ですか?
嫌いな理由は以下です。
PHP では、組み込み関数とライブラリ関数の命名に一貫性がありません。予測可能な命名パターンは、どの設計においても重要です。
PHP には、組み込み関数のパラメーターの順序付けに一貫性がありません。たとえば、array_map と array_filter などです。これは、単純なケースでは煩わしく、あらゆる種類の予期しない動作やさらに悪い結果を引き起こします。
PHP 開発者は、組み込み関数と下位レベルの機能を常に非推奨にしています。良い例は、関数の参照渡しを廃止したときです。これは、たとえば関数のコールバックを行うすべての人にとって悪夢のようなものでした。
再設計の考慮不足。上記の非推奨により、多くの場合、関数にデフォルトのキーワード値を提供する機能がなくなりました。彼らはこれを PHP 5 で修正しましたが、PHP 4 では参照渡しを非推奨にしました!
名前空間の実行が不十分です (以前は名前空間がまったくありませんでした)。名前空間が存在するので、逆参照文字として何を使用しますか? バックスラッシュ！PHP でさえ、エスケープのために普遍的に使用される文字です!
暗黙的な型変換が広すぎると、バグが発生します。たとえば、浮動小数点数から整数への暗黙的な変換、またはその逆の暗黙的な変換に問題はありません。しかし、PHP (私が最後にチェックしたもの) は喜んで配列を魔法のように整数に変換しようとします。
再帰のパフォーマンスが悪い。再帰は、あらゆる言語で書くための根本的に重要なツールです。複雑なアルゴリズムをはるかに単純にすることができます。貧弱なサポートは許されません。
関数は大文字と小文字を区別しません。彼らがこれについて何を考えていたのか、私にはわかりません。プログラミング言語は、コンピューターとコードのリーダーの両方に対してあいまいさなしに動作を指定する方法です。大文字と小文字を区別しないと、多くのあいまいさが生じます。
PHP は、処理とプレゼンテーションの結合を推奨しています (実際には必要です)。はい、そうしない PHP を作成することはできますが、実際には (適切な設計の観点から) 間違った方法でコードを作成する方が簡単です。
PHP のパフォーマンスは、キャッシュなしでは最悪です。PHP 用の商用キャッシング製品を販売している人はいますか? ああ、ほら、PHPの設計者はそうしています。
最悪なことに、PHP は Web アプリケーションの設計は簡単だと人々に信じ込ませてしまいます。そして、それは確かに、関連する多くの労力をはるかに簡単にします. しかし実際には、安全で効率的な Web アプリケーションを設計することは非常に難しい作業です。
多くの人にプログラミングを始めるよう説得することで、PHP はプログラマーのサブグループ全体に悪い習慣と悪い設計を教えました。安全に使用するための理解が不足している機能へのアクセスが与えられます。これは、PHP が安全ではないという評判につながっています。
(ただし、PHP が他の Web プログラミング言語と比べて多かれ少なかれ安全であることは認めます。)
PHP について欠けているものは何ですか? 有機的に成長し、管理が不十分な言語の混乱が、貧弱なプログラマーを生み出しているのを見ています。
そうでなければ私を説得してください！
私はあなたの箇条書きのそれぞれに対応することに挑戦します
PHP では、組み込み関数とライブラリ関数の命名に一貫性がありません。予測可能な命名パターンは、どの設計においても重要です。
私はこのトピックが好きでもあり、嫌いでもあります。本質的に、この問題は正しいからです。一部のバイワード関数がアンダースコアで分割され、一部が分割されないのはなぜですか? 針と干し草の山パラメータが引数シグネチャの位置を時々交換するのはなぜですか? バカバカしい。しかし、結局のところ...これは本当に重要ですか？Intellisense と php.net を備えた私の IDE は、ブラウザをクリックするだけで、それほど大したことではありません。言語としてのPHPに対してマイナスですか？はい。有能なプログラマーになる能力を妨げますか? いいえ。
PHP 開発者は、組み込み関数と下位レベルの機能を常に非推奨にしています。良い例は、関数の参照渡しを廃止したときです。これは、たとえば関数のコールバックを行うすべての人にとって悪夢のようなものでした。
個人的には、これは良い点ではないと思います。言語の進化には非推奨化が必要です。特に、PHP のように多くの欠陥がある言語ではそうです。PHP は「下手なプログラマーになりやすい*」ことで多くの批判を受けていますが、同時に PHP グループは、コールタイム パスバイなどの愚かな構造を言語から取り除こうとしても問題を抱えています。 -参照。呼び出し時の参照渡しをなくすことは、彼らが行った最高の取り組みの 1 つです。初心者の開発者にとって、この「機能」ほど簡単に失敗する方法はありませんでした。
再設計の考慮不足。上記の非推奨により、多くの場合、関数にデフォルトのキーワード値を提供する機能がなくなりました。彼らはこれを PHP 5 で修正しましたが、PHP 4 では参照渡しを非推奨にしました!
一般的に配慮が欠けているわけではないと思いますが、この特定の変化に刺されて、口の中に酸っぱい味が残っていると思います. 言語の変更は、何年も前からではないにしても、数か月前にわかることがよくあります。4 から 5 への移行に関する移行ガイドが提供され、バージョンの違いはマニュアルに記載されています。呼び出し時の参照渡しは恐ろしい「機能」であり、他の手段では得られない表現力を開発者に与えるものではありません。それがなくなってよかった（魔法の引用のような他のがらくたとともに）
名前空間の実行が不十分です (以前は名前空間がまったくありませんでした)。名前空間が存在するので、逆参照文字として何を使用しますか? バックスラッシュ！PHP でさえ、エスケープのために普遍的に使用される文字です!
私はこれについて複雑な気持ちを持っています。私の一部は、「とにかく、文字エスケープは文字列の外では意味がない」と考えており、「きっと彼らはもっと良いものを使うことができるだろう」と考えています。しかし、彼らはできますか？わかりません。私は Zend パーサーの開発者ではありません。PHP 5.3 まで名前空間がまったくなかったのは大きな見落としですか? そのとおり。
暗黙的な型変換が広すぎると、バグが発生します。たとえば、浮動小数点数から整数への暗黙的な変換、またはその逆の暗黙的な変換に問題はありません。しかし、PHP (私が最後にチェックしたもの) は喜んで配列を魔法のように整数に変換しようとします。
PHP がこれを行う方法に反対するのは問題ないと思いますが、それが言語を「悪い」ものにすることには反対します。しかし、このトピックにどれだけ座って、弱い型付けと強い型付けについて議論したいのか尋ねてください. (PS 私はまったく知りません)念のため: 引数の型が問題であり、強制によって解決できない場合、PHP は E_WARNING レベルのエラーを発行します。
再帰のパフォーマンスが悪い。再帰は、あらゆる言語で書くための根本的に重要なツールです。複雑なアルゴリズムをはるかに単純にすることができます。貧弱なサポートは許されません。
PHP は Web 用の DSL です。私はこれを 8 年間フルタイムで行っており、再帰を 4 ～ 5 回使用したことがあります。通常は、ある種の迷惑なディレクトリまたは XML トラバーサルです。これは、Web 開発で頻繁に必要とされるパターンではありません。パフォーマンスが遅いことを言い訳するつもりはありませんが、これは生産上の問題というよりも、はるかに学術的な問題です。本当に強力な再帰的パフォーマンスが必要な場合、PHP はすでに不適切な言語です。
関数は大文字と小文字を区別しません。彼らがこれについて何を考えていたのか、私にはわかりません。プログラミング言語は、コンピューターとコードのリーダーの両方に対してあいまいさなしに動作を指定する方法です。大文字と小文字を区別しないと、多くのあいまいさが生じます。
私はこれに完全に100％同意します。
PHP は、処理とプレゼンテーションの結合を推奨しています (実際には必要です)。はい、そうしない PHP を作成することはできますが、実際には (適切な設計の観点から) 間違った方法でコードを作成する方が簡単です。
* うーん、このトピックは非常になじみがあるように聞こえます...
しかし真剣に、私が思うに、100% 絶対に 100% 必要な出力システムを実装できる言語について人々が不平を言うことは驚くべきことです (PHP テンプレート システムの膨大な量とスタイルだけがこれを物語っています) - または - そのすべてのオーバーヘッドをスキップし、直接出力するだけです。これは PHP を悪くするものではありません。これは、PHP を優れたものにする要素の一部です。
PHP のパフォーマンスは、キャッシュなしでは最悪です。PHP 用の商用キャッシング製品を販売している人はいますか? ああ、ほら、PHPの設計者はそうしています。
バイトコード キャッシング (アクセラレータのようなもの) ですか、それとも出力キャッシングですか?
前者の場合、このトピックにどれだけ関心があるかはよくわかりません。アクセラレータは無料で簡単に実行できます。なぜそれが言語の一部ではないのかについて議論することはできますが、最終的にはそれほど重要ではないと思います.
あなたが出力キャッシュについて話しているのなら、私はあなたに何を言うべきかわかりません. 大量のトラフィックを伴う Web プロジェクトでは、キャッシュが必要です (シード ポッドキャスト #27 など)。これは PHP 固有の問題ではありません。
要約すると、あなたは PHP を非常に学術的な意味で「悪い」言語だと考えていると思います。また、前回の投稿では、PHP を使用して「物事を成し遂げる」私のような人々から、おそらく反対票を投じられたでしょう。
あなたのすべての批判 (およびその他の批判) は有効です。あなたが PHP を嫌うことは許されていますし、それが期待されていることさえあります。
しかし、繰り返しになりますが、いくつかの利点があります。
最後に、他の言語で書くような優れたコードを作成することで、すべてではないにしても多くの欠点を克服できます。PHP でしっかりとした、安全で、良い匂いのするコードを書くことができます。これは、多くの代替手段よりも何倍も高速に実行され、ホストとスケーリングが容易になります。
PHP について欠けているものは何ですか? 有機的に成長し、管理が不十分な言語の混乱が、貧弱なプログラマーを生み出しているのを見ています。
単純。貧弱なプログラマーが自分の言語に対して非常に防御的であるという事実。;) PHP は習得が容易で、代替手段よりもはるかに簡単です。一度習得すると、1) PHP の何が問題なのか、2) 代替手段がどのように優れているのか、3) どのように切り替えるか、および代替手段の1つを学びます。
そしておそらく、人々はどのような選択肢を持っているのでしょうか? ASP? それ自体には、大部分の Web サーバー (Apache) で実行できないことから、ばかげた過剰設計された設計の選択 (Web フォーム? Viewstate? 非同期の "要求が傍受され、順次実行される AJAX) まで、多くの問題があります。 ) Ruby on Rails? まあ, おそらく, どれだけのウェブサーバーが再びそれをサポートしているかを除けば? 現時点では簡単にアプローチできるわけではありません. それに遅い. だからおそらくPHPの「強み」は本当に良い代替手段が存在しないことです. 少なくともこれが私が理由です.可能な限り、すべての Web プログラミングに近づかないでください.PHP は最悪ですし、私はどの代替手段にもあまり熱心ではありません.
PHP には、おかしなことでもないほど多くの根本的な問題があります。Unicodeサポートの欠如から、予期しないセキュリティホールにつながることが多い多くの暗黙的な型変換、プレゼンテーションと...他のすべての完全な混合、または（最後にチェックした）使用しないデフォルトのデータベースモジュールまでパラメータ化されたクエリ。データベースへのアクセスと HTML の生成という 2 つの目的のために作成された言語について話しているのですが、どちらもひどいものです。
言語を設計する資格がない、またはできない人々によって設計された言語です。;)
私にとって最悪の PHP の罪は、プレゼンテーションとビジネス ロジックの結合です。より良い方法でそれを書くことができないということではありませんが、そうするように促すわけではありません。
PHP サイトにも多数のセキュリティ脆弱性が関連付けられています。それが不均衡であることを証明することはできません (多くのサイトが PHP で書かれているため) が、そうではないかと思います。私の意見が正しければ、セキュリティの脆弱性はバグの一種であるため、PHP サイトは全体的にバグが多い傾向にあるのではないかと思います。
(ちなみに、いくつかの大規模なサイトを指差して、PHP でそれを行うことができたと言うことは、これに対する反論ではないと思います。それは、隣人が喫煙していたので、タバコは癌を引き起こさないと言っているようなものです。 100歳まで生きた。）
この同様の質問をチェックしてください-PHP はJavaだけでなくエンタープライズレベルのサイトも処理できますか
要約-Facebook、Wikipedia、Yahoo.com、Digg、Flickr、その他多くの巨大なサイトがPHPで実行されています。その口径の何かを作ることに近づいた場合でも、PHPでそこに到達できるので安心できます。
アプリケーションがどの程度保守可能、拡張可能、信頼性、安全性、パフォーマンスを発揮するかは完全にあなた次第であり、言語に依存しません。ただし、PHPには、Webアプリケーションを構築するための非常に便利なツールがあります。
私にとって、そして大規模または巨大なプロジェクトについて話すと、それは（主に）1つの単語に要約されます：依存関係。
スクリプト言語の問題は、世界中のあらゆるものに似ています。最大の利点は、同時に最大の欠点です。
最大の利点は、無料で高速にコーディングできることです。スクリプトを書くだけで、その目的に役立ちます。冗長性は必要ありません。コーディングするだけです。
最大の欠点は、ある意味で、このスクリプトが他のスクリプトを妨害していないかどうかを確認することです。またはそれ以上：他の人が依存している古いスクリプトを変更します。すべての依存関係が希望どおりに機能することを確認しますか？
これは、ここで通常の意味が何であれ、「通常の」Webページの生成には当てはまりません。しかし、約50万行のソースコードに依存する製品があり、追加の10万行のコードで構成されるクライアント向けのカスタマイズもあります。そして、コンパイラがすべての依存関係をチェックし、何か間違ったことをした場合に警告/エラーを表示することを非常に嬉しく思います（たとえば、ここで最低レベルを話す、変数の入力ミスやメソッド呼び出しなど）。
これと、他の言語がその性質上、より使いやすい「エンタープライズ」機能を提供しているという事実（つまり、「銀行の使用法」のためのアプリケーションサーバー）は、多くの人がPHPを大規模に（またはより良い：巨大に）見ない理由を要約していると思います。プロジェクト。
当社はPHPを使っていくつかの大規模なウェブサイトを運営しており、言語に関連する問題はありませんでした。
PHP 言語の構造について、私には十分ではないところがあります。たとえば、関数の名前。1 つの言語で関数に名前を付けるためにいくつかの方法を使用することは、ベスト プラクティスではありません。アンダースコア (function_name) の混合、単語のくっつき (functionname) など。つまり、これは本当にごちゃごちゃです。非常に似ている、または同じことを行う関数が多すぎますが、それらの名前は非常に紛らわしいです。これは、優れたプログラミング言語の特徴ではありません。
大規模な展開では、言語は十分に簡単で具体的なものでなければなりません。変数型の宣言のように PHP が省略しているものは、後で理解して対処するのが非常に難しくなります。
その他のポイントは、機能の継続的な追加と他の機能のキャンセルです。PHP 5 に OOP が追加されたことで、プログラマーにとって作業が容易になると思われますが、後方互換性についての考慮事項はどうでしょうか?
このプログラミング言語がこのようなものである主な理由は、その起源によるものです: Personal Home Page. 大規模な展開用に設計されていません。
私は、この言語を企業規模の言語にしようと多大な努力が払われていることを知っています。個人的には、十分に優れたオープン ソースのサーバー側プログラミング言語を待っています。でもこの日が来るまでは橋の下にたくさんの水が流れます。
これらはすべて良い答えです。
私は初心者でした。私はコーディングを始めて 5 年しか経っていませんが、小規模から大規模まで 85 の Web サイトを直接サポートおよび管理しています。より良いコードを作成する方法。
確立された開発者がこの問題について意見を述べているのを聞くのは素晴らしいことです。PHP がベストだとは思いませんが、「ベスト プラクティス」への投資は十分に機能しているようです。
みんな、ありがとう！