Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DMM CM AWAEDS におけるフロントエンド技術選定について
Search
DMM.com
September 15, 2017
Programming
1
1.3k
DMM CM AWAEDS におけるフロントエンド技術選定について
17年8月22日に開催しました#DMMmeetup DMMフロントエンド開発最前線で発表した際の資料です
DMM.com
September 15, 2017
Tweet
Share
More Decks by DMM.com
See All by DMM.com
Neo4j with Spark for Big Data Analysis
dmmlabo
1
490
P3インスタンスではじめるDeep Learningと画像レコメンド
dmmlabo
2
3.2k
DMM.comのサービス開発におけるGitHub Enterprise活用の舞台裏
dmmlabo
2
920
Digdagを導入してみて
dmmlabo
9
4k
DMM.comラボにおける Scality Ring 活⽤事例
dmmlabo
0
1k
デジタルコンテンツの安定配信とコスト削減の両立を実現したシステム刷新
dmmlabo
1
2.6k
エンジニアのパフォーマンス・モチベーション管理
dmmlabo
1
1.3k
DMMに於ける技術導入はじめの一歩
dmmlabo
1
1.3k
AWSエンジニアがオンプレミスと対峙するとき
dmmlabo
2
5.6k
Other Decks in Programming
See All in Programming
CloudNativePGを布教したい
nnaka2992
0
100
Spring gRPC について / About Spring gRPC
mackey0225
0
230
バッチを作らなきゃとなったときに考えること
irof
1
420
Lottieアニメーションをカスタマイズしてみた
tahia910
0
130
ML.NETで始める機械学習
ymd65536
0
210
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
130
ファインディLT_ポケモン対戦の定量的分析
fufufukakaka
0
850
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
shunta27
0
190
Amazon ECS とマイクロサービスから考えるシステム構成
hiyanger
2
580
CI改善もDatadogとともに
taumu
0
170
sappoRo.R #12 初心者セッション
kosugitti
0
260
Java Webフレームワークの現状 / java web framework at burikaigi
kishida
9
2.2k
Featured
See All Featured
Writing Fast Ruby
sferik
628
61k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Thoughts on Productivity
jonyablonski
69
4.5k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Fireside Chat
paigeccino
34
3.2k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Building Your Own Lightsaber
phodgson
104
6.2k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
The Pragmatic Product Professional
lauravandoore
32
6.4k
GitHub's CSS Performance
jonrohan
1030
460k
Transcript
ʹ͓͚Δ ϑϩϯτΤϯυٕज़બఆʹ͍ͭͯ リソース、リスク、バリューから考える技術選定 DMM.comラボ デザイン本部 フロントエンド開発部 新規・流動チーム リードエンジニア 清宮 洋徳
ΞδΣϯμ
1. ⾃⼰紹介 2. プロジェクト背景 3. 技術選定とは? 4. 今回の技術選定 5. さいごに
1. ࣗݾհ
ਗ਼ٶ ༸ಙ LJZPNJZB Webサイトに携わり約20年。 Webに関することに⼀通り⾜ をつっこみ、2016年に DMM.com ラボへ参加。
৽ن/ྲྀಈνʔϜ σβΠϯຊ෦ ϑϩϯτΤϯυ ։ൃ෦ に所属 (not sys!) ৽نࣄۀのサイト構築に携わ ることが⽐較的多い。 ৽ن
/ ྲྀಈ ৽ ৽ ৽
2. ϓϩδΣΫτഎܠ
%..DPN৽نࣄۀ͕ଟ͍ձࣾ ここ⼀年を振り返ってみても、 多くのサービスサイトが⽴ち上がっている
ͦΜͳզʑͷνʔϜʹ ৽ͨͳϓϩδΣΫτͷґཔ͕ʂ
None
$.Ξϫʔυͱʁ DMMの各サービスを応援 する$.ಈըίϯςετ 最優秀賞はສԁ! ୈೋճ։࠵த!
たくさんデータあるけど 全部API叩けばいいから! $.Ξϫʔυͷϑϩϯτ։ൃཁ݅ 状態管理 ルーティング HistoryAPI 通信処理
੩తHTMLͰϦϦʔεͩʂ
͍··ͰͷϫʔΫελΠϧ HTML作成 php組み込み いままで • 異なる部署の成果物がີ݁߹ • クリティカルパスが存在 デザイン本部 システム本部
$.Ξϫʔυͷ։ൃ͜͏ͳΔ HTML作成 API作成 CMAWD • 異なる部署の成果物はૄ݁߹に! • クリティカルパスからの開放! デザイン本部 システム本部
͔͠͠ɺ͕͢͞ʹϑϨʔϜϫʔΫ ಋೖΛݕ౼͢Δ͖Ͱʁ
ಋೖ͍ͨ͠ཧ༝ • 投稿フォーム → 確認画⾯でデータを保持しておく • URLにより、APIに対して投げる値が変わる • モーダルを開いたときにURLを変えたい •
検索やページングなどの機能をフロントで実装 APIに投げるデータをたくさん保持しつつ、 データに応じて⾒た⽬とURLが変わる(逆も)
͍Ζ͍Ζ͋Δ͚ͲɺͲΕΛબͿʁ 何を拠り所として選んだらいいんだろう・・・? React Vue RIOT Angular BACK BONE
3. ٕज़બఆͱʁ
ٕज़બఆͱͳΜͩΖ͏͔
·ͣͪΖΜཁٻΛຬͨ͢͜ͱ いくら良い技術を使ったところで、 要求を満たせなくては意味がない。
ϦιʔεͱϦεΫͷఱṝ リソースには限りがある… 限られたリソースだから、 リスクはしっかり考えないと。
ϦιʔεͱϦεΫͷఱṝ リソースよりリスクが上回るとେมͳ͜ͱに いつ終わるかわからない、ϦϦʔεԆ ΫΦϦςΟなアウトプット 結果的にେͳίετ ਓʹґଘ͠ɺ͔ͭߴίετͳӡ༻ମ࣭
ϦιʔεͱϦεΫͷఱṝ つまり ϑϨʔϜϫʔΫಋೖʹؔͯ͠ͷఆϦεΫ ίετΛ͑ͳ͍ように設計する。
ͱ͍͑ৡΕͳ͍ͷ͕͋Δ ただ、リスク回避に主眼を置きすぎると jQuery͍͍͑Μ͡Όͳ͍ʁ ってなりがち。
ͦ͏͡Όͳ͍ɻ όϦϡʔ͕ඞཁͩɻ
όϦϡʔͱʁ 「తͷୡ」ではなく 「͞ΒͳΔՃՁ」であり、 ϊϋとなるもの。
ϊϋʹ͍ͭͯ ⾼い⼭でも 0からスタートするのと、 五合⽬からスタートするのでは かかるリスクが異なります。 この「五合⽬スタート」がノウハウです。
ࠓճ jQuery Λͬͯ ϊϋͨ·Βͳ͍ɻ
όϦϡʔͷઃఆ つまり ࠓճҎ߱ɺޒ߹͔ΒελʔτͰ͖ΔΑ͏ʹɺ खʹೖΕΔՃՁΛ͋Β͔͡Ίઃఆしておく。 何かしら学ぶことが重要。
ͪͳΈʹ ⼭はどんどん⾼くします。 でも開始位置も少しずつあがっていきます。 このΰʔϧͱܦݧͷํΛੵΈॏͶߴΊͯ ͍͘͜ͱが重要です。
ͭ·Γ
ٕज़બఆͱ • ϏδωεతཁٻΛຬͨ͢ • Ϧιʔε > ϦεΫ • όϦϡʔ >
ϊϋͷऔಘ
4. ࠓճͷٕज़બఆ
Ϗδωεతཁٻ 今回のケースでは • API連携が⼗分にできればよく、軽いもの (ϑϧελοΫෆཁʣ • ページ遷移時にデータを取り回せる • サーバーを持たない(SSRෆཁʣ •
࡞Γ͖ΓલఏͷͨΊɺӡ༻ੑॏࢹ͠ͳ͍
Ϧιʔεͱ੍ ぼくひとり。 2.5ヶ⽉程度の開発期間(not⼯数)を確保。 納期はマスト。 →͙͢ʹखΛ͚ΒΕɺࢿྉ͕ଟ͍ͱྑ͍
όϦϡʔ 何らかのクライアントサイドフレームワーク を導⼊し、知⾒を得ること。 →ࠓޙʹͭͳ͕Δ͜ͱΛߟ͑ΔͱɺͳΔ͘ ϝδϟʔͳͷ͕ྑ͍
ϏδωεཁٻΛຬٕͨ͢ज़ʹର͠ɺ ϦιʔεͱόϦϡʔ͔Β ϦεΫΛݕ౼͢Δ
ࢢௐࠪ 規模感と機能⾯の双⽅から、 いくつかのメジャーなアーキテクチャを 選定対象にしました。 React Vue RIOT
ϦεΫݕ౼ͷ؍ 選定対象のいずれも、要求を満たしており、 バリューも⼗分だと判断。 あとはリスクの精査から決めれば良い。 • 学習の容易さ(リスク) • ミニマムスタート(リスク) • 部内の知⾒、チーム内の知⾒(リスク)
• 運⽤の容易さ(リスク)
特筆すべきポイント ES6およびJSXについて、チーム経験値が⼗分にない。 よって環境構築に若⼲のリスクがある。 資料とサンプルの豊富さは魅⼒。 Case: React React
Case: Vue.js 特筆すべきポイント RouterやValidator含め、⽇本語での⼀次資料が群を 抜いて豊富である点はすごかった。 また記述⽅法がReactよりもHTML的であり(今に なって思えばそこまでJSXは難しくなさそうだが)、 我々のバックグラウンドに馴染みやすかった。 Vue
Case: Riot.js 特筆すべきポイント 軽量であることが素晴らしい。Vue.jsと同じくReact よりもHTML的に記述できる。 ただし部内での実績がなく、詳しくリスクを把握で きなかった。 RIOT
ϦεΫ ES6かつJSXを使うという敷居の⾼さ →学習&構築コスト⾼くなりそうな気配? とくに⼤きいリスクなし? 部内に実績がなかったため、 調査コストがかかりそうだと判断 React Vue RIOT
݁ͱͯ͠ 特に⼤きいリスクが⾒当たらなかったので、 その分学習に時間を割くことができそうだった に決めました。 Vue
バージョン名がEvangelionで気に⼊った という理由もある。(モチベはどんな形でも⼤事) ※本プロジェクトの開発時はまだ1系でした
݁Ռ
݁ՌͲ͏ͳ͔ͬͨʁ • リソース範囲内で学習と構築を完了 • MVVMの知⾒もGET • チーム⼒アップ(いまはReactも扱っている) • 部内外を問わず社内へフィードバックできた •
システムさんと連携しつつ、別で開発ができた • CMアワードそのものが成功した!(第⼆回へ)
5. ͍͞͝ʹ
͍͞͝ʹ 技術選定とは • Ϗδωεཁ݅Λຬ্ͨͨ͠Ͱɺ • ݱࡏͷϦεΫͱϦιʔεΛߟ͑ͯɺ • ྑ͖όϦϡʔΛಘΔ͜ͱ という考え⽅で⼀定の成果が出たと思っています。
όϦϡʔ͕มΘΕબఆมΘΔ 今回はԿͰ͍͍ͷͰϑϨʔϜϫʔΫͷݟΛೖ ख͢Δということをバリューに設定していますが、 ノウハウの貯蓄具合によってはとうぜんόϦϡʔ ࣗମ͕มΘͬͯ͘Δと思います。 ϦιʔεɺϦεΫɺόϦϡʔを考え、最適な技術 選択する事をこれからも⼼がけたいと思います!
͝ਗ਼ௌ͋Γ͕ͱ͏͍͟͝·ͨ͠ɻ