Storybookを使って安心しながら開発を進める_ラクスルテレビCMオンラインストア開発

© RakSul,Inc. All Rights Reserved. FrontendNight 実践 Vue x Storybook
Storybookを使って安心しながら開発を進める ~ ラクスルTVCMオンラインストア開発 ~ ラクスル株式会社　古谷文弥 2019年2月20日ラクスル×KCF　FrontendNight 実践 Vue x Storybook

自己紹介 Fumiya FURUYA (@_fuya) • 前職ではHTML5ゲームプラットフォームの開発 • 2018年8月中途入社 • フロントエンドミートアップ Meguro.es 運営 • 実家がいちご農家 Web Front-end Engineer

• 会社・事業紹介 • TVCMオンラインストアについて • 期間内で安心してリリースする技術選定の話 • まとめ本日話すこと

会社・事業紹介

「仕組みを変えれば、　　　　世界はもっと良くなる」 VISION Better System, Better World

ラクスルの事業意義は産業の在り方をトランスフォーメーションすること Mission

伝統的で巨大なBtoBの業界のデジタル化を推進する Mission

TVCMオンラインストアについて 1枠で買えるオンラインストア

• あのテレビ局のCMの放映が15秒10万円〜!? • 詳しくはこちらのサイトを御覧ください ◦ https://tvcm.raksul.com/store TVCMオンラインストアとは

※ 番組名、価格はサンプルです。発表時点のものです。

• リリースしたい時期がある程度決まっている • メンバーのうちフロントエンジニアは2名 • 開発初期時点では、価格・番組の本番データは無い ◦ ある程度見切りで作り始める ◦ プロトタイプの作成・技術検証も同時にやる • 番組表UIとカート、申込機能を作るオンラインストアを作ろう！要求は...

短期間で安心してリリースする為の技術選定期間・安心を考えて過不足のない選定をする

• 番組表・カートなどは既に概念があり、作りやすい ◦ 要件を詰めず、モックを見せながら進められそう • 業界知識が開発チームに無く、仕様変更が必至 • サービスが当たるかどうかわからない、仕様変更が必至 • 本番データが揃っていない、仕様変更が... • なんとなく進めたら確実に炎上！変更に臨機応変に対応するため速度を出そう！要求を整理して技術選定の基本方針をたてる

• 既存のレールに乗る • 人間は本質に集中する • 怪しいポイントには規約を作る • リスクを考えて対策を打つ速度を出すために基本方針を定めた

• 既存のレールに乗る ◦ Vue.js の中でも規約があるNuxt.jsを利用 ◦ コンポーネントの粒度は Atomic design を意識 • 人間は本質に集中する • 怪しいポイントには規約を作る • 実装物のリスクを考えて対策を打つ速度を出すために基本方針を定めた

• Vue.js のフレームワーク ◦ Router, Store, SSR, webpack などを含む ◦ ディレクトリ構成のレールがある ▪ エンジニア間で共通認識を持てる ◦ いざとなったら取り外せそう既存のレールに乗る Nuxt.js を利用当時はこちらのロゴ。 v1を使用 https://nuxtjs.org/

• 粒度の認識合わせ会を実施 ◦ ポンチ絵を元に認識合わせ ◦ エンジニア間の認識を揃えた • 自分が思っているレールと他人が思っているレールをすり合わせるのはとても大事既存のレールに乗る Atomic Design を意識プロジェクタで、ホワイトボードにモックの画像を移しながらエンジニアで粒度の認識を合わせている写真がありました。 (非公開)

• 既存のレールに乗る • 人間は本質に集中する ◦ lint formatterは初めに導入 ◦ TypeScriptの導入を考える ◦ css modulesを使ってクラス名を考えずに済ませる • 怪しいポイントには規約を作る • 実装物のリスクを考えて対策を打つ速度を出すために基本方針を定めた

• prettier, eslint, stylelint などを使う • CIを使って、lintが通らないものはmergeさせない ◦ 書き方によるレビューの往復をさせない • エディタの自動修正を設定しておく ◦ そもそも書き方を意識させない人間は本質に集中する lint formatter を入れる

• 型というドキュメントが定義される • 型があれば変更に強くなる • 今回は見送りした ◦ Nuxt + TypeScript に慣れていない ◦ 周辺ツールの導入・管理コストを積みたくなかった ◦ Nuxt 2.4 が出た今だったら導入したかもしれない人間は本質に集中する TypeScriptの導入を考える

人間は本質に集中する CSS Modules を入れる <template> <span :class="$style.monthUnit">月</span> </template> <style lang="scss" module> .month-unit { font-size: $large-font-size; } </style> 開発環境ファイル名本番環境ハッシュ値元のクラス名

