1年半React.jsのプロジェクトに関わってみて.

Slide 1

Slide 1 text

1年半 React.js のプロジェクトに関わってみて Tsuyoshi Numano from:Lancers　2017/03/07 【React / Digdag / Terraform勉強会】- 続々と新規事業を創出する、ランサーズの開発チーム -

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

沼野剛志 1990年生まれ出身高専　：神戸高専専攻科（~2012）：ロボット制御出身大学院：JAIST（~2014）：VRの研究、出会いの研究で修論株式会社リッチメディア（~2015）：メディアの運営・開発現在はランサーズ株式会社でフロントエンドエンジニアとして働いています。主に React.js を利用。自己紹介

Slide 4

Slide 4 text

「1年半React.jsのプロジェクトに関わってみて」と言うテーマで、導入の経緯や、その結果をまとめました - React.js とは - ランサーズで React.js が利用されている箇所 - React.js 導入の経緯 - なぜ React.js (と Redux) を採用したか？ - React.js を導入してどうなったか？ - 現在の開発フロー全体 - 1年半 React.js のプロジェクトに関わってみて - どうやって学習するか？今日お話しする内容

Slide 5

Slide 5 text

React.js とは

Slide 6

Slide 6 text

Facebook が開発しているUIライブラリ https://facebook.github.io/react/

Slide 7

Slide 7 text

Facebook が開発しているUIライブラリ利用している企業よく一緒に聞く言葉 UI を構築するライブラリ Flux などと一緒に使って、フロントエンドの秩序を保つ

Slide 8

Slide 8 text

ランサーズで React.js が利用されている箇所

Slide 9

Slide 9 text

React.js のプロダクト：メッセージ（チャット）画面

Slide 10

Slide 10 text

React.js のプロダクト：プロジェクト管理画面

Slide 11

Slide 11 text

新規事業(現在開発中: Cordova でスマホアプリ開発)

Slide 12

Slide 12 text

ランサーズで React.js が利用されている箇所 UIの操作や構成が複雑な部分 - メッセージ（チャット）画面 - プロジェクト管理画面複雑でない部分は以前のまま。

Slide 13

Slide 13 text

ランサーズのフロント周りで利用している技術ランサーズ流 React.js/redux アプリ開発入門@mori-dev エンジニアブログでリポジトリ公開してます！

Slide 14

Slide 14 text

React.js 導入の経緯

Slide 15

Slide 15 text

2015年の7月チャットシステムを刷新して、ユーザー体験を向上するプロジェクトが始動背景

Slide 16

Slide 16 text

背景 2015年の7月チャットシステムを刷新して、ユーザー体験を向上するプロジェクトが始動 - ランサーズは 2008年 12月リリース（2017年で約 9年目のプロダクト） - フレームワークは CakePHP - ビューファイルが、だいたいページごとに管理されている - API は導入されていない

Slide 17

Slide 17 text

背景 2015年の7月チャットシステムを刷新して、ユーザー体験を向上するプロジェクトが始動 - ランサーズは 2008年 12月リリース（2017年で約 9年目のプロダクト） - フレームワークは CakePHP - ビューファイルが、だいたいページごとに管理されている - API は導入されていない - クライアントサイドのJSがメンテしにくい状況

Slide 18

Slide 18 text

クライアントサイド JS を改善したい - どのページで何が発火しているかわからないのでそれを追いたい - 1ページに複数のjs ファイルが呼び出されている - 1ファイルに結構な行数のコードが書かれている - フロントエンドに処理フローの哲学を取り入れたい - Flux などのアーキテクチャが何もない - データとビューが密結合になっている - UI をコンポーネント単位で管理したい - 同じような UI でもページ単位で管理されていたり、バラバラ - スタイルガイド的なものがない

Slide 19

Slide 19 text

クライアントサイド JS を改善したいユーザー体験を向上するためには... メンテナンスしにくい状態を改善したい - どのページで何が発火しているかわからないのでそれを追いたい - 1ページに複数のjs ファイルが呼び出されている - 1ファイルに結構な行数のコードが書かれている - フロントエンドに処理フローの哲学を取り入れたい - Flux などのアーキテクチャが何もない - データとビューが密結合になっている - UI をコンポーネント単位で管理したい - 同じような UI でもページ単位で管理されていたり、バラバラ - スタイルガイド的なものがない

Slide 20

Slide 20 text

