サービスの成長を支えるフロントエンド開発 #denatechcon

Copyright © DeNA Co.,Ltd. All Rights Reserved.
サービスの成長を
支えるフロントエンド開発
February 10, 2017
Naoki Endo x Takefumi Yoshii
DeNA Design Strategies Office
DeNA Co., Ltd.

AGENDA
■ 自己紹介
■ サービス運用におけるパラダイムシフトとの最適な付き合い方
■ 直近の業務における選択 - React を選んだ観点 -
■ 直近の業務における選択 - Vue.js を選んだ観点 -
■ 中長期的にサービスを支えるコンポーネント設計
2

自己紹介
3

自己紹介
■ 遠藤直樹
■ 株式会社ディー・エヌ・エー　デザイン戦略室第2グループ
■ 2015年1月 DeNA に入社
■ ベンチャー企業・フリーランスでデザイナー兼フロントエンジニアとして働く。そ
の後、株式会社パズルへ入社して、主に広告プロモーションのWebサイト制作
を担当。
■ 多くのユーザを抱えるサービスの制作をしたくて転職。
4

自己紹介
■ DeNA 入社後はエブリスタ・Anyca・KenCoMなどのフロントエンドを担当。
■ 現在は新規サービスでフロントエンド実装を行いながら、複数のサービスで設
計と指導に従事。
5
Anyca

自己紹介
■ 吉井健文
■ 株式会社ディー・エヌ・エー　デザイン戦略室第3グループ
■ DeSC ヘルスケア株式会社　企画開発部
■ 2016年 DeNA に入社
■ 前職は広告制作会社にて、デザイン・フロントエンド開発を担当。
■ 事業会社でサービス開発に関わることに魅力を感じ転職。
6

自己紹介
■ DeNA では Mirrativ・ゲームプロモーションサイトを実装。
■ 現職のDeSC ヘルスケア株式会社では「KenCoM」の企画開発に従事。
7
デュエルエクスマキナ
（DUELS X MACHINA）
公式サイト
DeNA DESIGN BLOG
（デザイン戦略室）

サービス運用における
パラダイムシフトとの
最適な付き合い方
8
パラダイムシフト - Wikipedia：その時代や分野において当然のことと考えられていた認識や思想、社会全体の価値観などが革命的にもしくは劇的に変化することをいう。

フロントエンド界隈
2・3年で起こった
パラダイムシフト
9
パラダイムシフト - Wikipedia：その時代や分野において当然のことと考えられていた認識や思想、社会全体の価値観などが革命的にもしくは劇的に変化することをいう。
サービス運用におけるパラダイムシフトとの最適な付き合い方

10
※登壇者の開発現場で体感している年表です。いずれのツールも各プロダクトで健在であり、リリース時期の前後により表を作成しています
※登壇者の開発現場で体感している年表です。いずれのツールも各プロダクトで健在であり、リリース時期の前後により表を作成しています

11
■ AltJS（Babel・TypeScript・CoffeeScript）
■ Web Components framework（React・Angular・Vue.js）
■ CSS pre processor（PostCSS・SASS・LESS・Stylus）
■ CSS naming conventions（BEM・ITCSS・FLOCSS）
■ Module bundler（webpack・gulp + npm scripts）
■ package manager（yarn・npm）
■ webpack、Browserifyによるモジュールシステム
■ Javascriptで静的型付け
■ Flux・Reduxによる状態の管理
■ Unit test・e2e test
乱立するコンポーネントフレームワーク。
各種トランスパイル言語によるロックイン...

12
過去のパラダイムシフトで得た知見
フロントエンド開発現場は多かれ少なかれ、
リリース時期のトレンドにロックインさる。
リプレイスに工数が割けない現場は、
過去のドキュメントを元に運用するしかないのが現状。

13
過去のパラダイムシフトで得た知見
アウトプットに貢献する技術改革は常に起きている。
しかしながら、全てがサービスに寄与し得るとは限らない。
サービスを中長期運用するうえで最適解とは？
私たちが選択したフロントエンド開発のいまを
お伝えしていきたい。

14
仮想DOMの火付け役。viewのみ
のライブラリで、アプリケーション
構築のためには様々なモジュー
ルが必要
（ Facebook ）
2017年2月現在. 社内で使われているフレームワーク
オールインワンのフレームワー
ク。静的型付けのTypeScriptを
標準で使用、テストツールも充
実
（ Google / Microsoft ）
ReactやAngularの影響を受け、
2016年にもっとも成長したフレーム
ワーク。可読性や保守性と楽しさと
のバランス
( Evan / john resig )
React Angular Vue.js

