Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

B6d9eb9a3825f15c84b5e7588c56a405?s=47 DMM.com
September 15, 2017

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

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

B6d9eb9a3825f15c84b5e7588c56a405?s=128

DMM.com

September 15, 2017
Tweet

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. ͦΜͳզʑͷνʔϜʹ ৽ͨͳϓϩδΣΫτͷґཔ͕ʂ

  10. None
  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. ͝ਗ਼ௌ͋Γ͕ͱ͏͍͟͝·ͨ͠ɻ