Upgrade to Pro — share decks privately, control downloads, hide ads and more …

"READYFOR フロントエンド" の黎明 〜デザインシステム導入/READYFOR Ele...

neripark
February 05, 2021

"READYFOR フロントエンド" の黎明 〜デザインシステム導入/READYFOR Elements 誕生〜

2021/2/5 に行われた「【READYFOR】実践!フロントエンド分離戦略」の登壇資料です。
イベントページ: https://readyfor.connpass.com/event/198730/

neripark

February 05, 2021
Tweet

Other Decks in Programming

Transcript

  1. 2 江面陽一 a.k.a ねり 自己紹介 • SIerから転向 2018年11月入社 • 趣味でバンド活動

    / 家に猫がいます • like: React, Netlify, CSS設計, component設計 • 要素セレクタ警察 @neripark #readyfor_meetup
  2. 4 本日のお話: "READYFOR フロントエンド" の黎明 1. それまでの READYFOR のフロントエンド 2.

    UIリニューアルプロジェクト 3. 技術紹介 a. React / TypeScript / Storybook / Atomic Design 4. まとめ a. うまくいった点 b. 反省点 c. 伝えたいこと #readyfor_meetup
  3. 6 • READYFOR は2011年3月に稼働開始したモノリシックな Ruby on Rails 製のア プリケーション •

    現場の要望を実現するため、スピード重視の開発 ◦ 将来を見据えた堅牢な設計 <<< 兎にも角にも動作すること • 熟成されていくソースたち • 少しの修正のはずが、、、 ◦ どんどん大きくなる影響範囲 ◦ 本番に出して初めて分かる考慮漏れ ◦ 突貫で穴を塞ぐ→手を入れにくくなる … のループ 1. それまでの READYFOR のフロントエンド #readyfor_meetup
  4. 7 • バックエンドと密結合 ◦ View ファイルの中に突如出てくる jQuery コード ▪ セレクタ部分だけ

    Ruby の変数 ▪ フロントを見ていたはずが、気づいたら Rails の深いところへ • 全体像がわからない ◦ 一部だけ React、CoffeeScript も(あるある) ◦ 特定の環境で生成される yarn.lock ◦ Gulp と webpack の共存 ▪ 結局 Gulp は使われていなかった 1. それまでの READYFOR のフロントエンド #readyfor_meetup
  5. 17 2. UIリニューアルプロジェクト発足 • CI刷新は社内外が一丸となって進めるプロジェクト ◦ 絶対的な期限のある守りの側面 • 今後の開発(特にフロントエンド)が良くなる方向に舵を切りたい ◦

    未来も見据えた策を盛り込む攻めの側面 このバランスをうまく取るために、 どういう技術構成にするかめっちゃ考えた #readyfor_meetup
  6. 19 • デザインシステム導入 ◦ プロダクト間で統一されたデザイン運用はどのみち必要 • UIライブラリ新規作成 ◦ 機能部分はどうしても既存仕様・アーキテクチャとの兼ね合いになる ◦

    それならばデザインシステム文脈の仕様は最初から別リポジトリで用意したほ うが混ざらなくて良いだろうと考えた ◦ READYFOR Elements と命名 ▪ `npm install @readyfor/readyfor-elements` (※まだ社内限定です🙏) 2. UIリニューアルプロジェクト発足 やると決めたこと🎉 #readyfor_meetup
  7. 20 2. UIリニューアルプロジェクト発足 • ReactOnRails からの脱却 ◦ 刷新対象ページの事業数値を落とさない(主にSEO観点)ために SSR を削る

    選択がしにくい ◦ パラメータ1つで SSR できる機構=生かしたほうが得策と判断 ◦ CI刷新が目的なのでSPA化によるUX向上などはマストではない ▪ バックエンド工数の確保 やらないと決めたこと🙃 #readyfor_meetup
  8. 23 • React (継続) ◦ Vue.js という選択肢もあったが、ReactOnRails を継続するのなら React がコ

    スパが良いだろうと判断 ◦ 技術顧問をしてくれていた方が得意だった • TypeScript(新規) ◦ もはや使わない選択肢はなかった ◦ どんなデータをもらっているのか、コンポーネントの props の型を見ればわか る状態は非常に快適 ▪ 間違いなくコンポーネント分割の助けになった ◦ Rails → React への連携部分だけは気をつける 3. 技術紹介 #readyfor_meetup
  9. 24 • AtomicDesign(新規) ◦ デザイナーとの意思疎通のために、フレームがあったほうがよさそう ◦ エンジニアがコンポーネント設計する最初の指標になってよかった ▪ 自分含め、慣れていないエンジニアもいた ◦

    とはいえ銀の弾丸ではない ▪ Molecule or Organism 問題 • Storybook(新規) ◦ きっかけは技術顧問をしてくれていた方の勧め ◦ データの準備をせずに開発できるのでとても快適 ◦ `@storybook/addon-knobs` で状態に応じた変化の確認もらくらく 3. 技術紹介 #readyfor_meetup
  10. 30 • 反省点 ◦ いきなり UI ライブラリを作ると、改善点が見つかったときにアプリケーション側 との往復が大変 ▪ 別スコープでもよかったかもw

    ▪ とはいえ、強制的に設計力が鍛えられた面も • App 特有の UI → アプリケーション側に • デザインシステム文脈のパーツ → readyfor-elements 側に 4. まとめ #readyfor_meetup
  11. 31 • フロントエンドを変えたい!な方にこの場で伝えたいこと ◦ 新しいことをするタイミングは改善のチャンスでもある ▪ Biz側のきっかけに全力で乗っかる! ◦ TypeScript は少しずつでも入れたほうがよい

    ▪ 「面倒なもの」が「開発を楽にしてくれるもの」にすぐ変わる ▪ コンポーネント開発に慣れていないエンジニアがいればなおさら ◦ 社外のスペシャリストに協力を仰ぐ ▪ 全力で仰ぐ!! ◦ スコープを切る勇気を持つ ▪ やらないことを決める意識 4. まとめ #readyfor_meetup