直近の業務における選択
- React を選んだ観点 -
15

16
ツールセットと開発環境
■ React + Redux + redux-saga
■ npm scripts + webpack + webpack-dev-server
■ yarn + npm
■ Ruby on Rails
直近の業務における選択 - React を選んだ観点 -

17
静的片付けは見送り
Typescript ・ flowtype は導入を控えた。
実装要件においてそれが MUST ではなかったため。
propTypesや、UnitTest で代替する方針に。

18
React Redux を選定した基準
■ フレームワークとして設計が確立されている
■ モジュール単位でのリプレイスしやすさ
■ テストコードの書きやすさ
いずれも共通している点は「疎結合」であること。
疎結合なモジュール・コードは、パラダムシフトに強く
中長期運用に向いていると考えた。

19
Redux
Fluxパターン実装のひとつ。
React 専用の状態管理ライブラリの印象が強いが、
多くのviewライブラリと組み合わせが可能。
コーディングガイドが統一されるため
独自設計が生じにくい。

20

21
Redux で React の責務が単純になる
Redux の恩恵で React のコンポーネントライフサイクルを
使う場面がほとんど無くなる。Reactの責務は view を返す
シンプルなものになり、State を持つことが無くなる。
純粋な関数で記述された jsx コンポーネントは
再利用性が高まりパフォーマンス向上も期待できる。
参考文献： React Stateless Functional Components @Cory House

22
React.Componentを継承した場合

23
React Reduxで頻出する、Stateless Functional Component の一例。
コンポーネントの状態はStoreで管理され、共有される。
コンポーネントからロジックが排出される。

24
Redux がもたらす疎結合性
Redux のお作法にならうことで、
各レイヤーの粒度が小さく、役割が明確になる。
モジュール同士を疎結合にしてくれるため、
Redux に変わる状態管理ライブラリが将来台頭しても
jsx で記述された Componentは継続して利用できる可能性が高い。
（Reactが置きかわる場合も同様）

25

26
Reduxに置きかわる状態管理ライブラリの台頭に備える。
Reactで記述されたコンポーネントは継続利用が可能
MobX alt

27
Reactに置きかわるViewライブラリの台頭に備える。
Reduxによる状態管理は継続利用が可能

28
React Redux のテスト
Redux に則り記述されたコードは、
Actions・Reducers・Components、各レイヤーの責務が
シンプルなため、テストコードも明瞭に。
テストの書きやすさもReduxの特徴
【React Redux のunitテスト一例】
■ props 分岐で期待するコンポーネントテスト
■ reducer の initialStateとactionType による戻り値
■ mock や stub はモジュールの汎用性に応じて
詳細： React Redux テスト考察 @Takepepe (Takefumi.Yoshii)

29
React Redux のテスト
【Component テスト一例】
リグレッションテストだけでなく、unitテストはI/F明示として
運用資産になる。アプリケーション規模が大きくなるにつれ、
事故を未然に防ぐ恩恵を受けやすい。

30
Redux の副作用を扱う
React Redux の設計思想に則り構築すると、
それだけでは扱いきれない副作用が発生する。
ビジネスロジックや外部要因に起因するイベント、
非同期処理、アニメーションなど。
副作用を扱うためには middleware が必要。
選定した redux-saga は多くの副作用を扱うことができる。
【Redux の副作用一例】
■ Ajax / Animation
■ websocket
■ History location
【redux-saga】
■ https://github.com/redux-saga/redux-saga

31
redux-saga の特徴
疎結合な状態でReact Redux の
アーキテクチャに組み込める。
API (redux-saga/effects) で、非同期処理の
並列リクエスト・コールバック・キャンセルなどを
同期的な記述で完結に記述出来る。
処理列のなかで、Storeの状態を参照出来る。

32
redux-saga の API
【redux-saga/effects 抜粋】
■ fork（Lounch saga task）
■ take（Waiting Action）
■ call（Waiting Promise Resolved）
■ put（Dsipatch Action）
■ select（Reference Store）

33

34
redux-saga のコード
各々がブレークポイントを持った
マルチスレッドの様な振る舞いをする。
ES2015 Generator function を使用。

35

36

37

38

39

40

41

42
React Redux 所感
数十ページに渡るWebサービス構築を予定していたり、
複雑なGUIアプリケーション構築にお勧め。
数ページのSPA実装のためには重量オーバー…？
以上、Reactを選んだ観点でした！

