東京で開催された「Inside Frontend vol.2」の参加レポートです。

https://freshlive.tv/tech-conference/189060

freeeのアクセシビリティ、いまとこれから

  • UX成熟度のモデル
    • アクセシビリティに言い換えても通用する
  • 一人から始めるWebアクセシビリティ
  • まずはアクセシビリティを認識してもらうことから始める
    • Qiitaチーム、社内向けSNS、輪読会などで知識を共有
  • 課題が見えてきた
    • マウスオーバー依存のUIを改善する
    • 色弱の人向けの実装
    • チャットボットの聴覚障がい者向け対応
  • アクセシビリティが連想されるようになってきた
    • 飲み会でvoiceoverのプレゼンｗ

freeeのアクセシビリティ

  • 多数のアプリがある
    • 多すぎるのでとりあえずWebサイトから
      • W3G Easy checkを使う
  • 結果: 画像に代替テキストが入っていない、水色テキストのコントラスト、フォーム系のエラー表示
    • マルバツが空のi要素なので読み上げられない
    • 図に対する代替テキストがない
    • ヘルプのキャプチャに対して代替テキストがない
    • エラーがポップアップなので読み上げられない
  • アクセシビリティ中根さんに聞いてみた
    • 機能は優れているがかなり試行錯誤しないと使えない
    • 読み上げられない場合がある、アイコンにラベルがない
    • divボタンが押せない
    • labelにforがなく紐付けられていない
    • サジェストにwai-ariaが設定されておらず読み上げられない
    • iOS版は機能が絞られているので全容が把握しやすい
    • 押せないケースははあまり無い
    • だいたいちゃんと読んでくれるがボタンやアイコン系やテキストフィールド系がおしい
    • よく使う機能やコンポーネントは把握できた、人はマークアップを間違えるときにある程度法則がある→ahomuさんブログ

Webサイトのこれから

  • 有志でEasy checkの和訳
  • UIレビュー
  • マークアップのサンプルを用意する
  • 課題をあげておく
  • チェックプロセスの整備
    • CIで回す前にまずは人間の手で整備していく

既存のUI修正に向き合う

  • 機能追加によるユーザビリティの向上
  • UI修正によるユーザービリティ向上
  • UXメトリクスの必要性å

アクセシビリティの必要性に向き合う

  • 個人の正義に頼らず、目標と成果の明示が必要

現場の ES201x とアーキテクチャの変遷と未来

  • アーキテクチャの変遷を整理
  • 自分のコードの腐る腐らない部分の目利きができるように

フレームワークふり返り

  • 太古: セルフスクレイピングの時代
    • 手動でdomツリーを書き換える時代
    • 不安定なDOMをjqueryが吸収
    • IE6が死ねず長期化
  • テンプレーティングの時代
    • コンポーネントが定着し始めた
    • HTMLの初期生成がクライアント側へ
    • 二重テンプレート問題, SEO問題
  • データバインディングの時代
    • 文字列を展開するものからツリーを出力するものへ
    • 効率的な部分書き換え, リスト展開
    • MVVMの輸入
  • 現代
    • Client Side MVCの終焉
    • Rails由来のBackbornのMVCモデルは破綻
      • クラサバで必要な抽象は別物
      • 分解&再構築
    • 単方向データフローへ
    • Flux/とObservableの時代
      • EventとStateとViewを完全に分離
      • FRPの概念を輸入
    • Componentの内側に隠れたStateの存在は悪
    • EventストリームからStateのスナップショットを生成
  • フレームワークのトレンド
    • ハード/ソフトの発達によって
      • メモリ上にたくさんデータを置くようになる
      • ブラウザの機能をより賢く実装する
      • 富豪的な設計→マイクロチューニング

AltJSが果たした役割

  • 2015への文法追加

最近盛り上がる言語

  • 静的な型環境があること
  • 柔軟な型宣言があること
    • なぜ型？ -> GUIのテストがしづらいので静的検査で済ませたい

未来の話

  • Viewの末端はCustom Elementsへ
  • Web Componentsが来たら 〜デザインの〜実装が死ぬ
    • マテリアルデザインやBootstrapなど
  • mizchさんがqiitaでやったこと
    • グローバル参照渡しESM
    • View層とState層を分離(flow)
  • とりあえずやっとけ
    • prettier
    • eslint: no-unused-vars

フロントエンドエンジニアとは

  • SPAつくってもいいしサーバー齧ってもいいしゴールは人それぞれ
  • スピードを突き詰めるUXなのか

  • 継続して価値を届けるためのコード品質なのか

  • Web特有のアーキテクチャから普遍的なGUI設計の合流

  • OOP, FP, GUI設計論の知見がごった煮でそれぞれの理想をぶつけ合う戦場と化している

コンポーネントTDDの実践から見えたもの

  • React入門書出るよ
  • テストはE2Eやスナップショットが多い

