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