内部からのフロントエンド島

こんにちは、私の名前はIgor（ iamo0 ）です。私はOstrovokのシニアフロントエンド開発者です。 主な製品であるOstrovok.ruの Webサイトに従事しています。 何千人もの人々が当社のウェブサイトを使用して毎日ホテルを予約しているため、当社の製品の品質が最高であることは非常に重要です。 そして、このためには、あらゆる種類のささいなことに気を取られて、タスクを効果的に解決できる必要はありません。

フロントエンド開発プロセスをどのように編成して、タスク自体に焦点を当てて、それらを解決する方法を考えることなくタスクを解決できるようにする方法を説明します。

私の物語が表紙を破ったり、本当の啓示になったりするふりはしません。 Ostrovkaの開発者が蓄積した大規模なアプリケーションの経験を共有したいと思います。

チームワーク

バス番号

フロントエンドのOstrovkaに関与するチームは9人を雇用しています。 原則として、2人の開発者がコードの書き方についてコンセンサスを得ることは簡単ではありません（ こんにちは、エクストラネット ;-)。9について言えます。 一方、プロジェクトのアーキテクチャを明確かつ簡潔に、コードを読みやすく保守しやすいものにする必要があります。 最近チームに加わった新人や、別のプロジェクトに切り替えなければならない人が、コードをすぐに理解できることが重要です。

マネージャーと開発者には「バス番号」という用語があります。 これは、プロジェクトがサポートできなくなるためにバスにぶつかる必要がある開発者の数です。 最悪の場合、バス番号は1です。 私たちのタスクは、バス番号を最大化することです。理想的には、それは開発者の数と等しくなければなりません。

すべての開発者が同じスタイルでコードを記述し、プロジェクトのこれらの部分で行われていないことを知っていれば、高いバス数を簡単に達成できます。

ガイドライン

開発者が同じスタイルでコードを書くためのガイドラインがあります。 内部リソースの1つで、開発者はコードのフォーマットに関するルールだけでなく、プロジェクトのエコシステムの機能（ファイルの保存場所と保存方法、プロジェクトの編成方法、コードを書くためのいくつかのルール。

プロジェクトで使用される最も重要なルールの1つは、jsDocを使用したコードの必須ドキュメントです（ http://code.google.com/p/jsdoc-toolkit/、https://developers.google.com/closure/compiler/docs / js-for-compiler ）。 jsDocを使用すると大きな利点があります。 まず、コードの可読性が向上します。 第二に、多くのIDEでは、jsDocを使用するプロジェクトでナビゲートするのが非常に便利です。 vimのような単純なテキストエディタを使用して自分の足を撃ちたい人は、jsDoc-toolkitに付属のコンソールユーティリティを使用して、ドキュメントをHTMLファイルにコンパイルできます。 そして最後に、jsDocを正しく作成するために、開発者は頭の中ですべてを整理する必要があります。

コードレビュー

バス番号を増やすための2番目の条件-プロジェクトの他の部分のコードの詳細に関する開発者の知識-は、OstrovokでWTF（コードを見ていない開発者の最初の反応）と呼ばれるコードレビューシステムを使用して達成されます。

私たちのチームではすべてが信頼に基づいて構築されており、ロッドを持つ残酷なボスはいないので、すべての開発者のコ​​ードをフォローする人は一人もいません。 コードを投稿する前に、開発者自身がコードの確認を仲間に依頼します。 第一に、これは検査官と監査人の両方の責任に良い影響を与えます。第二に、各開発者は自分のコードを繰り返し見て自分が公開する許可を与えたため、隣人が何をどのように行うかを知っています。

開発機能

各企業の開発アプローチは、プロジェクトの特性とプロジェクトに取り組んでいるチームに基づいて構築されています。 Ostrovokでは、フロントエンドに十分な重点が置かれています。 このアプローチは歴史的に発展してきました。さらに、多数の開発者と適切に機能するシステムがこのアプローチを支持しています。

フロントエンドの助けを借りて、一見非定型の多数のタスクを解決し、強力なユーザーインターフェイスを実装できます。 たとえば、私たちの検索結果は、ほとんどすべての情報がクライアント側で発生するように機能します。 バックエンドは、利用可能なホテルのリストをJSONの形式で表示するという事実に関与しており、フロントエンドは、ホテルの一覧表示、地図上でのホテルの描画、並べ替え、フィルタリングに既に関与しています。

