大規模なJavaScript開発の話

27,946 views

Published on

大なごやJS#3(2012/07/21)で使ったスライドです。割と「当たり前のこと」をまとめなおしただけな感じです。

Published in: Technology
0 Comments
71 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
27,946
On SlideShare
0
From Embeds
0
Number of Embeds
368
Actions
Shares
0
Downloads
117
Comments
0
Likes
71
Embeds 0
No embeds

No notes for slide

大規模なJavaScript開発の話

  1. 1. 大規模なJavaScript開発の話terurou/YAGI.Teruo
  2. 2. 自己紹介 2
  3. 3. terurouです。• Web・GUI・分散処理を手広くやってます – Windows 8(Metro Style Apps), Silverlight, JavaScript, Android, … – Cassandra, 自作KVS, AWS, … – DataGridの自作に定評があるらしいです• フロントエンド寄りのアーキテクチャの設計が 割と得意です – MVC/MVVM, Client-side Cache, 通信, … 3
  4. 4. 大規模なJavaScript開発とは? 4
  5. 5. 私の大規模プロジェクト経験• 大規模なJavaScriptプロジェクト経験は2回 – 似たところではSilverlightの大規模プロジェクトも• 全て業務系システム開発プロジェクト – Web/ゲーム系のことはわからないです – 基本的なことは同じだと思いますが… 5
  6. 6. 私の関わった大規模JavaScript開発(1)• SaaS セルフカスタマイズエンジン – Salseforce.comみたいなやつ• 5人体制(JS担当者は2名) – プロジェクト全体では50名体制• 開発規模:数万行(記憶があいまい) – ライブラリ未使用、フルスクラッチ – 現在のスキルであれば25K行程度で作れそう 6
  7. 7. 私の関わった大規模JavaScript開発(2)• SaaS フレームワーク – 現在進行中• 6人体制(JS担当者は3名) – プロジェクト全体では最大30名程度になる?• 開発規模は30K行程度に収まる? – Ext.JS利用、DataGrid自作 7
  8. 8. 「大規模」の定義が難しいですが…• 単純にステップ数が多いアプリケーション – 並みの規模だとJS単体で10K行は超えない – cybozu.comがJS単体で65K行程度らしい • http://b.hatena.ne.jp/articles/201112/6709• 開発人員が多い – プロジェクト全体では数十名規模とか… 8
  9. 9. 大規模プロジェクトでのチーム構成• PMO(Project Management Office) – プロジェクト管理• 共通基盤チーム – フレームワーク開発、インフラ整備など• アプリケーションチーム(業務チーム) – 機能設計、実装など – このチームが一番人数が多くなるはず• その他に企画、品質管理、保守運営など 9
  10. 10. 大規模プロジェクトでのチーム構成• PMO(Project Management Office) – プロジェクト管理• 共通基盤チーム ← 今回話す範囲 – フレームワーク開発、インフラ整備など• アプリケーションチーム(業務チーム) – 機能設計、実装など – このチームが一番人数が多くなるはず• その他に企画、品質管理、保守運営など 10
  11. 11. 大規模プロジェクトでの基盤開発で意識すべきこと 11
  12. 12. 大規模プロジェクトならでは「急所」• どうしても「変更」に対して弱くなりがち – チーム制による分業のため、変更発生時には 関係各所との調整が必要 • 人数が多い分だけオーバーヘッドが大きくなる – 問題の発覚が遅くなるほど影響が大きくなり、 最悪のケースはプロジェクトが頓挫することも• プロジェクトメンバのスキルのばらつき – 対策をしなければ、生産性、品質、保守性に 大きな影響が出てしまう 12
  13. 13. どのように「急所」に向き合うか• 早期の技術検証/プロトタイピング – プロジェクトの序盤に問題点をクリアしておけば、 後から変更をする必要がない• 「できていいことだけができる」環境を作る – コードの品質(保守性・可読性)がメンバーの スキルに影響されないようにする – 品質が高レベルで安定していれば、もし変更が 必要になっても対応しやすい 13
  14. 14. 技術検証/プロトタイピングで注意すること• 些細なことでも必ず検証するのが理想 – 「実現できるはず」という思い込みをしていても、 実は実現できないことは多々ある• あまり作りこみ過ぎない – 所詮は検証用、書き捨てコードでOK• 目的(何を検証したいのか)を見失わない – 実装可能? パフォーマンス? 生産性? ユーザビリティ? … 14
  15. 15. 「できていいことだけができる」環境• プロジェクトに特化したフレームワークを作り、 実装パターンを単一化/テンプレート化する – 「穴埋め実装すればアプリが作れます!」 – 必要な機能を提供しつつ、不要な機能は隠す • 汎用化≒複雑化、保守性・学習性が落ちる • OSSのフレームワークを導入しただけではダメ• 規約での制限は最後の手段 – コードの品質が実装スキル、規約の理解度に 依存してしまう 15
  16. 16. ちょっと難しく書きすぎた…• 一人プロジェクトと大差はない – 「画面ごとに実装方法やクラス構成が違う」とか わざわざやらないよね• 大規模開発は小規模開発のサブセット – と、前に誰かが言っていたような気がする – 「自分ならこう書く」を分業体制でやるためには 段取りが必要 – どれだけうまく環境構築しても、基盤チームの 実力以上の品質にはならない 16
  17. 17. JavaScriptでの大規模開発 17
  18. 18. JavaScriptは大規模開発に向いていない• 言語仕様が柔軟すぎる – 「クラス的なもの」ですら書き方がいくらでもある – prototypeを拡張/改変できる • ECMAScript 5なら制限できるけど…• モダンな書き方をするとコードが冗長に – var前置、stacktrace対策(function名を明記)• そもそもGUIを作るにはAPIが貧弱 – jQuery UIやExt.JS等の範囲内ならよいが… 18
  19. 19. JavaScriptエンジニアが少ない問題• 「jQueryできます!」とか言われましても… – 案件によってはそれでもいいのだけど… – それで済む時はJavaScript部分は小規模…• そもそもJavaScriptは難しい – prototype型のオブジェクト指向言語 – HTML/CSS、クロスブラウザ、ブラウザハック – GUI実装パターン(MVC)の知識 – など、覚えないといけないこと沢山 19
  20. 20. 柔軟すぎる言語仕様への対策• JavaScriptを生成する言語の採用 – CoffeeScript, Haxe(, JSX, and more) – 個人的にはHaxe押し• JavaScriptで開発する場合、モジュールや クラスの書き方は必ず統一する – 開発ガイドやコーディング規約書が必須 – jsdocコメントも必須にすべき • Closure Compilerがコメントを元にチェックしてくれる 20
  21. 21. Haxe• 静的型付けのオブジェクト指向言語 – C#やActionScript3(ECMAScript4)に似た構文 – 型安全、コンパイル時の型チェック – 型推論や構造的部分型などの機能のおかげで JavaScriptより簡潔にコードを書ける• インライン展開やマクロにより、現実的には 人の手では行えない最適化が可能• コンパイルが速い 21
  22. 22. Haxeで解決できるJavaScriptあるある1. ライブラリの関数の定義変更が発生2. 呼び出し側を1か所だけ直し忘れる3. 忘れたころにバグに遭遇… – 原因がわかりにくいパターン一方Haxeはコンパイラが修正漏れを検出した 22
  23. 23. JavaScript MVC• ViewとModelを分離することで分業しやすい – デザイナとプログラマ – JavaScriptハッカーとプログラマ • 難しいViewはJavaScriptハッカーに委ねる• 保守性・可読性の向上• MVCライブラリはいろいろある – Backbone.js, Ember.js, Spine, AngularJS, … 23
  24. 24. MVCライブラリだけでは足りない部分• Modelのモジュール構成 – Template Methodパターン – Facade/Mediatorパターン – Factory Method/Abstract Factoryパターン – Observerパターン(MVCライブラリ未使用時)• プロジェクト固有の処理 – 入力チェック – 通信処理(特にエラー処理) 24
  25. 25. View(GUIコンポーネント)の細かいテクニック• invalidate(遅延描画) – GUIコンポーネントを作るときに必須 – 描画パフォーマンスが改善 • 不要な描画処理を走らせないようにする • 部分描画と組み合わせるとなお良い – ActionScript, iOS, Android, Windows, …など、 どれでも用意されている – JavaScriptでの解説を見かけたことがない… 25
  26. 26. invalidateを使うと改善できる例• プロパティを変更する毎に描画処理が 呼ばれてしまい、パフォーマンスに影響が function Box() {/*省略*/ } Box.prototype = { setWidth: function (width) { this._width = width; this._draw(); }, setHeight: function (height) { /*プロパティ更新後、描画*/ }, setFillColor: function (color) { /*プロパティ更新後、描画*/ }, setBorderColor: function (color) { /*プロパティ更新後、描画*/ }, _draw : function (style) { /*描画処理*/ } } 26
  27. 27. invalidateを実装する function Box() {/*省略*/ } Box.prototype = { setWidth: function (width) { • setTimeoutで描画処理を this._width = width; this._invalidate(); 遅延 }, /*中略*/ • 何度invalidateを呼んでも invalidate: function() { if (!this._drawer) { drawは一回だけ実行 var self = this; this._drawer = function () { this._draw(); this._drawer = null; }; setTimeout(this._drawer , 0); } }, _draw : function (style) {/*描画処理*/ } } 27
  28. 28. まとめ 28
  29. 29. まとめ• 一人開発でも複数人開発でもやることには 大差はない – ただし人数が多い分だけ修正する際のコストが 増加するので、段取りには注意する• JavaScriptは柔軟すぎる言語仕様の割には 冗長なコードになりがち – 可能であれば、JavaScriptを生成する言語の 採用を検討したほうが良い(Haxeとか) 29
  30. 30. ご清聴ありがとうございました 30

×