DMM CM AWAEDS におけるフロントエンド技術選定について

17年8月22日に開催しました#DMMmeetup DMMフロントエンド開発最前線で発表した際の資料です

Transcript

1. ʹ͓͚Δ ϑϩϯτΤϯυٕज़બఆʹ͍ͭͯ リソース、リスク、バリューから考える技術選定 DMM.comラボ デザイン本部 フロントエンド開発部 新規・流動チーム リードエンジニア 清宮 洋徳
2. ΞδΣϯμ
3. 1. ⾃⼰紹介 2. プロジェクト背景 3. 技術選定とは？ 4. 今回の技術選定 5. さいごに
4. 1. ࣗݾ঺հ
5. ਗ਼ٶ ༸ಙ LJZPNJZB Webサイトに携わり約20年。 Webに関することに⼀通り⾜ をつっこみ、2016年に DMM.com ラボへ参加。
6. ৽ن/ྲྀಈνʔϜ σβΠϯຊ෦ ϑϩϯτΤϯυ ։ൃ෦ に所属 （not sys！） ৽نࣄۀのサイト構築に携わ ることが⽐較的多い。 ৽ن / ྲྀಈ ৽ ৽ ৽
7. 2. ϓϩδΣΫτഎܠ
8. %..DPN͸৽نࣄۀ͕ଟ͍ձࣾ ここ⼀年を振り返ってみても、 多くのサービスサイトが⽴ち上がっている
9. ͦΜͳզʑͷνʔϜʹ ৽ͨͳϓϩδΣΫτͷґཔ͕ʂ
11. $.Ξϫʔυͱ͸ʁ DMMの各サービスを応援 する$.ಈըίϯςετ 最優秀賞はສԁ！ ୈೋճ։࠵த！
12. たくさんデータあるけど 全部API叩けばいいから！ $.Ξϫʔυͷϑϩϯτ։ൃཁ݅ 状態管理 ルーティング HistoryAPI 通信処理
13. ੩తHTMLͰϦϦʔεͩʂ
14. ͍··ͰͷϫʔΫελΠϧ HTML作成 php組み込み いままで • 異なる部署の成果物がີ݁߹ • クリティカルパスが存在 デザイン本部 システム本部
15. $.Ξϫʔυͷ։ൃ͸͜͏ͳΔ HTML作成 API作成 CMAWD • 異なる部署の成果物はૄ݁߹に！ • クリティカルパスからの開放！ デザイン本部 システム本部
16. ͔͠͠ɺ͕͢͞ʹϑϨʔϜϫʔΫ ಋೖΛݕ౼͢Δ΂͖Ͱ͸ʁ
17. ಋೖ͍ͨ͠ཧ༝ • 投稿フォーム → 確認画⾯でデータを保持しておく • URLにより、APIに対して投げる値が変わる • モーダルを開いたときにURLを変えたい • 検索やページングなどの機能をフロントで実装 APIに投げるデータをたくさん保持しつつ、 データに応じて⾒た⽬とURLが変わる（逆も）
18. ͍Ζ͍Ζ͋Δ͚ͲɺͲΕΛબͿʁ 何を拠り所として選んだらいいんだろう・・・？ React Vue RIOT Angular BACK BONE
19. 3. ٕज़બఆͱ͸ʁ
20. ٕज़બఆͱ͸ͳΜͩΖ͏͔
21. ·ͣ͸΋ͪΖΜཁٻΛຬͨ͢͜ͱ いくら良い技術を使ったところで、 要求を満たせなくては意味がない。
22. ϦιʔεͱϦεΫͷఱṝ リソースには限りがある… 限られたリソースだから、 リスクはしっかり考えないと。
23. ϦιʔεͱϦεΫͷఱṝ リソースよりリスクが上回るとେมͳ͜ͱに いつ終わるかわからない、ϦϦʔε஗Ԇ ௿ΫΦϦςΟなアウトプット 結果的に๲େͳίετ ਓʹґଘ͠ɺ͔ͭߴίετͳӡ༻ମ࣭
24. ϦιʔεͱϦεΫͷఱṝ つまり ϑϨʔϜϫʔΫಋೖʹؔͯ͠ͷ૝ఆϦεΫ͸ ίετΛ௒͑ͳ͍ように設計する。
25. ͱ͸͍͑ৡΕͳ͍΋ͷ͕͋Δ ただ、リスク回避に主眼を置きすぎると jQuery࢖͑͹͍͍Μ͡Όͳ͍ʁ ってなりがち。
26. ͦ͏͡Όͳ͍ɻ όϦϡʔ͕ඞཁͩɻ
27. όϦϡʔͱ͸ʁ 「໨తͷୡ੒」ではなく 「͞ΒͳΔ෇ՃՁ஋」であり、 ϊ΢ϋ΢となるもの。
28. ϊ΢ϋ΢ʹ͍ͭͯ ⾼い⼭でも 0からスタートするのと、 五合⽬からスタートするのでは かかるリスクが異なります。 この「五合⽬スタート」がノウハウです。
29. ࠓճ jQuery Λ࢖ͬͯ΋ ϊ΢ϋ΢͸ͨ·Βͳ͍ɻ
30. όϦϡʔͷઃఆ つまり ࠓճҎ߱ɺޒ߹໨͔ΒελʔτͰ͖ΔΑ͏ʹɺ खʹೖΕΔ෇ՃՁ஋Λ͋Β͔͡Ίઃఆしておく。 何かしら学ぶことが重要。
31. ͪͳΈʹ ⼭はどんどん⾼くします。 でも開始位置も少しずつあがっていきます。 このΰʔϧͱܦݧ஋ͷ૒ํΛੵΈॏͶߴΊͯ ͍͘͜ͱが重要です。
32. ͭ·Γ
33. ٕज़બఆͱ͸ • ϏδωεతཁٻΛຬͨ͢ • Ϧιʔε > ϦεΫ • όϦϡʔ > ϊ΢ϋ΢ͷऔಘ
34. 4. ࠓճͷٕज़બఆ
35. Ϗδωεతཁٻ 今回のケースでは • API連携が⼗分にできればよく、軽いもの （ϑϧελοΫ͸ෆཁʣ • ページ遷移時にデータを取り回せる • サーバーを持たない（SSR͸ෆཁʣ • ࡞Γ͖ΓલఏͷͨΊɺӡ༻ੑ͸ॏࢹ͠ͳ͍
36. Ϧιʔεͱ੍໿ ぼくひとり。 2.5ヶ⽉程度の開発期間（not⼯数）を確保。 納期はマスト。 →͙͢ʹखΛ෇͚ΒΕɺࢿྉ͕ଟ͍ͱྑ͍
37. όϦϡʔ 何らかのクライアントサイドフレームワーク を導⼊し、知⾒を得ること。 →ࠓޙʹͭͳ͕Δ͜ͱΛߟ͑ΔͱɺͳΔ΂͘ ϝδϟʔͳ΋ͷ͕ྑ͍
38. ϏδωεཁٻΛຬٕͨ͢ज़ʹର͠ɺ ϦιʔεͱόϦϡʔ͔Β ϦεΫΛݕ౼͢Δ
39. ࢢ৔ௐࠪ 規模感と機能⾯の双⽅から、 いくつかのメジャーなアーキテクチャを 選定対象にしました。 React Vue RIOT
40. ϦεΫݕ౼ͷ؍఺ 選定対象のいずれも、要求を満たしており、 バリューも⼗分だと判断。 あとはリスクの精査から決めれば良い。 • 学習の容易さ（リスク） • ミニマムスタート（リスク） • 部内の知⾒、チーム内の知⾒（リスク） • 運⽤の容易さ（リスク）
41. 特筆すべきポイント ES6およびJSXについて、チーム経験値が⼗分にない。 よって環境構築に若⼲のリスクがある。 資料とサンプルの豊富さは魅⼒。 Case: React React
42. Case: Vue.js 特筆すべきポイント RouterやValidator含め、⽇本語での⼀次資料が群を 抜いて豊富である点はすごかった。 また記述⽅法がReactよりもHTML的であり（今に なって思えばそこまでJSXは難しくなさそうだが）、 我々のバックグラウンドに馴染みやすかった。 Vue
43. Case: Riot.js 特筆すべきポイント 軽量であることが素晴らしい。Vue.jsと同じくReact よりもHTML的に記述できる。 ただし部内での実績がなく、詳しくリスクを把握で きなかった。 RIOT
44. ϦεΫ ES6かつJSXを使うという敷居の⾼さ →学習＆構築コスト⾼くなりそうな気配？ とくに⼤きいリスクなし？ 部内に実績がなかったため、 調査コストがかかりそうだと判断 React Vue RIOT
45. ݁࿦ͱͯ͠ 特に⼤きいリスクが⾒当たらなかったので、 その分学習に時間を割くことができそうだった に決めました。 Vue
46. バージョン名がEvangelionで気に⼊った という理由もある。(モチベはどんな形でも⼤事) ※本プロジェクトの開発時はまだ1系でした
47. ݁Ռ
48. ݁ՌͲ͏ͳ͔ͬͨʁ • リソース範囲内で学習と構築を完了 • MVVMの知⾒もGET • チーム⼒アップ（いまはReactも扱っている） • 部内外を問わず社内へフィードバックできた • システムさんと連携しつつ、別で開発ができた • CMアワードそのものが成功した！（第⼆回へ）
49. 5. ͍͞͝ʹ
50. ͍͞͝ʹ 技術選定とは • Ϗδωεཁ݅Λຬ্ͨͨ͠Ͱɺ • ݱࡏͷϦεΫͱϦιʔεΛߟ͑ͯɺ • ྑ͖όϦϡʔΛಘΔ͜ͱ という考え⽅で⼀定の成果が出たと思っています。
51. όϦϡʔ͕มΘΕ͹બఆ΋มΘΔ 今回はԿͰ΋͍͍ͷͰϑϨʔϜϫʔΫͷ஌ݟΛೖ ख͢Δということをバリューに設定していますが、 ノウハウの貯蓄具合によってはとうぜんόϦϡʔ ࣗମ͕มΘͬͯ͘Δと思います。 ϦιʔεɺϦεΫɺόϦϡʔを考え、最適な技術 選択する事をこれからも⼼がけたいと思います！
52. ͝ਗ਼ௌ͋Γ͕ͱ͏͍͟͝·ͨ͠ɻ