星の数や部屋のコストなど、検索結果のフィルターを変更してみてください-すべての計算はクライアントで行われるため、ホテルのリストは即座に更新されます。 大量のデータを扱うという事実にもかかわらず（たとえば、ロンドンには2,000を超えるホテルがあります）、サイトはユーザーの要求に非常に迅速に応答します。

Javascript

クライアント側をこのように重視するためには、コードを慎重に編成および構造化する必要があります。 モジュラーOOPベースの開発アプローチを選択しました。 これは、JavaScriptが提供するクラス、継承、弱いバインディング、およびその他のOOP機能を積極的に使用していることを意味します。

各ページには、いくつかのネストされたモジュールを含む個別のJavaScriptクラスがあります。これらのモジュールは、無限にフラグメント化することもできます。

基本モジュールクラスを作成しました。 イベントの操作に加えて、彼はほとんど何も知りませんが、最終的には、ページ、検索フォームコントローラー、またはカレンダーなど、他のすべてのモジュールが彼から継承されます。 各ページには、このページのクラスインスタンスが単純に作成され、初期化が行われるエントリポイントがあります。

このアプローチを説明するために、かなり粗雑なコード例を示します。 サブスクリプション用の電子メール入力フォームのあるページがあると想像してください。

このコードを次のように整理します。

//base.js /** * @fileoverview Sperical code in vacuum for Habrahabr.ru * @author Igor Alexeenko (habrahabr.ru/users/iamo0) */ /** Project namespace */ var ota = {}; /** * Inheritance interface. Uses temporary constructor. * @param {Function} childCtor * @param {Function} parentCtor */ ota.inherit = function(childCtor, parentCtor) { var temporaryCtor = function() {}; temporaryCtor.prototype = parentCtor.prototype; childCtor.prototype = new temporaryCtor; childCtor.prototype.constructor = childCtor; // Link to parent's prototype. childCtor._super = parentCtor.prototype; }; /** * Base module. It's not necessary, to implement full base class in simple * example, so let it just be an empty class, inherited from Object. * @constructor * @extends {Object} */ ota.BaseModule = function() {}; ota.inherit(ota.BaseModule, Object); 

 //page.js /** * @fileoverview Page controller. * @author Igor Alexeenko (o0@ostrovok.ru) */ /** * @constructor * @extends {ota.BaseModule} */ ota.Page = function() { this._form = new ota.EmailForm; }; ota.inherit(ota.Page, ota.BaseModule); 

 //searchform.js /** * @fileoverview Email form. * @author Igor Alexeenko (alexeenko.igor@gmail.com) */ /** * @constructor * @extends {ota.BaseModule} */ ota.EmailForm = function() { this._formElement = document.querySelector('.' + ota.EmailForm.CLASS_NAME); this._formElement.addEventListener( 'submit', ota.EmailForm.getEventHandler(this, this._onSubmit) ); }; ota.inherit(ota.EmailForm, ota.BaseModule); /** * Class name, which uses for match DOM-element. * @const * @type {string} */ ota.EmailForm.CLASS_NAME = 'form-element'; /** * Error message, which displays if user, entered wrong email address. * @const * @type {string} */ ota.EmailForm.EMAIL_ERROR_MESSAGE = ( ', ,    .' ); /** * @const * @type {RegExp} */ ota.EmailForm.EMAIL_REGEXP = ( /^[a-zA-Z0-9-_.+]{1,}@[a-zA-Z0-9-_.]{2,}\.[a-zA-Z]{2,}$/ ); /** * Static method. Returns event handler with certain context. * @param {Object} context * @param {Function} handler * @return {Function} */ ota.EmailForm.getEventHandler = function(context, handler) { return function(event) { handler.call(context, event); }; }; /** * Form submit handler. Alerts an error if email field is empty or its value * is invalid. Otherwise, submits the form. * @param {Event} event * @private */ ota.EmailForm.prototype._onSubmit = function(event) { event.preventDefault(); var formIsValid = this.validateForm(); var emailField = this._formElement.elements[0]; if (!formIsValid) { alert(ota.EmailForm.EMAIL_ERROR_MESSAGE); emailField.focus(); return; } this._formElement.submit(); }; /** * Form validator. Returns true if email field value is valid. * @return {boolean} */ ota.EmailForm.prototype.validateForm = function() { var emailField = this._formElement.elements[0]; var emailValue = emailField.value; return (emailValue !== '' && ota.EmailForm.EMAIL_REGEXP.test(emailValue)); }; 

