|
フロントエンド開発の世界では、エンジンやフレームワークという言葉をよく耳にしますが、エンジンとは一体何なのでしょうか？独自のエンジンはどのように作成するのでしょうか？エンジンを作成する際に注意すべき点は？エンジン技術はどのようなメリットをもたらすのでしょうか？ この記事は、日々の学習やコミュニケーションの中で遭遇する多くの問題から貴重な視点を抽出し、それを皆様と議論することを目的としています。 著者について 51CTO WOTサミットの特別ゲストであるQu Yi氏は、第7回WOTモバイルインターネット開発者会議のゲストスピーカーでもありました。Gaoyang、Kongzhong、Lefengなどの企業でアーキテクト、シニアテクニカルマネージャー、テクニカルディレクターを歴任し、インターネット研究開発に11年の経験を有しています。過去4年間はモバイルインターネットに注力し、中国におけるHTML5のシニアエキスパート兼研究者として、HTML5技術への深い理解と豊富な実務経験を有しています。HTML5エンジンCrow 5の開発者でもあります。ZOL.com.cn、iWeb Summit、GITC Global Internet Conferenceにもゲストおよびエキスパートとして複数回招待されています。
Qilekangのシニアテクニカルディレクター I. エンジンとは一体何でしょうか？軽量フレームワークとは何でしょうか？重量級フレームワークとは何でしょうか？ 実際には、ゲームエンジンは私たちが考えるほど魔法のようなものではありません。より便利にカプセル化されたフレームワークと捉えることができます。エンジン技術は本質的にフレームワーク技術であり、両者の間に根本的な違いはありません。フロントエンド開発においては、jQuery、Zepto、Sea、Kissyといった著名なフレームワークが優れた例です。これらのフレームワークは使いやすく、軽量で、学習曲線が緩やかであることがメリットです。これらのフレームワークはビルディングブロックのようなもので、それぞれ独自の特徴を持ち、特定のユースケースを対象とし、開発における問題点を解決します。例えば、jQueryは多数のJavaScriptメソッドをカプセル化することで、エンジニアを反復的なコーディングから解放し、ブラウザ互換性やアニメーション効果の処理を容易にします。しかし、モバイルプロジェクトでは、jQueryのようなライブラリはあまり実用的ではありません。jQueryはPCブラウザの互換性に関する多くの問題を解決しますが、サイズが大きく、モバイルデバイスとの互換性が低いため、その効果は著しく低下します。そこでZeptoフレームワークが登場します。Zeptoはモバイルデバイス向けに特別に設計されており、サイズが大幅に小さくなっています。例えば、JavaScript モジュールの読み込みに関する問題に対処する場合は、Sea.js を使用できます。Sea は、CommonJS 仕様に準拠した JavaScript モジュール読み込みフレームワークであり、JavaScript モジュールの開発と読み込みを可能にします。 すべてのフレームワークには独自の設計哲学と問題点への解決策があります。その目標は、より少ないコードでより多くの問題を解決し、ユーザーフレンドリーなAPIを提供することです。これらは軽量フレームワークの利点です。しかし、開発者にとっては問題となります。プロジェクトに取り組む際には、数多くの課題に直面します。モジュール開発に加えて、動的ロード、テンプレート技術、アニメーション処理、キャッシュが必要です。より複雑な機能には、地理位置情報や重力センサーが必要になる場合があります。そのため、多数の小規模なフレームワークが必要になります。ライブラリを使用せずにすべてをゼロから作成することは、すべての問題を一つ一つ解決しながら、超高層ビルをゼロから構築するようなものです。ライブラリを使用することは、カードゲームをするようなものです。さまざまな要素を組み合わせて物事を成し遂げるプロセスです。では、これらすべてを一度に処理できる優れたフレームワークは存在するのでしょうか？ 世界は本当に素晴らしい。もしあなたが何かニーズがあれば、誰かがそれを解決してくれる。答えはイエスです。フロントエンド開発の世界、オープンソースの世界では、欲しいものはほとんど何でも見つかります。これは確かに大きな利点ですが、ツールが不足することはありません。そのため、YUI、EXT、Anglar.js、Bootstrapなど、多くの重量級フレームワークが登場しました。これらはすべて重量級フレームワークであり、その利点は標準化、統一性、そして一貫したメトリクスです。コアライブラリをロードするだけでなく、これらの重量級フレームワークは、あらゆるニーズに対応する無数のプラグインを提供しており、非常に便利です。しかし、ここで問題が生じます。第一に、このような重量級フレームワークで実際にどれだけの機能を利用できるのでしょうか？第二に、重量級フレームワークに共通する問題は、プログラマーの思考を制限し、圧制的にしてしまうことです。プログラマーは、彼らのやり方に従ってコードを書くことを強いられます。特定の機能が必要な場合は、機械的にプラグインを探す必要があり、もし完璧に一致するものが見つからない場合は、プラグインを拡張しなければなりません。小さな問題でも解決に永遠に時間がかかることがあります。運が悪ければ、バグの修正が困難になることもあります。こうして多くの柔軟性が失われてしまいます。開発スピードが何を意味するのか、今や誰もが理解しています。さらに、重量級フレームワークの学習はプログラミング言語の学習に間違いなく似ており、チームの学習コストは非常に高くなります。様々な理由から、重量級フレームワークは実際にはあまり使用されていません。依然として、様々なものをつなぎ合わせて作業し、うまく動作しない場合は自分で交換することになります。プログラマーは、既成のパッケージを入手するよりも、自分で組み立てることを好みます。だからこそ、YUIのような重量級フレームワークはもはや更新されていません。 時代も考え方も常に変化し、改訂され続けています。ヘビーウェイトフレームワークには多くの利点がありますが、利用方法の制限やネットワークの制約などにより、市場シェアを独占することはできません。 つまり、重量級フレームワークは多くの軽量フレームワークの機能を統合し、統一されたコーディングルールを提供します。また、多くの小規模フレームワークを統合することで、断片的なアプローチを回避します。しかし、柔軟性が失われ、開発が困難になり、拡張性が阻害され、学習曲線が長くなります。 では、エンジンとは一体何でしょうか？まず、エンジンはフレームワークです。そして、エンジンは軽量であること、つまり小さく、高速で、プラグインであり、パターンであるという利点を持つべきです。同時に、重量級フレームワークの考え方も持ち、断片的なアプローチを避けるための統一された方法論を提供するべきです。同時に、エンジンは重量級フレームワークのように開発を束縛するのではなく、開発者が柔軟に利用できる方法を提供するべきです。 II. エンジン技術はどのようにして生まれたのでしょうか? エンジン技術は軽量フレームワークの利点を活用すべきです。プラグイン開発は非侵入的かつアスペクト指向で、必要な時に利用し、不要な時には簡単に抽出できるようにする必要があります。エンジンは重量級フレームワークから学び続け、統一されたアプローチを採用することで、可能な限り多くの問題に対処する包括的なソリューションを提供する必要があります。 私たちがコーディング時に最もよく用いるアイデアの一つはカプセル化です。これはフレームワークやエンジン技術においても重要な概念です。まず、操作クラス、アニメーションクラス、レンダリングクラス、ビジネスロジッククラスなどをカプセル化し、さらに細かい粒度を抽出できないか検討し、それらをクラスライブラリとしてカプセル化します。そして、適切なディレクトリと命名規則に従って保存します。これにより、クラスライブラリは参照しやすくなり、適切なロードとスケジューリング方法を提供することで、コードを統合します。プログラマーは開発中に、これらの様々な粒度を持つライブラリを継続的に拡張していきます。将来の開発は、積み木を積み上げて構築するようなものになります。こうして、私たちのプロジェクトに適したシンプルなフレームワークは既に形作られています。 しかし、これだけでは到底不十分です。少なくとも一つの重要な要素、つまりルールが欠けているからです。コードを積み木のように書くことで面倒なコーディングを減らすことはできますが、それでもコードを構築するプロセスは依然として存在します。例えば、ある機能を開発する際には、テンプレートリソースの読み込み、データのリクエスト、レンダリング、イベント処理など、一見異なるタスクが常に存在しますが、その方法論は無数に繰り返されます。これらの反復プロセスをルール化し、コードが特定の関係性に基づいてこれらの反復タスクを自動的に実行できるようにできたらどうなるでしょうか。そうすれば、機械的で反復的なコード構築を大幅に削減できるでしょう。 この考えに基づいて、ルールエンジンを設計しました。Crow5はこの指針のもとに誕生しました。コード生成を完全に自動化することは不可能ですが、可能な限り多くのコードを生成するように努めるべきです。では、どうすれば特定のロジックに従ってコードを自動生成できるのでしょうか？答えはシンプルです。私が与えた命令を読み取り、それを使ってコード構築プロセスを完了するだけのカーネルを作成しました。では、これらの命令とは何でしょうか？それは、このカーネルに提供する設定ファイルです。この考え方から、以下の設計が生まれました。 以前は、制御、サービス、モジュール、DAOといったレイヤーで機能を処理するためのモジュール型開発アプローチを採用していました。しかし、このアプローチは変わりました。レイヤー型開発では、カーネルがコードをアセンブルし、開発者は指示を提供するだけで済みます。 上の画像に示すように、コードの書き方が変わりました。以前は、ロジック制御コードや関数コードなどを記述する必要がありました。今では、設定ファイルと呼ばれるディレクティブを提供するだけで済みます。 #p# III. ニーズに適したエンジンをどのように抽出するか? コア参照ライブラリを抽出し、ロジック コントロールを抽出し、プレゼンテーションを抽出し、ビジネス ロジックを抽出します。 IV. エンジンを作成する場合、最低限実現する必要がある機能は何でしょうか？（エンジンがエンジンとみなされるための最低限の要件は何でしょうか？） エンジンの構築に必要なものを明確に規定したルールはありませんが、ここでは参考となる計画を示します。エンジンを他の人と共有する場合は、少なくとも以下の処理メカニズムを備えている必要があります。つまり、作成したライブラリを他の人が簡単に利用できるように設計する必要があります。 コード規則パターン、インタラクション抽出パターン、データカプセル化パターン、暗号化および難読化メカニズム、ユーティリティクラスパッケージ、プラグイン管理モジュール、ローダー、インターセプター、アニメーション処理モジュール、キャッシュコントローラ、タイムアウトリスナー、テンプレート制御エンジン、パフォーマンス処理モジュール（遅延読み込み、オンデマンド読み込み、アクセラレータ）、ビジネスロジック制御ファクトリー、操作ログ管理。 もちろん、プロジェクトに応じて様々な特別なモジュールがあります。例えば、クライアントが解凍を必要とする場合は、リクエストプロキシモジュールを設計できます。 開発者が設定やコード記述を行えるように、APIレイヤーも提供する必要があります。もちろん、包括的なユーザーマニュアルも必要です。 V. コンベンションベースプログラミングとは何ですか？エンジン技術とどのように関係しているのでしょうか？ プログラミングにおいて、コードサイズを最小限に抑える最も直感的な方法は、規約を利用することです。例えば、Springは規約パターンの要素を取り入れています。そのため、Crow5の設計では規約パターンを多用しました。 簡単に言えば、ページ名が `index.html` の場合、コントローラー呼び出しの名前は `UI.index` になります。ページへのAPIリクエストは `romote_index` と定義できます。テンプレート名は `index_tpl` です。AJAX処理のイベントバインディング関数は `___index` と定義できます。処理ロジックのすべてのエントリポイントと名前を定義できます。この規則により、類似するコードはすべてルールを持ち、ルールエンジンに抽象化できます。その後、パラメータと設定を渡すだけで、ルールに従ってコードが自動的に生成されます。 上記のページはすべてエンジンによって自動的に生成されたものです。コードを見てみましょう。 記述するコードは設定ファイルであり、それ以外のコードはエンジンによって自動的に処理されます。パフォーマンス処理はすべて設定可能です。これにより、コーディングの繰り返し作業が大幅に削減されます。 6. エンジン技術に関する研究の将来について教えてください。 今後の研究は、セマンティック抽出に焦点を当てます。すべてのエンジンコードは、クラウドプラットフォームを介してオンデマンドで自動的に割り当てられ、プロジェクトのエンジンコアが生成されます。設定ファイルはプラットフォームの設定に基づいて自動的に生成されます。これにより、アプリやデモの開発時に自動生成が可能になります。 探求は終わりがなく、多くのインスピレーションが必要です。デザインのインスピレーションの多くは動物から来ています。例えば、心拍維持技術を設計する際には、冬眠中のカエルを観察し、心拍の加速、減速、停止、そして覚醒といった一連の動きを抽出し、要約しました。私たちはエンジン技術をセマンティックな方向に推し進めていきたいと考えています。そしてその時、プログラミングは質疑応答のプロセスになるかもしれません。 |
