freee Tech Night #2 「大規模SaaSを支えるフロントエンドの話」 https://gyazo.com/bbf486baf0bcc89607afcc664ae5654c
会計freee 7年目のフロントエンド開発
ソシャゲ界出身
会計freeeの開発
フロントエンドの啓蒙活動
単一のリポジトリで開発を7年やってきた
会計freeeについて
経理業務を始めとしたクラウド会計管理
フロントエンドも１つのリポジトリでやっていた
その他規模
DBテーブル 約650
PR番号 45000超
デプロイ 平均1/day
2019 Contributor数 50超
エンドポイント 3000弱
フロントエンドエンジニアとサーバーサイドエンジニアの区分はない
ローンチ〜2014
片手間のJS
そこまで複雑な要件ではなかった
ファイル間の依存関係なし
社内フレームワークもあった
freee-js-framework
メンテナが欠如
2015〜フロントエンド委員会の発足
課題の洗い出し
依存解決
エントリーポイントの分割
段階的に移行を進める
現在
機能ごとに独立したエントリーポイント
レガシーからモダン開発に
コードベースも開発組織も急速に拡大
ライブラリの選定ミス、アンチパターン設計という失敗による負債もあった
失敗例
facebook/fluxを使い続けた
2. 1. のリファレンス実装ライブラリを使用
freeeでは2を使用
Dispatcher を提供する flux と Container, ReduceStore を提供するflux-utils からなる非常に薄いライブラリ Container = Provider
ReduceStore = Reducer
導入背景
当時はflux系のライブラリが乱立
エコシステムのロックインを危惧、薄いほうがよいのでは
諸問題
治安が乱れる、薄いゆえにいろいろできる
storeの直接参照、単方向データフローの崩壊
マイナーな書き方になったのでサンプルがなくなる
コードが膨大な量
ActionCreatorとdispatchの分解がネック
移行期が長期に渡る
治安の保ち方
社内フレームワークになりそうなリスクはあるが…
リファレンス実装の明示
Lintで防ぐ
Flux Standard Action（FSA）の採用
コンポーネントの状態をStoreで管理する
モーダルの開閉、ローディング、フォームの入力値
Storeをどこで管理するかは明確な答えがない
適時判断しましょう（公式ドキュメント）
将来はReact.Suspenseという選択肢も
親から子のStateでみたいなら親のStateであるべき
Reducerの肥大化
コンポーネントで扱うか、Storeで扱うかの判断基準がわからない
悲劇
ライフサイクルからActionがdispatchされる事態
同一イベントループで例外が投げられる
React16だとエラーでrootまでさかのぼってコンポーネントunmountされる
画面が真っ白に
表示上の不整合を防ぐための仕様変更
指針の統一
コンポーネントの状態はコンポーネント
親から参照したければ親のState
Reactコンポーネントの継承
BaseModalというコンポーネント
モーダルの共通ロジックを抽象化
実際の運用
renderごとオーバーライド
実質ヘルパのInclude
そもそも継承すべきではない
ViewControllerではない
propsから同じDOMを生成するアトミック関数
renderという明確な主体がある
抽象化は別のアプローチでやるべき
HOC
render props
children
So What About Inheritance ?
（公式）継承が必要な例はなかった
振り返り
設計やライブラリ自体は悪ではない
問題の根幹
初期の設計や規約がきちんと整備できてない
大規模故に一度定着してしまうとmズウ香椎
分業制ではない＝練度はバラバラ
秩序を保つ
コンセンサスをとっておく
自動化できるところはやっておくコスト減
組織全体の取り組み
プロダクト立ち上げ時にボイラープレートの提供
少人数でフロントエンドについて語る
今後の展望
共通UIコンポーネントライブラリの開発
フロントエンド委員会も継続的に活動中
質問
ない。flowtypeと比較して、TypeScriptじゃないとできないことは今の所そんなになさそうだから
freeeではどこまでフロントエンドと呼ぶの？
freeeだとデザイナー的なことはしてない。あくまでエンジニアリング担当
サーバーサイドとフロントエンドで分業しないメリデメ
メリットは、コミュニケーションコストが下がること。パフォーマンスも全体的に考えることができる
デメリットは、人によってバランスや練度がばらけること
長期インターンとして1年間人事労務freee開発に従事
2018年に新卒で入社
社内外からいろんな反応があった
アドベントカレンダーで書けなかった本当の理由について
npm
node package manager
オフィシャルなパッケージマネージャ
package.jsonを元にインストール
yarn
アンオフィシャルなパッケージマネージャ
チェックサムによるパッケージの整合性チェック
freeeはyarnで開発
yarnは本当に必要か？
海外記事
利点
高速インストール
npm 5から改善、6ではほぼ同等のスピードに
ロックファイル
shrinkwrapの固定化
devDepebdenciesの整合性の破壊
npm-shirinkwrap.json
package-lock.jsonの自動生成
npm 5以降
依存パッケージすべてのバージョン指定はできない
ワークスペース
まともに使ってない
出戻った本当の理由
2019年現在のfreeeではnpmが優れている
1. 複数バージョンのyarnが使いにくい
基本的にグローバルインストール
１つのプロダクトに複数のバージョンが混在
複数バージョンの管理
2. ビルド環境の複雑化
Dockerfileの更新、イメージ作成
テストやコンポーネントカタログ用
本番用
Ansibleの更新、サーバの適応
3. 100人を超えるエンジニア組織に
https://gyazo.com/3d42d8dcde282dcbc313447573c75c0f
フロントエンドのスキルギャップがある
yarnを使うためにNode.jsとは別のセットアップが必要（学習コスト） npmに出戻るまでの道のり
半年弱β版を使ってた
2018/8に正式版リリース、アップデート
@babel/preset-envの設定にハマった
もともとv8.11.2を使用
ビルド時にパフォーマンス低下発生する可能性
少しでもビルド時間を減らしたい
v10にアップデート
deyarnを使ってnpmへ戻す
1. yarn.lock削除
2. node_modulesの削除
3. npm installで再インストール
QAテスト＆リリース
依存の解決方法が違う
lockファイルを再生成してるのでパッケージのバージョンがズレる
依存性をどう担保するか
synpを使ってpackage-lock.jsonに変換したがうまくいかない QAテストで動作を担保してリリース
開発合宿から片手間3ヶ月強かけて出戻り作業
今後について
npmとyarnの混在はまだある
脱yarnをすすめていく
yarn v2の動向チェック
優れている場合はyarnに出戻るかも？
2015年からは人事労務freee開発
当初は給与計算freee
UI改善プロジェクトと同時並立でデザインシステムの開発
会社の成長によって起きたこと
資金調達161億円
従業員505名
エンジニア・デザイナーも100人超
サービスも7本立てに
個人事業主→上場企業にも導入
サービスの変化で変わってきたこと
高品質なものを求められるように
数百人規模の法人までカバー
普通のことができるサービスに
ユーザビリティやアクセシビリティが重要に
開発組織の拡大
誰がどこで何を作ってるのかが見えづらくなった
求められるもの・満たすべきものが複雑化
試行錯誤しながら作ったものが負債に
フロントエンド開発スタイル
UIデザインはデザイナーが行い
画面モックをエンジニアにわたす
コーディングがすべてエンジニアがやる
フロントエンドが不慣れなエンジニアもやる
会社が大きくなってきたことのUI開発
人事労務サービスがカラースキームが緑色に
CSSが得意な人がいなかった
環境整備の不備が大きくなってきた
作る画面モックの差異がでかい
更に違うものが作られる
stylesheetsディレクトリがカオスに
見た目が揃ってない、挙動が若干違う
生産性も低下
AG部の誕生
統一的なUIを作る
目標
どのデザイナーでも統一されたUIがデザインされるように
フロントエンドが不慣れな人も統一されたUIが実装できるように
爆速で機能開発できるようにしたい
ガイドラインとデザインシステム
Groove
網羅性が高くない
メンテも参照されず放置されていた
チームでオーナーシップを持ちましょう
vibes
SketchライブラリとCSS / React Component実装 freeeにとってのアクセシビリティ
ビジネスのプラットフォームとなるサービス
freeeが使えない＝ビジネスができない
誰でも使えるサービスにして強みにしよう
どういう問題がある？
法定雇用率
45.5人以上で2.2%以上の障害者雇用が義務
色覚異常
日本人男性に20人に1人
中小企業ほど高齢者比率が高い
全盲のエンジニア 中根さんも働いている
働きやすいか？
給与明細がWebやアプリで見られるので誰かに読んでもらう必要がない
写真をとってOCRするなど
Webで基本やり取りなのでペーパーレス化されている
何が必要なのか
少なくやっていくのには限界
全員が教育される必要がある
デザインシステムがアクセシビリティを担保すればすべての人が利用できるのでは
障害者へのヒアリング、挙動への議論
コンポーネントの定義時にヒアリングしてみる
コンポーネントごとにそのあり方について議論
スクリーンリーダーで読み取ってもらう
eslint-plugin-jsx-a11y
アクセシビリティチェック内容の定義
各フェーズで誰向けに何をチェックすればいいかを定義
色覚、弱視、スクリーンリーダー使用、上肢障害向け
https://gyazo.com/3a72a586504c3d5054e0eaeba2f559cf
現状
vibes自体の実装がほぼ完了した
アプリストアなど一部導入
Sketchライブラリの課題
共有問題
FigmaやXDなどそれ以外を使う可能性も
CSS/ React Componentの課題
CSSは１つのファイルにSCSSをトランスパイル
秩序にオーバーライドされそう
アクセシビリティの課題
いい塩梅を知ってるひとだけ問題
デザインシステムを最速導入するのを前提
そこにアクセシビリティを乗っけていきたい
freeeアプリストアの事例
モダンなフロントエンド開発
デザインシステムのvibesの採用
コンポーネントを自作
スタイル配布が間に合わなかった
カラーシンボルがレイヤーで取り込める
1週間で50ページ規模のプロトタイプ
パワポ感覚でサクサク作れる
活きのいい若手にやりきらせることを目指す