y_nakahira’s blog

エンジニアの技術ブログ。

Inside Frontend #1に参加しました

insideFE 勉強会 フロントエンド

2/25(土)にこちらのイベントに参加しました。

inside-frontend.connpass.com

場所はヤフーさんのオフィスのある東京ガーデンテラス紀尾井町 紀尾井タワーで開催されました。 フロントエンドのこういったセミナーに参加するのは初めてだったのですが、とても実入りのあるセッションばかりで大変勉強になりました。 参加したセッションでメモしていた内容と、アップされていたセッション資料を紹介します(随時追記) (特にいいと思った点は赤字にしています)

セミナーB1 Web over ServiceWorker by @Jxck_

speakerdeck.com

  • Web vs PC APP
  • ここ最近の主戦場は Web vs Mobile
    • モバイル利用時の滞在時間割合はNativeAPPが90%、Browserは10%
    • Browserの利用率を引き上げるには足りないものが多い
      • Native/Low API
      • Installable
      • Performance
      • Permission
      • Offline
        • Browserはネットがつながっていてなんぼの世界
      • etc..
    • 安全にSandbox化したAPIを、ブラウザが標準実装するのを待たずに
  • Service Workerとは？
    • Webブラウザの中でもう一つのプラットフォームを提供する形になってきている
    • クライアントとネットワークのプロキシ的な役割が一つのユースケース
    • Pusherとしての役割も一つのユースケース
    • タスクマネージャーとしての役割もある
      • ToDoアプリなどをオフライン時にはローカルにためておいて、オンラインになった場合にデータをネットワークにつなげたりする
      • 単純にオンライン/オフラインだけではなく、バッテリー残量なども考えてくれる
    • Workerとしても使える
  • ライフサイクルの違い
    • WindowとSWは違うライフサイクルで動く
  • 最近のUpdate情報
    • Foreign Fetch
      • 1クライアントに対して1コントローラだったが、
      • 1stPartyだけでなく3rdPartyのアプリのSWも起動できるようになった
      • SWの責務の切り分けをSW単位でできるようになった
    • Navigation Preload
      • SWが起動していなかった場合、起動するまで待つ必要があったが、
      • レスポンスを返した後にSWを起動できるようになった

セミナーB2 Web フロントエンドにおけるコンポーネント化のアプローチ by @1000ch

speakerdeck.com

  • これまでの振り返り
    • CSSのスタイルガイド
    • workフローに組み込んでいるだけで、何を解決すればいいのか本質的に見えてなかった
  • コンポーネントとはいったい何なのか
  • これまでの問題点
    • コンポーネントの管理手段の問題
      • スタイルガイドはどうなのか
      • エンジニアがスタイルガイドの管理者だった
      • 改善案
        • デザインファイルで管理する
          • コンポーネント単位で分割するのが重要
            • デザイナーが継続してメンテナンスできる
            • 管理するうえでページという概念は不要
          • とはいえ、ページファイルは必要になる…
    • クライアントサイド実装の溝問題
      • デザイナーとデベロッパーでやってることが違うから当然だが…
      • 開発プロセス上の必然
        • 全体像の表現が課せられるデザイナー
          • 客先への提案、モックの作成
        • 実装の前提であり、実装への依存が強い
      • 改善案
        • デザイナーは実装を理解しデベロッパーはデザインを理解する
    • 技術的課題
      • CSSはスコープがなくもろく壊れやすい
      • スコープがなくてつらいリスト
        • 可搬性がない
        • CSS設計は最低限のスパゲッティ対策に過ぎない
      • CSSは設計を工夫してもデザイン次第で破たんする
      • これに対応するアプローチとして
        • CSS ModulesとCSS in JS
        • Shadow DOM
          • スコープの実現
          • Custom Elementsによる要素の再定義
    • 協業実践に向けた方針
      • 職能同士の歩み寄り at 現場
      • 一方通行な開発にならないための説得材料の提示
        • 開発上のメリット
        • 品質上のメリット
      • 先人に学ぶ
      • 説得材料の交換
        • 開発上のメリット：再利用性・保守性
        • 品質上のメリット
      • お互いの作業を小さく分担

セミナーB3 Refactoring CSS: 管理されたカオスへの道のり by @hiloki @cssradar

  • リファクタリングとは
    • 保守しやすく拡張しやすくする
    • CSSにおけるリファクタリングには難しい場面が多々ある
      • UIの変更頻度と変更速度
      • 影響範囲の広さ
      • テスト書くことが難しい
    • リファクタリングはいつするのか？
    • リファクタリングはどうやるか？
      • リファクタリング中はそれだけをする。外部的振る舞いを変えず、内部的振る舞いのみ変えることが重要
      • 問題は小さく砕いて解決する
      • CSSは影響範囲が大きくなりがちなので、小さくする
      • 元のソースコードは消さない
        • .RF_*というプレフィックスをつけるテクニック
        • class=”RF=” + …
          • テストして問題なければ削除する
        • all: initial; を使ったりとかもする
      • ドキュメントを書こう
    • リファクタリングのコツ
      • 技術的負債の返済がリファクタリングの目的
        • 技術的負債　≠　古いコード
        • 技術的負債　≠　汚いコード
        • 技術的負債とは、戦略的で、意識的な「ショートカット」
          • 時間が無いから一時的に対応する、など
        • 短期的な目標だけではなく中長期的な視点を持つ
      • 負債を返すために大切なことは、、
        • 負債を明確にする設計
          • shame.css
          • コメントを確実にそして詳しく記載する
            • コードベースのどこに関連しているのか
            • なぜ必要だったのか
            • どうやって問題を解決しているのか
            • 負債返済の条件
            • これらを行う⇒負債の可視化
          • shame.cssに書くほどではない場合は、、
            • _(アンスコ)つけるなど
          • ちゃんとコメントを残すことが重要
    • まとめ
      • 気が付かない間に負債となってしまったものについて
      • リファクタリングの機会をどうやって作るかが重要
      • リファクタリングとはひらめきで書いたコードを冷徹な頭で見直すこと

所感

どれも刺激的な内容だったのですが、得にセミナーB3のCSSのリファクタリングの話でのコメント技は衝撃を受けました・・。

セッションの合間に行われていたAMA(Ask Me Anything)がすごい良かったと評判だったので、もう少し参加しておけばよかったという後悔はありましたが、全体を通して大変満足した内容だったので次回もぜひ参加したいと思いました。

当日の内容は #insideFEでも見ることができます。