この記事はNapolskyによって書かれました 。 既知の理由により、彼はそれを公開できませんでした。 記事が気に入ったら、既知の方法で著者に報酬を与えてください。
このトピックでは、Webプログラミングで開発している1つのアプローチについて説明します。その中心は、コードをデータベースに保存することです。 残りのテキストに関するいくつかのコメント：
- 「ページコード」というフレーズは、実行可能な（php）コードを意味します
- パフォーマンスに関するすべての事項において、アクセラレータ、キャッシュシステムなどを使用しない、クリーンなページ生成時間を意味します。
それがすべて始まった方法
「なぜそれが必要なのか」を理解するために、コードをデータベースに保存することになったパスをすぐに確認します。 そのため、既存のシステム用のスクリプトやモジュールを作成するのではなく、絶対にゼロから独自のWebサイトエンジンを作成することで、Webプログラミングの道を始めました。 この時点で、私はC ++で2年間のプログラミング経験があり、もちろん、親指で独自のOOP Webエンジンを構築しようとしました（ただし、PHPにはOOPから名前が1つありました:)）。 理由の範囲内で、私は本当に「バイク」が大好きです。 特に大きい。 そして、既成のソリューションを使用する前に、私は常に「より良く書くことは可能ですか？」という質問を自問します。
一般に、自転車を書くことは、特に初心者開発者にとっては非常に便利です（割り当てられた時間と予算でコードを書くのではなく、プロフェッショナリズムを高めることが最初の場所である場合）。 独自の決定を書くことでのみ、最下位レベルで内部から何かが構築される方法を理解できます。 そして、これにより、複雑さ、リソースの強度、さまざまなアプローチの速度が理解され、最終的には問題を解決するための適切なツールの選択につながります。 たとえば、大学では配列のプッシュバックを書くことを余儀なくされたので、一見シンプルで些細なものの後ろにもっと何かが隠れていることを忘れません。その結果、クラス、モジュール、テンプレートなどを含むフォルダーというかなり古典的なスキームに従ってエンジンが構築されました。 まあ、それに応じてページ生成時にこれらすべてを無限に含めます。 そして、多くのプログラマーのように、合理化者が私の中に住んでいるので、このアプローチのコストは私を悩ませ始めました。 特に、ほとんどの場合、ページ（たとえば、ライブラリ全体、このページでは1つの関数のみが必要な場合）の
多くの「不要な」コード （ページで実行されない「デッド」コード）
を接続する必要があるという事実が気に入らなかった彼女）。
ページ上の「デッド」コードの量を考慮したことがありますか？ 実際、その量は通常、ページにアクセスするときに実際に実行されるコードの量の7〜15倍です。 たとえば、コメントクラスを取り上げます。 render（）、delete（）、edit（）、add（）、compress（）、answer（）メソッドなどがあります。さらに、スクリプトの1回の実行では、原則として、これらのメソッドのうち1つだけが呼び出されます（delete-if削除、編集-編集時など）、残りは呼び出されません。 そのため、このような追加コードがページにどれだけ実行されるかを検討してください。最初に、さまざまなページのニーズに合わせて大きなライブラリまたはクラスを「カット」および「グルー」することで最適化を試み、それによりインクルードおよび「デッド」コードの数を減らしました。 しかし、これはもちろん行き止まりです。 時間が経ちました。 このエンジンで書かれたプロジェクト（彼らにとって天国:)）はますます多くなりました。 これに伴い、接続されたコードの数とサイズが増加し、ページ生成の時間も増加しました。 私は、「デッド」コードを取り除く方法についてますます考えるようになりました。 そして、私は大胆で、とんでもないアイデアにさえ見えました。 もしも...
アイデアの誕生
しかし、本当に必要なものだけをページ上で収集できるように、コードを最小の独立した部分に分割するとどうなりますか？ つまり、すべての関数、クラス（理想的にはクラスメソッド）などを分離します。 したがって、多くの小さな「ブリック」を取得し、そこからページを折ります。 したがって、
「デッド」コードとインクルージョンを
完全に取り除くことができます。 私はこのアイデアに本当に興奮していましたが、答えよりも多くの質問がありました。それを行う方法、それが機能するか、実装でどんな落とし穴が待ち受けているか、そのようなシステムはどれくらい高速ですか？ 要するに、これをどのように実装し、どのように機能するかについて、私が少しだけ考え出すまでです。 しかし、もちろん試してみる価値がありました。
戦士の道
イデオロギーは、すべてを最小のコードに分割し、それらから何でも収集できるというものです。コードの「ブリック」を保存する方法については質問がありませんでした。属性の場合、唯一の可能なオプションはデータベースを使用することでした。 そのようなシステムの動作原理を、できるだけ本質的であり、できるだけシンプルで抽象的なものを示すようにします。
1レンガストレージ
ここではすべてがシンプルで明確です：個別の関数、クラス（またはクラスメソッドの方が優れています）、モジュールコントローラー、モジュール表現などは、データベース内の個別の行です。 たとえば、最も単純な場合、テーブルは
id | code | name | componentType （
componentTypeはブリックのタイプ（関数、クラス、モジュール..））のようになります。
2依存関係ストレージ
あるブリックのコードが別のブリック（たとえば、タイプfunction-function、module-function、さらにはpage-moduleの依存関係）を引き起こす可能性があるため、レプリケーションを保存する必要があります。 これは、レプリケーションテーブルを使用して行うことができます。レプリケーションテーブルは、最も単純な場合、
id | parentId | childIdという形式
です 。 したがって、ネスト構造の「ブリック」の適切な収集の問題を解決します。
function A()
{
B();
}
,
«»
B.
B.
3
, , ? , , , «» . Codegen. , «». : . «» . :
1 , .
. , Codegen, , ( eval ).
:
—
— «»
:
- 12000-14000 1500-2000
- 16-22 0
- 0.25-0.3 0.04-0.05 (~600%. , . )
.
-
IDE. . , / ( ). ,
. . ( , ..) . , , IDE .
-
. . , - eval, .
-
. , . , .
:
,
, , . , — .
/backup/update
… sql( ) , .
,
. .
, , , , «» on site
( ) . .
—
. . , «» , .
—
. , .
—
. , , . , .
—
. , codegen, . , . : - ,
if(!$user->isAdmin()) {ErrorLog(' '); return;}
_CHECKADMIN
. .
, , . , , . , , , : . -, «» . , , . , , CMS, .
P.S. , .