$30 off During Our Annual Pro Sale. View Details »

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

DMM.com
September 15, 2017

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

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

DMM.com

September 15, 2017
Tweet

More Decks by DMM.com

Other Decks in Programming

Transcript

  1. ʹ͓͚Δ
    ϑϩϯτΤϯυٕज़બఆʹ͍ͭͯ
    リソース、リスク、バリューから考える技術選定
    DMM.comラボ デザイン本部
    フロントエンド開発部 新規・流動チーム
    リードエンジニア 清宮 洋徳

    View Slide

  2. ΞδΣϯμ

    View Slide

  3. 1. ⾃⼰紹介
    2. プロジェクト背景
    3. 技術選定とは?
    4. 今回の技術選定
    5. さいごに

    View Slide

  4. 1. ࣗݾ঺հ

    View Slide

  5. ਗ਼ٶ ༸ಙ LJZPNJZB

    Webサイトに携わり約20年。
    Webに関することに⼀通り⾜
    をつっこみ、2016年に
    DMM.com ラボへ参加。

    View Slide

  6. ৽ن/ྲྀಈνʔϜ
    σβΠϯຊ෦ ϑϩϯτΤϯυ
    ։ൃ෦ に所属
    (not sys!)
    ৽نࣄۀのサイト構築に携わ
    ることが⽐較的多い。
    ৽ن / ྲྀಈ
    ৽ ৽ ৽

    View Slide

  7. 2. ϓϩδΣΫτഎܠ

    View Slide

  8. %..DPN͸৽نࣄۀ͕ଟ͍ձࣾ
    ここ⼀年を振り返ってみても、
    多くのサービスサイトが⽴ち上がっている

    View Slide

  9. ͦΜͳզʑͷνʔϜʹ
    ৽ͨͳϓϩδΣΫτͷґཔ͕ʂ

    View Slide

  10. View Slide

  11. $.Ξϫʔυͱ͸ʁ
    DMMの各サービスを応援
    する$.ಈըίϯςετ
    最優秀賞はສԁ!
    ୈೋճ։࠵த!

    View Slide

  12. たくさんデータあるけど
    全部API叩けばいいから!
    $.Ξϫʔυͷϑϩϯτ։ൃཁ݅
    状態管理
    ルーティング
    HistoryAPI
    通信処理

    View Slide

  13. ੩తHTMLͰϦϦʔεͩʂ

    View Slide

  14. ͍··ͰͷϫʔΫελΠϧ
    HTML作成 php組み込み
    いままで
    • 異なる部署の成果物がີ݁߹
    • クリティカルパスが存在
    デザイン本部 システム本部

    View Slide

  15. $.Ξϫʔυͷ։ൃ͸͜͏ͳΔ
    HTML作成
    API作成
    CMAWD
    • 異なる部署の成果物はૄ݁߹に!
    • クリティカルパスからの開放!
    デザイン本部
    システム本部

    View Slide

  16. ͔͠͠ɺ͕͢͞ʹϑϨʔϜϫʔΫ
    ಋೖΛݕ౼͢Δ΂͖Ͱ͸ʁ

    View Slide

  17. ಋೖ͍ͨ͠ཧ༝
    • 投稿フォーム → 確認画⾯でデータを保持しておく
    • URLにより、APIに対して投げる値が変わる
    • モーダルを開いたときにURLを変えたい
    • 検索やページングなどの機能をフロントで実装
    APIに投げるデータをたくさん保持しつつ、
    データに応じて⾒た⽬とURLが変わる(逆も)

    View Slide

  18. ͍Ζ͍Ζ͋Δ͚ͲɺͲΕΛબͿʁ
    何を拠り所として選んだらいいんだろう・・・?
    React Vue RIOT Angular
    BACK
    BONE

    View Slide

  19. 3. ٕज़બఆͱ͸ʁ

    View Slide

  20. ٕज़બఆͱ͸ͳΜͩΖ͏͔

    View Slide

  21. ·ͣ͸΋ͪΖΜཁٻΛຬͨ͢͜ͱ
    いくら良い技術を使ったところで、
    要求を満たせなくては意味がない。

    View Slide

  22. ϦιʔεͱϦεΫͷఱṝ
    リソースには限りがある…
    限られたリソースだから、
    リスクはしっかり考えないと。

    View Slide

  23. ϦιʔεͱϦεΫͷఱṝ
    リソースよりリスクが上回るとେมͳ͜ͱに
    いつ終わるかわからない、ϦϦʔε஗Ԇ
    ௿ΫΦϦςΟなアウトプット
    結果的に๲େͳίετ
    ਓʹґଘ͠ɺ͔ͭߴίετͳӡ༻ମ࣭

    View Slide

  24. ϦιʔεͱϦεΫͷఱṝ
    つまり
    ϑϨʔϜϫʔΫಋೖʹؔͯ͠ͷ૝ఆϦεΫ͸
    ίετΛ௒͑ͳ͍ように設計する。

    View Slide

  25. ͱ͸͍͑ৡΕͳ͍΋ͷ͕͋Δ
    ただ、リスク回避に主眼を置きすぎると
    jQuery࢖͑͹͍͍Μ͡Όͳ͍ʁ
    ってなりがち。

    View Slide

  26. ͦ͏͡Όͳ͍ɻ
    όϦϡʔ͕ඞཁͩɻ

    View Slide

  27. όϦϡʔͱ͸ʁ
    「໨తͷୡ੒」ではなく
    「͞ΒͳΔ෇ՃՁ஋」であり、
    ϊ΢ϋ΢となるもの。

    View Slide

  28. ϊ΢ϋ΢ʹ͍ͭͯ
    ⾼い⼭でも
    0からスタートするのと、
    五合⽬からスタートするのでは
    かかるリスクが異なります。
    この「五合⽬スタート」がノウハウです。

    View Slide

  29. ࠓճ jQuery Λ࢖ͬͯ΋
    ϊ΢ϋ΢͸ͨ·Βͳ͍ɻ

    View Slide

  30. όϦϡʔͷઃఆ
    つまり
    ࠓճҎ߱ɺޒ߹໨͔ΒελʔτͰ͖ΔΑ͏ʹɺ
    खʹೖΕΔ෇ՃՁ஋Λ͋Β͔͡Ίઃఆしておく。
    何かしら学ぶことが重要。

    View Slide

  31. ͪͳΈʹ
    ⼭はどんどん⾼くします。
    でも開始位置も少しずつあがっていきます。
    このΰʔϧͱܦݧ஋ͷ૒ํΛੵΈॏͶߴΊͯ
    ͍͘͜ͱが重要です。

    View Slide

  32. ͭ·Γ

    View Slide

  33. ٕज़બఆͱ͸
    • ϏδωεతཁٻΛຬͨ͢
    • Ϧιʔε > ϦεΫ
    • όϦϡʔ > ϊ΢ϋ΢ͷऔಘ

    View Slide

  34. 4. ࠓճͷٕज़બఆ

    View Slide

  35. Ϗδωεతཁٻ
    今回のケースでは
    • API連携が⼗分にできればよく、軽いもの
    (ϑϧελοΫ͸ෆཁʣ
    • ページ遷移時にデータを取り回せる
    • サーバーを持たない(SSR͸ෆཁʣ
    • ࡞Γ͖ΓલఏͷͨΊɺӡ༻ੑ͸ॏࢹ͠ͳ͍

    View Slide

  36. Ϧιʔεͱ੍໿
    ぼくひとり。
    2.5ヶ⽉程度の開発期間(not⼯数)を確保。
    納期はマスト。
    →͙͢ʹखΛ෇͚ΒΕɺࢿྉ͕ଟ͍ͱྑ͍

    View Slide

  37. όϦϡʔ
    何らかのクライアントサイドフレームワーク
    を導⼊し、知⾒を得ること。
    →ࠓޙʹͭͳ͕Δ͜ͱΛߟ͑ΔͱɺͳΔ΂͘
    ϝδϟʔͳ΋ͷ͕ྑ͍

    View Slide

  38. ϏδωεཁٻΛຬٕͨ͢ज़ʹର͠ɺ
    ϦιʔεͱόϦϡʔ͔Β
    ϦεΫΛݕ౼͢Δ

    View Slide

  39. ࢢ৔ௐࠪ
    規模感と機能⾯の双⽅から、
    いくつかのメジャーなアーキテクチャを
    選定対象にしました。
    React Vue RIOT

    View Slide

  40. ϦεΫݕ౼ͷ؍఺
    選定対象のいずれも、要求を満たしており、
    バリューも⼗分だと判断。
    あとはリスクの精査から決めれば良い。
    • 学習の容易さ(リスク)
    • ミニマムスタート(リスク)
    • 部内の知⾒、チーム内の知⾒(リスク)
    • 運⽤の容易さ(リスク)

    View Slide

  41. 特筆すべきポイント
    ES6およびJSXについて、チーム経験値が⼗分にない。
    よって環境構築に若⼲のリスクがある。
    資料とサンプルの豊富さは魅⼒。
    Case: React
    React

    View Slide

  42. Case: Vue.js
    特筆すべきポイント
    RouterやValidator含め、⽇本語での⼀次資料が群を
    抜いて豊富である点はすごかった。
    また記述⽅法がReactよりもHTML的であり(今に
    なって思えばそこまでJSXは難しくなさそうだが)、
    我々のバックグラウンドに馴染みやすかった。
    Vue

    View Slide

  43. Case: Riot.js
    特筆すべきポイント
    軽量であることが素晴らしい。Vue.jsと同じくReact
    よりもHTML的に記述できる。
    ただし部内での実績がなく、詳しくリスクを把握で
    きなかった。
    RIOT

    View Slide

  44. ϦεΫ
    ES6かつJSXを使うという敷居の⾼さ
    →学習&構築コスト⾼くなりそうな気配?
    とくに⼤きいリスクなし?
    部内に実績がなかったため、
    調査コストがかかりそうだと判断
    React
    Vue
    RIOT

    View Slide

  45. ݁࿦ͱͯ͠
    特に⼤きいリスクが⾒当たらなかったので、
    その分学習に時間を割くことができそうだった
    に決めました。
    Vue

    View Slide

  46. バージョン名がEvangelionで気に⼊った
    という理由もある。(モチベはどんな形でも⼤事)
    ※本プロジェクトの開発時はまだ1系でした

    View Slide

  47. ݁Ռ

    View Slide

  48. ݁ՌͲ͏ͳ͔ͬͨʁ
    • リソース範囲内で学習と構築を完了
    • MVVMの知⾒もGET
    • チーム⼒アップ(いまはReactも扱っている)
    • 部内外を問わず社内へフィードバックできた
    • システムさんと連携しつつ、別で開発ができた
    • CMアワードそのものが成功した!(第⼆回へ)

    View Slide

  49. 5. ͍͞͝ʹ

    View Slide

  50. ͍͞͝ʹ
    技術選定とは
    • Ϗδωεཁ݅Λຬ্ͨͨ͠Ͱɺ
    • ݱࡏͷϦεΫͱϦιʔεΛߟ͑ͯɺ
    • ྑ͖όϦϡʔΛಘΔ͜ͱ
    という考え⽅で⼀定の成果が出たと思っています。

    View Slide

  51. όϦϡʔ͕มΘΕ͹બఆ΋มΘΔ
    今回はԿͰ΋͍͍ͷͰϑϨʔϜϫʔΫͷ஌ݟΛೖ
    ख͢Δということをバリューに設定していますが、
    ノウハウの貯蓄具合によってはとうぜんόϦϡʔ
    ࣗମ͕มΘͬͯ͘Δと思います。
    ϦιʔεɺϦεΫɺόϦϡʔを考え、最適な技術
    選択する事をこれからも⼼がけたいと思います!

    View Slide

  52. ͝ਗ਼ௌ͋Γ͕ͱ͏͍͟͝·ͨ͠ɻ

    View Slide