React.js なら望みが叶いそう - どのページで何が発火しているかわからないのでそれを追いたい - どのページでどのJSを呼ぶか、管理するクラスを作る（ React.js 関係ない） - ビルドシステムを入れてファイルを分割し JSの管理をする(React.js 関係ない) - フロントエンドに処理フローの哲学を取り入れたい - React.js なら、Flux のフレームワークがいくつか存在 - データとビューを分離して疎結合な作りに - UI をコンポーネント単位で管理したい - React.js 自身が UI をコンポーネントごとに構築するためのライブラリ

Slide 21

Slide 21 text

なぜ React.js (と Redux) を採用したか？

Slide 22

Slide 22 text

React.js を選んだ理由(2015年7月当時) - 当時はAngularJS も v1 で、 React が押してきている感じだった - Vue.js もそこまで盛り上がっていなかった http://www.npmtrends.com/react-vs-angular-vs-vue 2

Slide 23

Slide 23 text

フロントに処理フローの哲学を入れたい - Flux を導入したい。 Facebook が提唱したアーキテクチャ - React.js は UI (view) でしかない。MVCでいう V のみ - データの動きが一方向でパターン化されているので動きが追いやすい - スタンダードに乗っかっておけば、メンテできる人が増える React.js 導入の経緯 https://github.com/facebook/flux

Slide 24

Slide 24 text

- fluxxorや、reflux、flummox など、いろいろ選択肢はあった - Redux に決めたのは flummox の作者が、Redux の方がイケてるからそっち使ってというようなコメントを github に残していたり、スター数も急激に伸びていた - 2015年７月当時、次の標準になりそうなフレームワークだった Flux のフレームワークはどれにするか？ Reduxを導入 React.js 導入の経緯

Slide 25

Slide 25 text

前述のような経緯で、動作を追えるようにし、コンポーネント単位でUIを管理し、メンテできるようにするために、React.js と Redux を採用をチャレンジすることに React.js を採用 React.js 導入の経緯

Slide 26

Slide 26 text

React.js を導入してどうなったか？残り: - 現在の開発フロー全体 - 1年半 React.js のプロジェクトに関わってみて - どうやって学習するか？

Slide 27

Slide 27 text

React.js を導入してどうなったか？結論から言うと - Redux(Flux) が導入され、動作が追えるようになった - UIもコンポーネント単位で管理できるようになったスタンダードを採用することで、メンテできるメンバーが増えた！ - バックエンドをAPI化することで仕事のフローが変わった - エコシステムに乗ることで、より改善に注力できるようになった課題感については、最後にまとめます

Slide 28

Slide 28 text

Redux が導入され、動作が追えるようになった http://slides.com/jenyaterpil/redux-from-twitter-hype-to-production#/27

Slide 29

Slide 29 text

コンポーネント単位で管理できる - 以前は CakePHP の ctp ファイルにダーッと書いていた - ページ単位 → UI コンポーネント単位で意識せざるをえない - コンポーネントごとにファイルを分割し、組み合わせて使う

Slide 30

Slide 30 text

コンポーネント単位で管理できる - 以前は CakePHP の ctp ファイルにダーッと書いていた - ページ単位 → UI コンポーネント単位で意識せざるをえない - コンポーネントごとにファイルを分割し、組み合わせて使うステートを受け取るコンポーネント (Container Component) ステートを持たない、受け取ったデータを表示するだけのコンポーネント ( Stateless Functional Component )

Slide 31

Slide 31 text

バックエンドをAPI化することで仕事のフローが変わった API サーバーフロントエンドバックエンド API仕様書 - 以前は CakePHPのMVC でエンジニアが一気通貫で作成 - API仕様書を作成して、その仕様を元に、並行した開発が可能に - バックエンドが完成するまでは仕様書からapi-mock を使ってmock サーバーを起動このAPI仕様書の JSON返してください API仕様書どおりのJSON返します運用方法に関してはブログにまとめました。 API仕様書をMarkDownで書き、GitHubをつかって運用する方法

Slide 32

Slide 32 text

エコシステムに乗ることで、より改善に注力できるようになった - 難易度や管理が難しい実装なども React のコミュニティライブラリで解決 - Google で利用したい機能を検索するとライブラリ化されていたりする例) 検索ワード：「redux persist 」 state をローカルストレージなどに保存して永続化したい https://github.com/rt2zz/redux-persist

Slide 33

Slide 33 text

React.js を導入してどうなったか？

