Web Developer's Struggle Memories

日々の業務から思ったこと、学んだことを書き連ねていきます。

「WEBフロントエンドにおけるソフトウェア設計の考察」の参加メモ

今年の2月に行われた OOC(Object Oriented Conference) の中で数少ないフロントエンドに関するトークに参加してきたときのメモ。 ぶっちゃけこのスライド見ればこの下のメモは不要。

現代フロントエンドの難しさ

  • 開発環境の多様化・複雑化
  • フロントエンドの難しさは道具選びではない
  • ユーザー操作の複雑化
    • リッチ/インタラクティブなUI
    • 複数状態の組み合わせによる表示変化
    • 操作に応じて動的に切り替わる画面表示
  • 画面の表示状態が複雑
  • これらをいかに管理するか

フロントエンドと「ドメイン

  • フロントエンドにはない
    • ドメイン
    • 結局表示して終わり
    • ロジック
    • そんなことはない
  • ドメインの解決ンにどう取り組むかが、フロントとバックのアプローチが違うだけ
  • フロントエンドの関心事
    • 操作
    • 表示

フロントエンドを「設計する」

  • 画面
    • UI設計
  • ソフトウェア
    • モジュール設計、依存設計
  • 画面の設計は重要
  • それだけでは完結しないはず
  • その先のソフトウェアの設計が必須
  • Atomic Design
    • UI 設計まで
    • その先のソフトウェア設計には至らない
  • オブジェクト思考
    • 操作と表示に注目
  • ちゃんと?設計?
    • 画面とその奥のソフトウェア
    • それぞれへの適切な手法
  • ロジック
  • フロントにおけるクリーンアーキテクチャ
    • 重要なのは同心円ではなく依存性のルール
    • 薄いそうなのは単なる表示の問題
    • 切り出した側面でしかない
    • UI 以外のものに焦点を当てたから外心円になっただけ
    • 同心円は入れ子状になる(フラクタル状態)

Q&A

  • オレオレQAについて、社内で似たようなことを行ってみたが、「本と違う!」って言われて浸透しなかったがそういう事は起きなかったのか?その場合はどうした?

→ そもそもなんでQAを使っているのか?を問い直すのが良さそう。本が提供している考え方をどう使うか?という議論になると思う。

  • Flux では データストアの流れを定義しているが、ソフトウェアの設計までは解決していないが、オレオレQAでは何を表しているのか?

→ システム全体の見通しを良くするために、設計をするためにオレオレの解釈をしていました。

  • QAの利点の一つはレイヤーをテスタブルにすることが上げられるが、そこは考慮しているか?

→ 考慮している。コントローラのテストをひたすら書いていくと、それはUIのテストになる。コントローラは単なる関数なのでテストを書けるが、viewはコンポーネントを分けて行くが、メソッドの対応づけしかないので、そこを考えるとテスタブルになる。

  • VIPER が iOS 関連のQAの話で、参考になるかも