php が大規模プロジェクトに適していないのはなぜですか?

# php が大規模プロジェクトに適していないのはなぜですか?

1. 再帰のサポートが不十分である

再帰は、関数が自分自身を呼び出すためのメカニズムです。これは、複雑なものを非常に単純なものに変えることができる強力な機能です。再帰の使用例はクイックソートです。残念ながら、PHP は再帰があまり得意ではありません。 PHP 開発者の Zeev 氏は、「PHP 4.0 (Zend) は、ヒープ アプローチではなく、高密度データに対してスタック アプローチを使用しています。これは、許容できる再帰関数の数が他の言語に比べて大幅に制限されていないことを意味します。」バグ 1901 を参照してください。 。これは非常に悪い言い訳です。すべてのプログラミング言語は適切な再帰サポートを提供する必要があります。

2. 多くの PHP モジュールはスレッドセーフではありません

数年前、Apache は Web サーバーのバージョン 2.0 をリリースしました。このバージョンでは、ソフトウェアの 1 つの部分で複数の部分を同時に実行できるマルチスレッド モードがサポートされています。 PHP の発明者は、PHP のコアはスレッドセーフだが、非コア モジュールはスレッドセーフではない可能性があると述べています。ただし、10 回中 9 回は、このモジュールを PHP スクリプトで使用したいと考えますが、これにより、スクリプトが Apache のマルチスレッド モードと互換性がなくなります。これが、PHP チームが Apache 2 のマルチスレッド モードで PHP を実行することを推奨しない理由です。 Apache 2 が不人気なままである理由の 1 つとして、PHP のマルチスレッド モードのサポートが不十分であることがよく挙げられます。

3. ビジネス上の理由により、PHP は健全ではありません

キャッシュを使用すると、PHP のパフォーマンスが 500% 向上します [ベンチマーク テストを参照]。では、なぜキャッシュが PHP に組み込まれていないのでしょうか? PHP のメーカーである Zend は独自の Zend Accelerator を販売しているため、当然ながら商用製品を捨てたくはありません。

しかし、別のオプションがあります: APC (Zend は後に Zend Optimizer、無料のアクセラレータ - トランスレータを発表しました)

4、 は標準ではありません 日付形式文字

多くのプログラマは、UNIX および C 言語に由来する日付形式文字に精通しています。他のいくつかのプログラミング言語はこの標準を採用していますが、奇妙なことに、PHP には完全に互換性のない独自の日付形式文字のセットがあります。 C では、「%j」は年間の日を表し、PHP では月の日を表します。ただし、事態をさらに混乱させるのは、Smarty (人気のある PHP テンプレート エンジン) の strftime 関数と date_format 関数では、C/UNIX 書式設定文字が使用されているということです。

5. わかりにくいライセンス

PHP は無料であり、マニュアルに記載されているすべての PHP モジュールも無料であると思われるかもしれません。間違っている！たとえば、PHP で PDF ファイルを生成する場合、マニュアルには PDF と ClibPDF という 2 つのモジュールが記載されています。ただし、これらは両方とも商用ライセンスを取得しています。したがって、使用するすべてのモジュールについて、そのライセンスに同意する必要があります。

6. 一貫性のない関数の命名規則

一部の関数名は複数の単語で構成されています。一般に、単語の組み合わせには次の 3 つの習慣があります。

## ● 直接結合: getnumberoffiles

# ● アンダースコアで区切る: get_number_of_files

# ● Camel のルール: getNumberOfFiles

Mostいずれかの言語を選択してください。ただし、PHPは使用されます。

たとえば、一部の特殊文字を HTML エンティティに変換する場合は、関数 htmlentities (単語を直接結合) を使用します。逆の機能を使用したい場合は、弟の html_entity_decode を使用する必要があります。何らかの特別な理由により、この関数名には単語がアンダースコアで区切られています。これはどうやってできるの？ strpadという機能があるのはご存知でしょうか。それとも彼はstr_padですか？毎回、シンボルが何であるかを確認するか、エラーが発生するのを待つ必要があります。関数では大文字と小文字が区別されないため、PHP では rawurldecode と RawUrlDecode に違いはありません。これも良くありません。両方が使用されており、見た目が異なっており、読者を混乱させます。

7. 魔法の引用符の地獄

魔法の引用符は、SQL インジェクション攻撃から PHP スクリプトを保護します。これはいい。ただし、何らかの理由で、php.ini でこの設定をオフにすることができます。したがって、柔軟なスクリプトを作成したい場合は、マジック参照がオンかオフかを常に確認する必要があります。このような「機能」はプログラミングを容易にするはずですが、実際にはプログラミングをより複雑にします。

概要

非常に小規模なプロジェクトの場合、非常に満足のいくプログラミング言語となる可能性があります。しかし、より大規模で複雑なプロジェクトの場合、PHP は弱点を示します。

PHP 関連の知識の詳細については、

PHP 中国語 Web サイト をご覧ください。

以上がphp が大規模プロジェクトに適していないのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。