Slide 34

Slide 34 text

現在の開発フロー全体

Slide 35

Slide 35 text

フロントエンドで利用している主なライブラリや技術 - yarn - webpack - es6 - babel - eslint - flow type - material-ui - css modules - enzyme

Slide 36

Slide 36 text

開発のフロー全体コードを書くテストを書く構文チェック、型チェック最新に合わせるトランスパイル、ビルド実機確認 hoge huga bar

Slide 37

Slide 37 text

デプロイ開発のフロー全体（レビューとCI、デプロイ）コードを書くテストを書く構文チェック、型チェック最新に合わせるトランスパイル、ビルド実機確認 CIでgithubにあげたファイルをチェックコードレビューオープンソースのフローベースの開発 - commit は anguralr のルールをベース - ドキュメントは厚めに書く hoge huga bar

Slide 38

Slide 38 text

エンジニアブログでリポジトリ公開しています - ランサーズ流 React.js/redux アプリ開発入門@mori-dev

Slide 39

Slide 39 text

1年半 React.js のプロジェクトに関わってみて

Slide 40

Slide 40 text

ブラッシュアップ(UI、機能) 1年半の年表 2015 2016 7月プロジェクト始動 12月 3月技術キャッチアップチャットリリース開発開発開発輪読会本ニュース約半年

Slide 41

Slide 41 text

開発開発開発 1年半の年表 2015 2016 2017 7月プロジェクト始動 12月 3月 7月 12月 3月技術キャッチアップチャットリリースブラッシュアップ(UI、機能) プロジェクト管理リリース新規プロジェクト始動輪読会本ニュース githubリポジトリ、github issue 環境構築プロト作成約半年定期的なライブラリバージョンアップ API仕様作成開発開発開発

Slide 42

Slide 42 text

プロダクトで利用している技術やコードの変化（１年半経って） - コンポーネント間の共通処理: mixin → HOC - Reduxの非同期処理: redux-thunk → redux-saga - Redux のロジック部分: action,reducer → middleware に集約 - ビルド関連: gulp + browserify → webpack - CSS関連: sass → CSS Modules - ステートを持たないコンポーネント: SFC - JSに型をもたせたい: FlowTypeの導入

Slide 43

Slide 43 text

Slide 44

Slide 44 text

React.js を入れたからといって、全てがうまくいくわけではない - React、 Redux の学習コストが高く、人をすぐ入れにくい - デザイナーがjsxを書くのに敷居が高く、HTML直書きより協業しにくい - Component の粒度が人によって違って、認識を合わせにくい - コミュニティライブラリに依存しすぎると思わぬところでハマる - データのモデリングや、ビジネスロジックの置き場に悩む - FlowType入れたけど、型を使いこなせているか不安 - gulp で管理しているプロジェクトがあり、webpackに移行できていない - トレンドを追いかけつつ、プロダクトの製作は結構忙しい React.js のプロダクトを開発、運用してみた現状の課題感

Slide 45

Slide 45 text

どうやって学習するか？

Slide 46

Slide 46 text

React.js 採用したものの、どうやって学習する？ 2015年7月時の自分のスペック - jQuery はわかる - 特にJSフレームワークを使った実務経験なし - 新卒２年目、エンジニアとしてもこれから - 当時は React や Redux の日本語の情報が少なかった - プロジェクトメンバーも3人で全員 React は初めてそもそも導入の時の技術選定に、自分は参加できていなかった。（当時のリードエンジニアと現在のシニアエンジニアの方が素晴らしい方だったおかげで今の自分があります。）

Slide 47

Slide 47 text

輪読会が一番効果があったチームメンバー３人で輪読会 - 毎日３０分 - １５分精読、１５分読んだ内容を発表 - 約２ヶ月くらい続けたチームメンバーで共通意識が持てた。カレンダーで時間を取っており、勉強する時間が取れた。

Slide 48

Slide 48 text

まとめ

Slide 49

Slide 49 text

まとめ React.js や Redux を導入したことによって - 処理が追えて、UIコンポーネントごとに管理できるようになった - ユーザーに価値提供するための、継続的な改善開発基盤ができた React.js のプロジェクトに関わってみて - 初期の導入はハードルが高い - 日々トレンドが変わったり活発なコミュニティは案外楽しい - 慣れると、以前のような開発には戻れない(戻りたくない) そもそも素人な自分にチャレンジさせてくれる会社に感謝。