• 既存のレールに乗る • 人間は本質に集中する • 怪しいポイントには規約を作る ◦ z-index, color, @mixin を使う温度感を決める • 実装物のリスクを考えて対策を打つ速度を出すために基本方針を定めた

怪しいポイント = コンポーネントに閉じないであろう箇所 • 色の定数これを使う • z-indexはこれで管理する • store はこの方法で接続する等々、これらの認識を合わせる前提としてはコンポーネントに閉じる事が大事怪しいポイントには規約をつくる最低限のルールだけ決める

• 既存のレールに乗る • 人間は本質に集中する • 怪しいポイントには規約を作る • 実装物のリスクを考えて対策を打つ ◦ 何が怖いかを考えてどんな対策をするか、しないか速度を出すために基本方針を定めた

ところで、一番のリスクってなんだろうかそもそもロジックのミス通しで動いているか不安エッジケースのUI ロジックの考慮漏れ仕様変更でどこに影響があったかわからない

ところで、一番のリスクってなんだろうかそもそもロジックのミス通しで動いているか不安エッジケースのUI ロジックの考慮漏れ仕様変更でどこに影響があったかわからない Storybook ユニットテスト e2e テストスナップショットテスト

• 複雑な処理をしている箇所は、関数にしてテストを書く ◦ テストが書けない場合、関数が仕事しすぎ ◦ それぞれの関数の責任が分かれる • 境界値の振る舞いなどもカバーできる ◦ テストを書くことで考慮漏れを減らせる Storeのビジネスロジックのユニットテストを書く

• すべてのコンポーネントに対してエッジケースを書く ◦ 時刻のComponentであれば、8時、11時、25時など考えられるパターンを書いておく • デザインカンプではエッジケースの漏れは多い ◦ 結合してから「想定していませんでいた」を減らす Storybookを書く

• こんなカンプが来たらデザイナーに何か聞く? ◦ 100万円以上の商品は? ◦ 長い番組名は? ◦ 番組放送時間が短かったら? • デザイナーとのコミュニケーション大切 ◦ カンプで全パターン網羅は不毛 ◦ ただ、動かしてみて分かる事もある ◦ Storybookで再現しようデザインカンプではエッジケースの漏れは多い

• @storybook/addon-storyshots を使う ◦ Storyがテストのケースになる ◦ Storyの実行結果のHTMLをGitで管理するイメージ ▪ Storybookでエッジケースを試すほど、精度が上がる ◦ 末端の実装修正による影響範囲が分かるスナップショットテストを書く

exports[`Storyshots Atoms/PriceText CM枠の価格 1`] = ` <span class="mock--price mock--large" > ¥1,000 </span> `; exports[`Storyshots Atoms/PriceText CM枠の価格桁区切り 1`] = ` <span class="mock--price mock--large" > ¥1,234,567 </span> `; スナップショットテスト

exports[`Storyshots Atoms/PriceText CM枠の価格 1`] = ` <span class="mock--price mock--large" > - ¥1,000 + $1,000 </span> `; exports[`Storyshots Atoms/PriceText CM枠の価格桁区切り 1`] = ` <span class="mock--price mock--large" > - ¥1,234,567 + $1,234,567 </span> `; ￥を＄に変更してみる

影響するコンポーネント一覧がわかる $ git status modified: components/Atoms/PriceText/__snapshots__/index.stories.storyshot modified: components/Molecules/CartItem/__snapshots__/index.stories.storyshot modified: components/Molecules/OrderItem/__snapshots__/index.stories.storyshot modified: components/Molecules/OrderTotalPrice/__snapshots__/index.stories.storyshot modified: components/Molecules/Program/__snapshots__/index.stories.storyshot …… • 影響範囲をGitで管理できる • 想定外の影響がないか、レビューを通せる

• e2eはデグレ検知に効果が高い方法の1つ ◦ しかし記述・メンテコストが高い ◦ 仕様変更との戦いになる今回は... 複数ページにまたがる仕様の変化が予想された人数的にもスピード的にも面倒を見るのは当初は断念したリリースのときの安心感を無くすという負債を積むこととしたコストの高いe2eを書くのか

まとめ

• 何がリスクかを想定する。対応しないのもまた対応 ◦ 技術力・知識は対応手段の選択肢を増やす ◦ 想定した選択の精度をあげる必要がある • 負債を積まずに高速な開発はできません ◦ 何を負債とするか取捨選択が大事 ◦ 負債は把握して、返せるものだけ借りましょう過不足のない選定が大事

仕組みを変えれば、世界はもっと良くなる Our Vision

Storybookを使って安心しながら開発を進める_ラクスルテレビCMオンラインストア開発

Storybookを使って安心しながら開発を進める_ラクスルテレビCMオンラインストア開発

More Decks by Fuya

Other Decks in Programming

Featured

Transcript