直近の業務における選択
- Vue.js を選んだ観点 -
43

直近の業務における選択 - Vue.js を選んだ観点 -
44
ツールセットと開発環境
■ Vue.js + Vuex
■ npm scripts + webpack + Browsersync
■ yarn + npm
■ Ruby on Rails

45
Vue.js を選定した基準
■ 単純なテンプレート構文による宣言的レンダリング
■ コンポーネントシステム
■ プログレッシブフレームワーク
コードの可読性や、フレームワークに不慣れなメンバーも
導入ハードルが低い。アジャイル開発向きなため
プロダクトの中長期運用に向いている。

46
単純なテンプレート構文による宣言的レンダリング
既存のマークアップ資産を流用する容易さ

47
コンポーネントシステム
Web Components の仕様に沿ったモデル化

48
プログレッシブフレームワーク
コアは宣言的レンダリング & コンポーネントシステム
とりあえず動くものを素早く完成させる
モジュール化の粒度の自由さ
クライアントサイドルーティングを加えたければ & vue-router
大規模状態管理を加えたければ & Vuex

49
導入も簡単で、
サクサクと動くものを作ることに集中した結果…

状態管理ツラい物語１
あるところに仕様を決めながら作っていたため、
複数人で高速プロトタイピングを繰り返した結果、
１コンポーネントの粒度もバラバラなソースがありました。
リリースを終えて運用フェーズに入ったことで、
関わっていた人は減り、バラバラだったファイルに秩序をもたらすためモ
ジュール化を進めることになりました。
最初はとても大きな単位でコンポーネントを作っていたため、
大量の状態を１コンポーネントが抱えています。
50

状態管理ツラい物語２
51
これは見通しが悪いと、
コンポーネントの粒度を細かくしていくと、
だんだん props のバケツリレーが増えてきます。
親から子へ、子から孫へ、孫からひ孫へ…
双方向バインディングしてると、コンポーネント間の関係を追っていくの
がとても大変です。
ただリレーしてるだけで使ってない値がコンポーネント内に存在します。
１箇所直すと、他に影響が出ててしまわないか不安になってきました。

状態管理ツラい物語３
52
「信頼できる状態管理の仕組みがほしい」

状態管理ツラい物語４
53
React 界隈で流行っている Flux, Redux
「いつやるか？今でしょ！」
用語の多さを見ればわかるとおり、
ソース量の増加があって、冗長化されているようにみえます。
しかし、データの流れが一方向になったため、
可読率と変更に対する安定性が上がり、
状態遷移を追うことが楽になりました。めでたしめでたし。

54
Vuex を導入した理由
■ 書き方がバラバラだった
■ コンポーネント粒度が細かくなっていく
■ 大量の状態を1つのコンポーネントが抱えていた
■ バケツリレーするだけで、コンポーネントが使わない値が量産

55

56
サービスの成長に合わせて
状態管理も柔軟に
これもプログレッシブ

中長期的にサービスを支える
コンポーネント設計
57

Linter の設定を用意して、
記述ルールのドキュメントを廃止する
サービスによって、記述ルールが個人の趣味に偏りがち。
ESLint, Sass-lint, stylelint でスタンダードな書き方に矯正して、チーム
としてメンテナンスをできる体制にする。
58
中長期的にサービスを支えるコンポーネント設計

59
.eslintrc.js
airbnb/javascript
をベースにルールを追加
.stylelintrc
stylelint/stylelint-config-standard
をベースにルールを追加
ESLint や stylelint では extend を利用して、
OSSで多くの人が採用しているスタンダードに合わせやすい。

こんなPRのくだらない指摘を未然に防ぐ。
60

61
CSS 設計のこれまでと、これから
■ BEM のコンポーネントスコープ
■ OOCSS, SMACSS, の柔軟性
■ ITCSSの記述順と詳細度
各設計が解決している問題点を継承。
プロジェクト単位でルールを作り上げているのが現状。

62
CSS 設計のこれまでと、これから
■ BEM のコンポーネントスコープ
■ OOCSS, SMACSS, の柔軟性
■ ITCSSの記述順と詳細度
SPAフレームワークと併せて登場した CSS Modules は、
これらの問題を解決するかもしれない。