さて、これを機能させるには、HTMLページに次のコードを挿入するだけで十分です。もちろん、最初に必要なすべてのファイルを接続します。

 <script> new ota.Page; </script> 

この例では、使用するツールとの会話を減らすためではなく、意図的にライブラリを使用してアプローチの本質を示しませんでした。

もちろん、このような小さなタスクを解決するために、コードは非常に多くなることが判明しましたが、同じページに検索フォームがあると想像した場合、 無限スクロールのホテルのリスト。 マークされたホテルのあるマップ、およびリスト内のホテルにカーソルを合わせると、マップ上のマーカーが強調表示されます。 状態の変化によりリストとマップの両方が更新されるはずのいくつかのフィルター-このアプローチは正当化され、非常に便利になります。

さらに、この開発アプローチにより、プロジェクトコードは柔軟になり、重要な状況に簡単に適応できるようになります。 たとえば、開発者がメインページからではなく、検索クエリによってサイトにアクセスしたユーザーの発行ページをカスタマイズするタスクに直面している場合、タスクは子クラスの作成と親クラスのいくつかのメソッドのオーバーライドに制限されます。


モスクワのカスタマイズされた通常の検索結果（高解像度）。

マークアップとスタイル

もちろん、コードの慎重な編成はJavaScriptだけでなく、組版（サーバーとクライアントのテンプレートおよびCSS）にも適用されます。 レイアウトの要件は、JavaScriptアプリケーションの場合と同じです：モジュール性、柔軟性、カスタマイズ性、簡単な継承。 幸運なことに、これらの要件に適した、かなりよく確立された実証済みのコード編成システムがあります。 これはBEM（ http://ru.bem.info/method/、http://clubs.ya.ru/bem/ ）です。

マークアップとスタイルには、いくつかの機能はありますが、BEM手法を使用します。 まず、BEMはJavaScriptシステムではうまく機能しないため、jsファイルを個別に保存し、独自の順序で整理します。次に、シンプルではなくSCSS（ http://sass-lang.com/ ）を使用しますCSS

クライアントテンプレート

ほとんどのロジックはJavaScriptで実装されているため、クライアントテンプレートを積極的に使用しています。 最初は、underscore.jsライブラリー（ http://underscorejs.org/ ）に組み込まれたテンプレートエンジンを使用しましたが、それが不便であることをすぐに認識しました。 まず、テンプレートを別のファイルに保存したかった。次に、テンプレートをJavaScriptの文字列変数ではなく、vimのようなテキストエディターでのマークアップの作成が実行に似ているようにしたかった。

さらに、ユーザーのマシンのリソースが複雑な文字列変換で無駄にならないように、これらのテンプレートをプリコンパイルしておくといいと思いました。

インフラストラクチャ部門は、テンプレートを作成して支援を行いました。 JST-JavaScript Templatesと名付けました。 主な構文はunderscore.jsから残されていましたが、テンプレートがjst拡張子を持つ外部ファイルに保存され、プロジェクトのビルド段階でも自動的にJavaScript関数にコンパイルされるように作成されました。 コンパイルされたテンプレートは、通常のjsファイルとしてプロジェクトに接続されます。

 <!-- path/to/template.jst --> <ul> <% elements.forEach(element, function(el, index) { %> <li><%= element.name %></li> <% }) %> </ul> 

テンプレートには別の名前空間が入力され、テンプレート識別子はプロジェクト内のパスです。

 // some_file.js var template = templateNs['path/to/template.jst']; var list = [ { name: '' }, { name: '' }, { name: '' } ]; var renderedHtml = template.render({ elements: list }); document.body.innerHTML = renderedHtml; 

クライアントテンプレートの操作は、組版に携わる人とJavaScriptを書く人の両方にとって非常に便利になりました。

依存関係とプロジェクトのビルド

各JavaScriptクラスには独自の依存関係システムがあるため、必要なすべてのファイルを手作業で接続することはほとんど不可能であり、何らかの方法でコードを縮小する必要があります。 このような複雑なシステムでは、多数のファイルを作成する必要があるため、効果的なビルドシステムが必要です。 このシステムを作成する際に、インフラストラクチャ部門が再び私たちを助けました。

