「WEBフロントエンドにおけるソフトウェア設計の考察」の参加メモ
今年の2月に行われた OOC(Object Oriented Conference) の中で数少ないフロントエンドに関するトークに参加してきたときのメモ。 ぶっちゃけこのスライド見ればこの下のメモは不要。
現代フロントエンドの難しさ
- 開発環境の多様化・複雑化
- フロントエンドの難しさは道具選びではない
- ユーザー操作の複雑化
- リッチ/インタラクティブなUI
- 複数状態の組み合わせによる表示変化
- 操作に応じて動的に切り替わる画面表示
- 画面の表示状態が複雑
- これらをいかに管理するか
フロントエンドと「ドメイン」
フロントエンドを「設計する」
- 画面
- UI設計
- ソフトウェア
- モジュール設計、依存設計
- 画面の設計は重要
- それだけでは完結しないはず
- その先のソフトウェアの設計が必須
- Atomic Design
- UI 設計まで
- その先のソフトウェア設計には至らない
- オブジェクト思考
- 操作と表示に注目
- ちゃんと?設計?
- 画面とその奥のソフトウェア
- それぞれへの適切な手法
- 画面:Atomic Design
- ソフトウェア:オブジェクト指向
- ロジック
- 表示と操作のルール
- ビジネスロジックではない
- フロントにおけるクリーンアーキテクチャ
Q&A
- オレオレQAについて、社内で似たようなことを行ってみたが、「本と違う!」って言われて浸透しなかったがそういう事は起きなかったのか?その場合はどうした?
→ そもそもなんでQAを使っているのか?を問い直すのが良さそう。本が提供している考え方をどう使うか?という議論になると思う。
- Flux では データストアの流れを定義しているが、ソフトウェアの設計までは解決していないが、オレオレQAでは何を表しているのか?
→ システム全体の見通しを良くするために、設計をするためにオレオレの解釈をしていました。
- QAの利点の一つはレイヤーをテスタブルにすることが上げられるが、そこは考慮しているか?
→ 考慮している。コントローラのテストをひたすら書いていくと、それはUIのテストになる。コントローラは単なる関数なのでテストを書けるが、viewはコンポーネントを分けて行くが、メソッドの対応づけしかないので、そこを考えるとテスタブルになる。
- VIPER が iOS 関連のQAの話で、参考になるかも