2013年2月9日に東京で開催されたイベント「Frontrend Vol.4」に参加してきました。

Frontrendとは

名前の通り、フロントエンド技術にフォーカスを当てた勉強会です。
サイバーエージェント所属のエンジニアさんの最先端かつ尖った話を聞くことができます。

今回のテーマ

• JavaScript Development Tools - JavaScript開発の効率アップ
• jQuery Performance Tips - jQueryにおける高速化 -
• Testable Javascript - テストしやすいJavaScriptとテストについて -
• jQuery to Backbone - アーキテクチャを意識したJavaScript入門

参加してみた感想

全体的に良い話が多く、もっと聞きたい！と思う内容でした。

特に3つ目の「ユニットテスト」と4つ目の「Backbone.js」に関しては、 これまで触れたことの無い分野だったので、すごく新鮮でした。
どちらも話しているテーマは異なっていても、根本的なところは一緒で、 「Javascriptの設計」に関する話であると聞いていて思いました。

普段業務でそこまでjavascriptを書かないこともあり、jQueryプラグインを 使ってのその場しのぎだったり、過去のサイトからコピペしたりと、設計について そこまで真剣に考えたことがこれまでありませんでした。

今後は「ただ動くものを作る」から「品質が高く、メンテしやすいものを作る」に 徐々に考え方を変えて、書く際に意識をしていきたいと思いました。

また単純に最近のWebサービス・アプリで主流になりつつある、「シングルページ、リッチ＆シームレス RESTful API 」に興味があるので、まずは簡単なサービスを1つ作ってみる予定です。

以下は自分のまとめメモです。もしよかったら、ご覧ください。
結構自分の私感が入っていますので、そこだけご注意ください。

JavaScript Development Tools

• ひらきさとる さん
• Javascriptツール初心者→脱初心者へ
• Crome Dev tools
  • BreakPoint
    • Event
    • XHR
    • DOM change
  • TimeLine
  • Profile
• Charles（チャールズ）
  • デバッグ用Proxy
  • MAP Local
    • 外部サーバのファイルのエミュレート
  • Throttle
    • 回線速度エミュレート
• DocHub
  • jQuery等々のドキュメント
• jsperf
  • jsの実行スピードテスト
• jshint
  • シンタックスチェッカー
• jq
  • JSONパーサー
• Doctor JS
  • jsの関数リストを作成、該当エディタでIDEライクに
• Yeoman,Nodefront
  • Node.js製の様々な開発ツールを寄せ集めてパッケージングしたもの
• まとめ
  • 最近のJavaScript開発には便利なツールが いっぱい
  • 不便だなと思ったらツールを探してみると生産性UP
  • 特にCUIツールは「黒い画面」だからと尻込み しないで使うと幸せになれる

jQuery Performance Tips

• みずのはやと さん
• 速く動くコードの書き方
  • 速くするにはマシンの仕事を少なくしろ
  • シンプル！
• jQueryは開発者の中の共通言語になっている
• パフォーマンスと可読性はトレードオフになりやすいので、及第点を見つける
• ファイルサイズを減らす
  • 1kbにつき1msのパース時間がかかる
  • IEと他のモダンブラウザで別のjQueryを読みこませる（CCタグ）
  • grunt.jsでカスタムビルド
• セレクタのチューニング
  • querySelecterAllよりgetElementBy...を使うようにする
  • セレクタを分解する（findを使う）
  • キャッシュを活用する
  • $()が実際にどのような処理がされるかを考える
  • コスト：ブラウザネイティブ＜＜jQuery独自
• リフローの影響を考える
  • DOMツリーとレンダーツリー
    • DOMツリー=実際のHTML構造
    • レンダーツリー=見た目の構造
  • ブラウザの再描画処理
    • リペイント（色の変化など）
    • リフロー（display,margin,padding,borderなど配置変更に関わる変更の際に発生する）
  • リフローのトリガー
    • CSSの変更
    • DOM操作
    • 特定プロパティの取得
    • ユーザ操作（スクロールなど）
  • 不要なリフロー・リペイントを避ける
    • CromeのDevTool>Timelineでアタリをつける
    • 高コストの処理から削っていく
      • opacity,gradient..
      • animate
      • each
      • scroll,resize
    • scroll,resize,keyupなどの都度発生するイベントは適当に間引くことも有効（throttle...)
  • スタイルの変更はできるだけ末端要素で行う
  • jsで直接スタイルを変更するのではなく、クラスの付け替えで書くようにする

Testable Javascript

• さいとうゆうや さん
• 先人のベストプラクティスを取り入れる
  • オブジェクト指向Javascript
  • デザインパターン
  • MV*
  • ユニットテスト
• 何故テストが必要なのか？
  • "テストにではなく、動作するコードにお金を 払って貰っているのだから、 一定レベルの確信が得られる最小限のテストを 行うことが私のフィロソフィーだ[...]。
    • Kent Beck on StackOverflow
  • Javascriptが「本物」のプログラミング言語へ進化を遂げた（から）→品質が求められる
  • 今動いているのだからそれでいい、はもはや現実的ではない→リファクタリングを前提で考える
  • ロジックにもデザイン（パターン）がある
  • 一貫性と確実性を持つロジックにはテストが必須
• テストしやすいJavascriptとは
  • テストを書くのが難しい、のではなく、 テストをしているコードに問題があると 考える方が自然。
  • コードの役割を考える（DOM操作・データ取得・HTML作成、ネットワークIOなど）
  • 役割ごとにコードを分割して書く
  • 1モジュール＝1機能=1テスト(testable)
  • コードの役割分担が複雑で、 コードの役割が密接な関係を持っていると テストを行うことが難しくなる。
  • テストしやすいコード=見通しの良いコード
• ユニットテストのテストツール
  • QUNIT
  • JASMINE
  • MOCHA
• テストの工程を自動化する
  • grunt.js
  • 環境を整えてしまえば、言い訳はしづらくなる
  • プログラマの才能は「面倒くさがり」であること。
  • 『 面倒な繰り返しになることは自動化し、 大事なことに時間を割けるようにする』
• まとめ
  • 成功は失敗から生まれる
  • まずはテストを書いてみること
  • テストは問題解決へのガイドになる

jQuery to Backbone

• さとうあゆむ さん
• jQueryのよいところ
  • DOMを隠蔽して簡潔にかける
  • イベントを隠蔽してくれて、クロスブラウザ
  • プラグインの充実とエコシステム形成
• フロントエンド実装の比重の変化
  • 新しめなWebサービス・アプリはシングルページ、リッチ＆シームレス RESTful API
• jQueryが解決しない問題
  • アプリケーションコードの肥大化
  • スパゲティコードの技術的負債
  • テスタビリティの確保
  • メンテナンスのたびに深まる業
• デザインパターンは知っておくべき
  • Javascript Design Patterns
  • すべてがデザインパターンに当てはまることはない
  • デザインパターンから一般的なパターンを学ぶ
• jQuery to Backbone
  • コードを構造化する
  • Backbone.jsをきっかけに構造化を学ぶ