たくさんの面白い人
そして誰もが自転車を作ります。
そしてある朝
火薬を思いつきます。
ビクター・ツォイ
最初は、「私はPRです」のセクションで、自分がどれだけうまくやっているか、私がどんな素晴らしいことをしたかについての記事を書きたかったのですが、ネット上で少し検索した後、私は自分だけではないことに驚いていました。 それから私は反対に行くことにしました：おそらくほとんどすべてのWebプログラマーは、少なくとも彼の人生で一度は完全なCMSを書き込もうとします。 同時に、設計プロセス（およびこのプロセスはコードの記述時にすでに発生していることが多い）で、開発者には確かに質問があります。 これらの質問で、彼は検索エンジンに目を向け、同様のレーキですでに旅行した人のサイトにアクセスします。
そこで、私は初心者の「自転車開発者」がどのようなリクエストを受け取ったのかを調べ始め、作業の始めには私には明らかではなかったいくつかのことを強調しようとしました。
1. MVCがすべてです！
Webアプリケーション開発に関する会話がどこに来ても、MVC（Model-View-Controller）という略語がすぐに表示されます。 このアプローチでは、インターフェイスをロジックから分離し、ロジックをデータから分離する必要があると述べています。 私はこれらのアイデアに完全に染み込んだとは言いませんが、デザイン（またはデザイン）の変更がコードのロジックに影響を与えないという事実-私は口で泡で防御する準備ができています:)
これが、レーキナンバー1が置かれている場所です。外観をプログラムロジックから分離する必要があります。 それを行う方法-誰もが自分で決める。 この問題にはかなりの数の壊れたコピーがあります。ここにはさまざまなテンプレートエンジンとxslt変換があり、php + htmlが別々のファイルに取り出されています。 選択肢は大きいが、通常の「銀の弾丸」は存在しない。規模の片側に柔軟性があり、もう片側に了解性がある。 「最小のプログラミング」を備えた
Smartyでさえ、多くのユーザーにとって複雑に思えます。 したがって、システムを箱から出して、最小限のプログラミング知識で必要に応じてファイルを保存したいユーザーに焦点を当てる場合は、頭を痛めるだけの価値があります。
さらに、設計は交換可能であり、場合によってはオンザフライでも可能です。 つまり、便利なストレージと編集を提供する必要があります。 そして、多くの人が無視したもう一つのこと：デザインは簡単に編集可能で更新可能でなければなりません。 200個のテンプレートで構成される無料のフォーラムのデザインを調整する必要がありました。このテンプレートでは、すべてがテーブルでしっかりと「釘付け」され、JavaScriptの一部が「ロジックから」挿入されます。
私はこの設計を思いつきました。ユーザー設計には、基本設計にはないものしかありません。 つまり、最も最小限のケースでは、デザインはデザインの名前を持つ空のカタログで構成されます。 この場合、欠落しているすべての部品が借用されるため、設計が基本設計とまったく同じに見えることは明らかですが、出発点として非常に便利です。 デザインにcssが表示される場合、システムは自動的にそれに切り替えます（htmlはまだベースのものから借用しています）。 JSでも同じです。 これで得られるのは、ユーザー設計において、彼自身が作成したファイルのみです。 ユーザーは、自分が修正したファイル、および作業開始時に基本設計から単純にコピーしたファイルを覚えておく必要はありません。 このサイトには、ユーザーを編集することなく、基本設計のほぼすべての革新的な技術も表示されます。 そのようなシステムは便利で論理的であると感じましたが、ある人にとってはやや予想外のように思えます。 それをサービスに取り入れるか、あなた自身のものを思いつくかはあなた次第です。
2.サイト構造
コアを取得します。 カーネルは何をすべきですか？ そして、すべての「汚い」作業を行う必要があります。サイト設定、ユーザーグループの権限と設定、使用モジュール、テンプレート、キャッシュ、ローカリゼーションパラメーターなどを決定します。 つまり、プラグインが動作を開始するまでに、興味のあるすべての情報をカーネルから取得できます。 気味が悪いように聞こえますが、要素の相互作用を明確に想像すれば、これはすべて比較的簡単に記述して作業できます。
このサイトは、データベース内のどこかにダンプされたページの集まりではなく、厳密な階層になると自分で決めました。 その結果、サイト構造はツリー状になり、デザインの場合のように、欠落している部分は親から継承されます。 ユーザーグループの構造もツリーに似ています-権限と設定も親から継承されます。 ローカリゼーションファイルとモジュールも単純な階層を持っています。 明確な階層により、サイトマップの自動生成、さまざまなメニュー、権利の分配など、あらゆる種類の不快なものをエンジンに転送することができました（はい：複数のグループに何かを与えるために、それぞれを編集する必要はありません-階層を定義するだけです）。 生きて喜ぶ！ そして、もし熊手がなければすべてがうまくいくでしょう：
最初にレーキ。 キャッシング
私は「メガドライブ」の設計に従事していましたが、どういうわけかキャッシング次第ではありませんでした...はい、そしてあなたは思う-何がそんなに複雑なのですか？ ページを変数に配置してファイルに保存し、次回そこから表示しました。 何かビジネス...いつでも添付できます！ ああ...そして、登録ユーザー用に別のページがあります...ええと、考えてみてください-キャッシュに2つのページを保存します！ そして、ヘッダーに「hello、Vasya」と表示する必要があります...まあ、ヘッダーのこのフラグメントはキャッシュされるべきではありません。 そして、地下の同じフラグメント...と中部...うーん...まだページのさまざまな部分をさまざまな期間キャッシュする必要があります...私たちは座って、ブロックキャッシュのためにエンジンとキャッシュシステムを書き換えます-各ブロックに独自の寿命があります。
2番目のレーキ。 キャッシング
どうして？！ 再度キャッシュしますか？ 結局のところ、彼らはすべてを美しく行いました！ ええ、そうです...彼らはしました...そして、タスクが彼の個人的な設定に基づいて各ユーザーのコンテンツを生成することになるまでそれはうまくいきました。 同時に、キャッシュのサイズはジェット戦闘機の速度とともに増大し、その内容は再び要求されるよりもはるかに早く古くなっています。 サイトを高速化する代わりに、速度を落として、誰も必要としないギガバイトのキャッシュページを作成します。サイトのメインスクリプトは「His Majesty」キャッシュ無効化ツールです。 うーん...エンジンを再度書き直してください。今回はパフォーマンスのボトルネックであるため、データベースクエリのレベルでキャッシュを実装します。 書き換えられた...すべてがnです。
3番目のレーキ。 キャッシング
あなたは自分の作成を見て、完全な馬鹿のように感じます。ページ全体を保存するのではなく、毎回作成します。 しかし、キャッシングはその反対のために正確に考案されました！ どのように私は何かを破裂させるのですか？
その結果、一部のモジュールはブロックにキャッシュされ、一部はクエリレベルでキャッシュされます。 これにより、たとえばサイトメニューなど、めったに変更されないものをキャッシュに格納することができました。
私自身の教訓として、これを学びました。システムは、実行の特定の段階で、簡単にキャッシュまたはそこから取得できるデータをグループ化するように最初に設計する必要があります。 また、キャッシュシステムをエンジンに厳密に結び付けるべきではありません。今日ではキャッシュをファイルに保存するだけで十分であり、明日（または今夜）にはすでにmemcacheサーバーにサービスを提供しています。
エンジンの作成プロセスでは、リファクタリングに関するスマートブックを読むことも、エンジンの作成後に読むことも理にかなっています。 いずれにせよ、3つすべて（あなた、エンジン、本）がそれをうまくやることができます。
3.モジュール性。
現代のシステムを「それ自体」のものとして想像するのは困難です-機能を拡張するためのインターフェースが必要です。 したがって、CMSの最もおいしい部分であるモジュールの作成に進みます。 また、多くの質問もあります。モジュールの外観、システムへの接続方法などです。
一部のシステムでは、モジュールの呼び出しはシステムのカーネルに厳密に登録されているため、モジュールを記述したりサードパーティをインストールしたりする場合は、ソースコードにアクセスし、インストールマニュアルを用意して、対応する呼び出しをコードに入力します。 このアプローチのすべての愚かさで、多くのシステムはまさにそのように機能します。 このソリューションにはバリエーションがあります。各モジュールは特定のディレクトリ内の個別のファイルです。 この場合、カーネルにモジュールを登録するだけでなく、単一のファイルとして実行する必要もあります。 アクティブなテンプレートを持つバリアントもありました。つまり、テンプレートに{module_name}が入力され、パーサーがこのタグに到達すると、モジュールmodule_nameが実行のために呼び出され、その結果がタグの代わりになります。 おそらくこの方法は便利かもしれませんが、この場合、ロジックをプレゼンテーションから分離するだけでなく、逆もまた完全に混在しています。
一定数のコーンの後、おそらく簡潔で単純な例ではないシステムになりましたが、非常に便利なようです。 各モジュールは、カーネルが1つのファイル（index.php）のみを呼び出す個別のディレクトリです。 このファイルは、「Hello world！」を出力し、ハイパースペース準エミッターの制御ファイルを接続できます。これは、モジュール開発者にとって便利です。 同じディレクトリに、モジュールパラメータ、可能な設定、および権限のシステムの説明が記載されたxmlファイルがあります。 このファイルは、システム自体がモジュールを追加し、この頭痛をユーザーに転送しないようにするために使用されます。「モジュールのインストール」ボタンをクリックしてください-受信してください。
インストールを理解しました。 新しい問題が発生します-たとえば、ユーザーがフォトアルバムやフォーラムなどを1ページに投稿しないようにする方法はありますか？ 常識に頼るのは無意味なので、モジュールの入力が必要です。 このタイプのモジュール（これらのモジュールの一部では、「コンポーネント」の概念を探りました）は、ページに1つしか存在できません。
さて、ページには1つのコンポーネントしかありませんが、他にも多くのコンポーネントが存在する可能性があります-それらはどのような順序で接続されるべきですか？ 結局のところ、仕事の終わりにユーザーをサイトのメインページに移動させる何らかのスキン切り替えのモジュールが、交尾期のウサギの数の動態を分析するためのモジュールが完了した後に接続するとバカになります-分析結果が表示されず、計算に時間がかかりません。 したがって、モジュールは接続の順序で指定する必要があります。
このためにnixランレベルの類似物を紹介する人もいます。各モジュールでは、接続するモジュール間で登録する必要があります。 ユーザーとして、この決定は衰弱に陥りましたが、開発者として私はほとんど同じことを思いつきました。モジュールは3つの大きなグループに分かれています。 グループの1つはすでに述べた「コンポーネント」であり、他の2つは、1つのグループのモジュールがコンポーネントの前に接続され、他のグループのモジュールが接続されている点のみが異なります。 さらに、この分離をユーザーから隠し、「コンポーネント」と「モジュールのみ」だけがユーザーに残されました。
そのため、モジュールを設計し、接続を決定しました...次に、その構成方法と許可方法を決定する必要があります。 そして、ここではすべてが単純です：カーネルは汚い仕事のために設計されているため、それを傷つけ、xmlのモジュールが設定のリストを提供し、カーネルにそれを解析させ、保存し、要求に応じて提供しますシンプル。
開発プロセス中に発生した別の問題は、モジュール間のデータの転送です。 パズルの条件に従って、彼らはお互いについて何も知らず、数字の順にカーネルによって呼び出されます。 しかし、あるモジュールから別のモジュールにニュースを送信したいのです！ これを行うために、グローバル変数用の特別なクラスを導入しました。このクラスでは、すべてのモジュールが後続のユーザーのために何かを保存できます。 これはおそらく非常にエレガントなソリューションではありません。
4.アップデート
私は常に最新バージョンを持ちたいのですが、これのために最小限の体の動きを作りたいです。 したがって、更新プロセスを自動化する必要があります。 そして、ここでも、非常に広範囲ではないにしても、ソリューションの動物園があります。 最も進歩的なものは、すべてのディレクトリに777の権利を、ファイルに666の権利を置いてから、「スクリプトがすべてを実行する」ことを提案します。 これがグランドキャニオンほどの大きさのセキュリティホールであるという事実は、一般的に誰も気にしません。
スクリプトには、更新プログラムを一時ディレクトリにダウンロードし、FTPアクセス設定をユーザーに要求した後、それ自体を更新するという2つのオプションのアイデアがありました。 したがって、彼は余分な権限を与える必要はなく、すべてが自動的に行われ、更新はサーバー内で追跡されます...毎回ユーザーにFTPアクセス設定を要求するか、サイトに保存してください...つまり、すべての卵を1つにバスケット。 したがって、私は別のオプションを選択しました：ユーザーは更新を（アーカイブまたはsvn経由で）ダウンロードし、サイトにアップロードし、サイトのコードは「新しい」と感じて、データベースおよび/または設定に必要な修正を加えます...しかし、最初のオプションはより美しい...しかし、私はあえてしませんでした。
これらは私の「自転車の建物」の最も記憶に残るマイルストーンです。 これを読んでいる間、私は仕事の初めにこのようなことをしなかったこと、そして私自身が「正しい」質問をするのに十分な経験とコーンを持っていなかったことを非常に残念に思います。 私が結果として得たものは、
ここで
見ることができ、質問があれば、それらに答える準備ができています。
ちなみに、未回答の質問に対する回答があれば、喜んで聞きます。 結局のところ、経験-それは誰の息子であり、すべての間違いを犯すことはほとんど不可能です;）