63
CSS Modules はフロントエンド設計を
改変するのか
CSS Modules とは、javascript を bundle する際、
各コンポーネントに一意のhash値をclass名として付与し、
CSSグルーバル汚染を解決するアプローチ。
Bundleされたjavascriptにcssのコードが内包され、
CSS in JS とも呼ばれている。
同一ディレクトリにコンポーネントを定義している
javascript、stylesheetを配置するケースが多い。

64
改変するのか
Vue.js でのコンポーネントの作り方と CSS Modules

65
改変するのか
React でのコンポーネントの作り方と CSS Modules

66
改変するのか
ブラウザでの展開例
webpackによる一意のclass付与
コンポーネントマウント時
head タグ内に挿入される

67
改変するのか
CSS Modules はグローバル汚染を解決したものの、
プロダクトを取り巻く様々な要因により
導入できないのが、現場の実情。
※そもそも、React や Vue.js など、CSS Modules が利用できる環境ではない
※Featureテストなど外部コードからDOM名を参照できない
※外部リソースを挿入した際、詳細度のコントロールが辛くなる

68
改変するのか
SPA・非SPAが混在するプロダクトで共有し辛い…
javascript と css が密結合になってしまうこと、
特定のフレームワークによるロックインも
避けたいところ。

69
2017年2月現在
CSS Modules は全てのプロダクトで
最適解であるとは限らない

70
が、いつかは移行したい。
将来的に移行しやすい設計を意識することで
自然と良いCSS設計を得ることができる

71
CSS Modules を見据えた
CSS設計
ここで、CSS Modules が成し遂げようとしたことが
長年試行錯誤されてきたCSS設計の
台頭であったことに立ち返りたい。
それらのCSS設計と
CSS Modules の共通点とは？

72
■ 名前空間
■ 関心の分離
■ 状態管理

73
■ 名前空間
■ 関心の分離
■ 状態管理

74
CSS設計で再現する
名前空間
いずれのCSS設計もコンポーネントスコープを担保するため
BEM（Block・Element・Modifier）を用いた
命名規則を取り入れている。
BEMにおけるBlock = 名前空間は、
CSS Modules が付与するhash値と等しい。

75
名前空間
SPA コンポーネントの粒度に倣い、view関連ファイルを定義。
ファイルツリーに由来する名前空間をBEMのBlock名に。
view関連ファイルのツリー構造を対にしてみる。
■ partial ≒ component
■ locals ≒ props

76
名前空間
非CSS Modulesプロダクトであっても、
将来的に移行しやすい状態に。
コンポーネントの粒度や I/F設計が
自然と良いものに。

77
■ 名前空間
■ 関心の分離
■ 状態管理

78
コンポーネント同士の
関心の分離
外部定義からの影響は遮断したい。
担保した名前空間が台無しに…
BEMにおけるElement = プライベート要素で、
外部の名前空間から関心を分離してみる。

79
関心の分離
名前空間以外の指定を含んでしまうと、
該当コンポーネントに関する定義が分散してしまう。
また、その存在で担保していたレイアウトが破綻し、
アウトプットが予測しづらい設計に。

80
関心の分離
外部コンポーネントを配置するため、
Container Element を用意する。
BEM Element 指定は、CSS Modules における
:local() や scoped の機能と等しい。

81
■ 名前空間
■ 関心の分離
■ 状態管理

82
予測しやすい状態管理
CSSの指定はコンポーネントの
BOXモデル・装飾の定義だけではない。
状態に応じて、Modify（修正）をかけ
定義を積み重ねていく。
ある特定の状態に一致したとき、
コンポーネントに対して変化を与える様な
管理方法の危険性に触れていく。

83
詳細度の競合が発生し、影響範囲が予測できなくなる。
特定の状態になったとき、予想外の崩れが発生する。
影響範囲を特定するのが困難な例
？

84
そこで、コンポーネント単位で状態を管理することに。
状態による変化の優先順位が予測しやすくなる。
コンポーネント単位にまとまるため、
CSS Modules への移行も容易に。
CSS Modules への移行例

85
新しいトレンドには
起源となるアイデアと知見が背景にある。
それを見逃さずに意識することで、
中長期運用における最適解を導くことができる。

86
ご清聴ありがとうございました
design.dena.com

サービスの成長を支えるフロントエンド開発 #denatechcon

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a サービスの成長を支えるフロントエンド開発 #denatechcon

Semelhante a サービスの成長を支えるフロントエンド開発 #denatechcon (20)

Mais de DeNA

Mais de DeNA (20)

Último

Último (8)

サービスの成長を支えるフロントエンド開発 #denatechcon