プロジェクトをビルドするサービスはmediageneratorと呼ばれ、開発者の1人によって作成されました。 このサービスは、特別なタグの使用に基づいてプロジェクト内の依存関係を収集します。

例に戻りましょう。 主にページ用のpage.jsファイル、base.jsおよびsearchform.jsファイルを含めるには、page.js内に依存関係を登録する必要があります。 これらは、jsDocの@requireタグに登録されます。 必要なファイルを接続するには、page.jsファイルに、たとえば@fileoverviewブロックのどこかに2つのタグを追加するだけで十分であることがわかります。

 /** * @fileoverview Page controller * @author Igor Alexeenko (twitter.com/iamo0) * @require 'base.js' * @require 'searchform.js' */ 

それだけです デバッグモードでは、2つの<script>タグがページに追加され、必要なファイルが含まれます。 そして、プロダクションモードでは、メディアジェネレーターはこれら3つのファイルすべてを1つに接着して、ミニファイヤに渡します。 もちろん、彼は複雑な依存関係を追跡する方法を知っており、1つのファイルを何度も添付することはありません。

さらに、jst-templatesとSCSSをコンパイルし、写真をキャッシュし、プロジェクトを組み立てるすべての黒い作業を行うのはメディアジェネレーターです。 したがって、フロントエンド開発者は、手元のタスクにのみ集中できます。

私たちは何をするつもりですか

古いプログラミングのジョークがあります。十分に複雑なCまたはFortranプログラムには、Common Lisp言語の半分の、新しく作成された、不特定の、バグがあり、遅い実装が含まれています。

フロントエンド開発者にとって、このジョークは次のように言い換えることができます。jQuery、Backbone、またはKnockout.js（ http://jquery.com/、http://backbonejs.org/またはhttp：// knockoutjsで記述されたかなり複雑なプロジェクト。 com / ）、Google Closure Tools（ https://developers.google.com/closure/ ）の半分の、新しく書かれたバグのある遅い実装が含まれています 。

実際、ここで私が話したことはすべて、モジュール性、OOPアプローチ、継承できる基本的なモジュールセットの存在、スタイルの操作、プリコンパイルされたテンプレート-はGoogle Closureエコシステムにあります。 Google Closure Library JavaScriptライブラリに加えて、このシステムにはGoogle Closure Compiler JSミニファイアーも含まれています。 サーバーテンプレートとクライアントテンプレートの両方にコンパイルする大豆テンプレートエンジン。 また、Google Closure Compilerと統合されたスタイル言語により、cssクラスの名前さえも縮小できます（BEMを使用する開発者にとっての青い夢）。

クロージャーツールは、2005年からGoogleが独自のプロジェクト向けに開発したものです。 最初に、ライブラリはGMailメーラーのニーズに合わせて作成され、その後、他のすべてのGoogleプロジェクトはそれを使用して書き直されました。 Closure Library JavaScriptライブラリのコードベースだけでも約8MBの重さがあり、複雑なプロジェクトを開発するために必要なものがすべて含まれています。

このライブラリには、かなり複雑なインフラストラクチャと高いエントリしきい値があります。 市場で入手可能なソリューションを使用することに慣れているプログラマーがClosureに切り替えるのは非常に困難ですが、このライブラリを使用するとプロジェクトの品質が大幅に向上します。

この世界のすべては、何らかのプーシキンによってすでに書かれています：中規模/大規模プロジェクトの多くの開発者がゼロから開発するときに直面するタスクのほとんどは、無限の数のサービスを作成する過程でGoogleエンジニアによって既に解決されています。

この秋、Ostrovkaの新しいバージョンのリリースが準備されており、現在Google Closureを使用して開発されています。 新しいOstrovkaの主な機能は、単一ページのアプリケーションであることです。 これは、ページ間の移動、アドレスバーの操作、データの読み込み、ページのレンダリングのすべてのロジックがクライアント側に移動することを意味します。 プロジェクト開発の複雑さは、サイトの速度とより便利なユーザーインターフェイスによって相殺されます。

もちろん、Google Closureへの移行に伴い、開発へのアプローチを変更する必要がありました。たとえば、この方法論のいくつかの欠点とGoogle Closureプロジェクトのインフラストラクチャとの弱い互換性のためにBEMを放棄しなければなりませんでしたが、建設に関する見解プロジェクトは同じままです。