コンポーネントの単体テストについて

  • 以前はコンポーネントの単体テストは書かない
    • テストケースが複雑でコストが高い
    • リリース後にE2Eテストやスナップショットを入れれば良いと考えていた
  • リリースしても手が空かない
  • E2Eテストの導入が辛い
    • 開発フローにどう組み込むか？
  • レビューに時間がかかる
    • テストがないので毎回動作確認が必要
  • レビューに時間がかかるとPR出すのが億劫になる

コンポーネント単体テストとは

  • Reactはenzyme, vue/test-utils
  • shallow関数(仮想DOM)とmount関数(実DOM)
  • コンポーネントによって描画される要素の確認、イベントの確認
  • 新規コンポーネントは必ず単体テストを書く
  • 不安感
    • すぐ壊れるテスト
    • 実装に対するテストケースになる
    • TDDでやってみようという気持ちになる

コンポーネントTDD

  • 仕様に対するテストケースが自然に書けるはず
  • 実装が変わっても仕様が変わらなければテストは壊れないはず

TDDの進め方

  1. テストケースを書く
  2. テストを動かして失敗することを確認
  3. 実装する
  4. リファクタリングする

細かくステップを踏むのがコツ
仮実装で良いのでテストが通るようなコードを書く
仮実装すると思考が進む

アサーションを追加→テスト落とす→実装→テストを通す…ループ
仕様を考えてからテストを書く

TDDのコツ

  • Component Tests with Vue.js
  • View的なロジックをテストする
    • v-ifの出し分けなど
    • vue自体のテストにならないようにする
  • enzyme（エンザイム）、vue/test-utilsを知る
    • find出来ないケースを知る
    • shallow関数でmountedが呼ばれる
    • mocks, stubs, localVue, storeなどの使い方
      • shallowで落ちる時はmountedで試す
      • DOMが書き換わっても変数が書き換わってないなど
        • mountedしたのはupdateしないといけない

TDDやってみて

  • 最初はいつもより時間がかかる
    • テストを考えると手が止まる
  • 実装の時間は短くなる
  • トータルの時間はあまり変わらない
  • 安心感がある
    • 想定通り動いている状態をキープできる
  • テストコード
    • 無駄なテストケースは書かなくなるがテストケース自体は多くなるかも
    • テストケースのまとまりが「振る舞い」に向くのは良い
    • テストコードもソースコード
      • レビューする文化も根付かせよう
  • テストコードを読みやすくする方法を考えよう

日経電子版を速くするためにやっていること

  • サイトの速度は重要KPI
    • サイトの速度が1秒落ちるとユーザーエンゲージメントは5%下がるという結果が出た
  • サイトの速度は検索結果にも影響してくる
  • チーム発足時
    • 最重要KPIはスピードを高めること
    • 開発環境
      • 内製
      • アジャイル、継続的デリバリー
  • 初回起動時に時間がかかっていた
  • 継続的な計測はspeedcurveを利用して他プロダクトと比較

どう早くしていくか

  • CDNを使う
    • 速報に対応するためキャッシュクリアに注力
  • Fastly
    • 十分なPOPの数
    • VCLの設定が可能
    • APIが充実している
    • キャッシュの削除（Instant Purge）が150ms
  • システム構成
    • マイクロサービス
    • HTTP APIのREST設計
  • IPv6はアクセス全体の20%ほど
  • Promise Cache
  • imgix, http api

フロントエンドの高速化

  • あとでいいことはあとでやる
    • クリティカルレンダリングパスを減らす
    • JSは非同期で読み込む
      • async/deferをつける
      • jsはpolyfil.ioのonload後に初期化される
      • 一番初めに映るCSSだけインラインで書く方法も
      • セクション単位の遅延ロード
      • スケルトンスクリーンの実装
  • 必要なことは先にやる
    • HTTP/2 Server Push
      • 画面の表示に必要なリソースはなるべく早く
    • Resources Hints
      • 次の画面をprefetchしておく
      • prerender … マウスカーソルを載せたらリンク先をロード
      • Service Workerによる事前キャッシュ
      • サブリソースはLinkヘッダから取得
    • キャッシュ問題の対策
      • ログイン・ログアウト時のURLをキャプチャして判別
    • pictureタグを使って最適な画像を配信
    • Network Infomation API便利そう
    • まずは分析Lighthouseをwebspeedtestを使う
    • CDN,サーバのパフォーマンスも大事
    • 速くすることを考えるより、遅くなる要素を減らしていくことが一番大事

一言感想

今年も引き続きSPAの年になりそう。
結局アクセシビリティも大事だけどパフォーマンスも重要だし、ますます細かいところまで気を配らないといけなくなってきた印象。

フロントエンドエンジニアつらいけどポジティブに捉えると「やること多くて飽きない」職業ではあるよね〜って感じ。
mizchさんもそうだけど、サーバーも扱えるフロントエンドエンジニアの方がお得感あるからそっち目指していきたいと思った。