2023/10/28 Vue Fes Tokyo Vue.js プロジェクト設計のベストプラクティスを求めて

Transcript

1. ©MNTSQ, Ltd. 2023/10/28 Vue.jsプロジェクト設計の ベストプラクティスを求めて Vue Fes Japan 2023 クラウドサイントラック
2. ©MNTSQ, Ltd. 2 自己紹介 MNTSQ株式会社 ソフトウェアエンジニア フロントエンド担当 安積洋（Azumi Hiroshi）(@cyber_snufkin) エンジニア的変遷 LAMPでバックエンド > フロントエンド > ネイティブアプリPjM > アナリティクス > フロントエンドに戻る（今ここ） Vue.jsはv0.11からv1, v2, v3 2023/08 のv-tokyoでもお話させていただきました Vue.jsの今までをざっくり https://speakerdeck.com/cyber_snufkin/vue-dot-jsnojin-madewozatukuri
3. ©MNTSQ, Ltd. 3 フロントエンドにおける設計とは
4. ©MNTSQ, Ltd. 4 いきなりですが まず設計フェーズのアウトプットの例
5. ©MNTSQ, Ltd. 5 設計フェーズのアウトプットの例 (1) Vue SFCの命名規則
6. ©MNTSQ, Ltd. 6 設計フェーズのアウトプットの例 (2) 分割されたVue SFCの論理名、Componentのname属性と構造
7. ©MNTSQ, Ltd. 7 設計フェーズのアウトプットの例 (3) APIアクセス部分 処理シーケンス（現在はここから新しくなっています）
8. ©MNTSQ, Ltd. 8 設計はなぜ必要なのか 何故こんなものが必要なのか 誰得？
9. ©MNTSQ, Ltd. 9 ゼロイチの次のMNTSQ フェーズの境界を超えるために、自らを変化させる
10. ©MNTSQ, Ltd. 10 ゼロイチの次のMNTSQ MNTSQは現在多くのエンタープライズ企業様に導入頂いています。 PMF (Product Market Fit) 前の0→1フェーズで必死に探索する時期からその後、 如何にスケールさせるかを考えるフェーズに入っています。
11. ©MNTSQ, Ltd. 11 コードレベルでの変化 ゼロイチの次のMNTSQ 書く速さが重要 使われて初めてPSF (Problem Solution Fit) しているか判断出来る PMF前 プロダクトの価値を決めるのは市場 とにかく使ってもらえるものを 早く出したい Scrap & Build ! Feedbackはすぐに反映させたい コードレベルでも、価値観は随分変化しました。
12. ©MNTSQ, Ltd. 12 コードレベルでの変化 ゼロイチの次のMNTSQ 読む速さが重要 書く速さが重要 PMF前 現在 プロダクトの価値を決めるのは市場 とにかく使ってもらえるものを早く 出したい プロダクトはすでにBizの前提に なっている 新機能も既存コードとの界面は 意識しながら書く 改修はもちろん 既存コードを読んで直す コードレベルでも、価値観は随分変化しました。 使われて初めてPSF (Problem Solution Fit) しているか判断出来る Feedbackはすぐに反映させたい Scrap & Build !
13. ©MNTSQ, Ltd. 13 人を増やすと加速するプロジェクトとは、 満たさなければならない幾つかの条件があります。 読む速さの重要性 読む速さが重要な理由 ゼロイチの次のMNTSQ チームの人数が増える 人数を増やす事で逆に減速するPJ、ありますよね？ 新メンバーが参加してAdd Valueできるまでのリードタイムをどう短縮するか
14. ©MNTSQ, Ltd. 14 読む速さが重要な理由 ゼロイチの次のMNTSQ 読む速さの重要性 動くものが早く出来たとしても、読む事にコストが掛かるコードは じわじわと真綿で首を締めるようにプロダクトとチームを蝕みます。 読むことにコストが掛かるコードは
15. ©MNTSQ, Ltd. 15 チームが読めるものを チームで書くために 設計をする
16. ©MNTSQ, Ltd. 16 もちろん、チーム全員が読む技術を持っている事も重要です。 エンジニア入社時の業務オンボーディングにはデバッグの講習も行います。 デバッグ手法の共有 速く読める事に拘る ゼロイチの次のMNTSQ
17. ©MNTSQ, Ltd. 17 現在のMNTSQのフロントエンドは、「高速に開発するため」に「遅くならない事を担保する」ための施策を行っています。 速くする前に、まず遅くならないように 速くするより、遅くならない ゼロイチの次のMNTSQ 遅くなる要因として読めないコードの他に • 考慮漏れ • 外部要因 • 想定外の事態 等があります。 どれも踏み抜くと、一気に想定完了時期の精度が下がります。 (見積もりが難しくなってしまう)
18. ©MNTSQ, Ltd. 18 あとは何と言ってもやっぱりこれですね。 質を上げることでスピードも手に入れたい。 本当にこうありたい、と日々思っています。 質とスピード ゼロイチの次のMNTSQ https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition
19. ©MNTSQ, Ltd. 19 自分自身の一日の振り返りの中で「今日は捗ったな」と思う日であっても、 エディターで書いている時間は思った以上に長くないと思っています。 エディター上で書く以外の時間に自分は何をしていたのか調べると、「ドキュメンテーション」と「コミュニケーション」 に続いて、「構造と名前」について考えている事が多いことに気が付きました。 きちんと作ろうと思うとこの時間、しっかり取る事が多いと思うのですがそれは迷っている時間とも言えると思います。 チーム内でそれぞれが個別に考えているとすると、それは最初から高めの解像度で考えておいた方が 結果的にスムーズにゴールにたどり着けるのではないか、と考えました。 迷わないために決めておく 速くするより、遅くならない ゼロイチの次のMNTSQ
20. ©MNTSQ, Ltd. 20 工数の中身は、コードの行数やドキュメントの量ではなく、 思考の深さと量 最初に決める事で考える量と迷う時間を削減して 「遅くならない事」を実現できるのではないか、 と考えました。 工数の中身は「思考の深さと量」 速くするより、遅くならない ゼロイチの次のMNTSQ
21. ©MNTSQ, Ltd. 21 決めておくという事は コードを書く際のエンジニアの自由を奪う という見方もできます。 コードを書くという行為は実際の所、様々な決断をする事も含まれています。 選択肢の前では、設計者と同様の目的に向かって結論を導けるように 「なぜ」の部分も含めてドキュメントで提示する という目的意識も設計者に求められると考えています。 迷わないためには「なぜ」も必要 速くするより、遅くならない ゼロイチの次のMNTSQ
22. ©MNTSQ, Ltd. 22 設計と開発においてチーム内では、以下の2つを意識するようにお願いしています。 Principle 開放閉鎖の原則（SOLID原則の１つ） • 拡張に対しては開いている ◦ ファイルを追加するだけで機能を拡張できるのがベスト ◦ 既存ファイルへの改修は最小限になるように • 修正に対しては閉じている ◦ 修正が必要な場合は、その対象が限定されている YAGNI (You ain't gonna need it) • いま必要ないものは実装しない
23. ©MNTSQ, Ltd. 23 遅くならないために、設計をする
24. ©MNTSQ, Ltd. 24 ドキュメントの力を活用する 良いドキュメントは、書いた人の知らない所で 勝手に見つけてもらえて 勝手に疑問に答えて 勝手に課題を解決してくれる
25. ©MNTSQ, Ltd. 25 ドキュメントの力を活用する 良いドキュメントは、書いた人の知らない所で 勝手に見つけてもらえて 勝手に疑問に答えて 勝手に課題を解決してくれる 勝手に仕事をしてくれる
26. ©MNTSQ, Ltd. 26 良いドキュメントは、書いた人の知らない所で 勝手に見つけてもらえて 勝手に疑問に答えて 勝手に課題を解決してくれる 勝手に仕事をしてくれる ドキュメントの力を活用する そうする事で、ドキュメントを書く者は 自分の力にレバレッジを掛ける事が出来る 何人分もの仕事が出来る
27. ©MNTSQ, Ltd. 27 まとめ 開発サイクルを速く回すために まず遅くならない事を担保する 改修と機能追加が遅くならないために読めるコードを書く 開発作業が遅くならないために開発者の思考量と迷いを減らす 設計はそのためにする 設計フェーズの成果物は、設計者の代わりに勝手に仕事をする
28. ©MNTSQ, Ltd. 28 設計と開発の中で考えていること 流行とのおつきあい 標準との乖離のコントロール 機械学習プロダクトの設計
29. ©MNTSQ, Ltd. 29 ©MNTSQ, Ltd. 29 流行とのおつきあい 迷ったら「楽な方」ではなく「楽しい方」に倒します。
30. ©MNTSQ, Ltd. 30 MNTSQのSLAで定めている対象ブラウザは Microsoft Edge（Chromium版）と Google Chrome の最新バージョンです。 何と言ってもブラウザ ブラウザの進化を追いかける 流行とのお付き合い 新しい事はどんどん試せます。 ブラウザの進化を味方につけたい！ FrontendチームではChromiumの更新タイミングに合わせて、 その内容を皆でチェックする会を開催しています。 あまりに面白いのでmtg時間が伸びる傾向に
31. ©MNTSQ, Ltd. 31 スタイルシートの進化にも注目しています やはりStyleSheet ブラウザの進化を追いかける 流行とのお付き合い やはり難しいものですし（敷居の低さが、タチが良くないとは思いますが） Baselineの進化を先取りできれば、という動機でCSSは（一部を除いて）PostCSSとしています。 ちなみに2023年現在のBaseline機能の例としては • :focus-visible 擬似クラス • 新しいViewport 単位 ◦ svh ◦ lvh • <dialog>要素 Nesting ModuleもCSS Valiablesも標準で使えるようになったので、 PostCSSもネタは探し中ではあります
32. ©MNTSQ, Ltd. 32 ©MNTSQ, Ltd. 32 標準との乖離をコントロールする 時代の移り変わりに負けないために
33. ©MNTSQ, Ltd. 33 現在MNTSQのフロントエンドはVue.jsで書かれています。 使い続ける理由としては幾つかありますが、 フロントエンド領域での標準的なエコシステムと、乖離が比較的少ない と考えている事も大きな理由です。 Vue.jsを使い続ける理由 標準との乖離をコントロールする • ブラウザのレンダリングエンジンがパースするのはHTMLであってJSXではない ◦ JSX、Pug等は使っていません ◦ エディタで書いているものをDevToolsでもそのまま見たい ◦ 最後の手段でDOMを弄る選択肢も残しておきたい ▪ そんな時は余裕なんて無いのでサクッと出来るようにしておきたい • 将来的な視野にWebComponentsを入れたい ◦ 現在すでに大きな開発はComponent志向 ▪ PageComponentではなく、個別のComponentから開発するスタイル • 親から作ると、子コンポーネントに親の知識が入ってしまいがちなのが理由です。
34. ©MNTSQ, Ltd. 34 Sass/LESSは、依存しているUIコンポーネントのカスタマイズに限定しています。 個別のライブラリの事情に左右されることは避けたいと考えています。 実はCSSも CSSプリプロセッサー 標準との乖離をコントロールする
35. ©MNTSQ, Ltd. 35 ©MNTSQ, Ltd. 35 機械学習プロダクトでのフロントエンドの設計 課題感だけちょっとお話します
36. ©MNTSQ, Ltd. 36 どのような情報なのか 機械学習プロダクトのフロントエンドの設計 これらのデータを画面上に表示する中には、 様々な条件分岐があります。 このケースの爆発を整理することも フロントエンドのミッションです。 MNTSQ Company Deckより抜粋 https://speakerdeck.com/mntsq/mntsq-careersdeck?slide=19
37. ©MNTSQ, Ltd. 37 どのような情報なのか 機械学習プロダクトのフロントエンドの設計 MNTSQ Company Deckより抜粋 https://speakerdeck.com/mntsq/mntsq-careersdeck?slide=19 • 構造解析 ◦ 文書の木構造 ◦ 条項分解 ◦ 照応解析 ◦ 当事者抽出（契約書上の「甲」「乙」） • NER ◦ 契約締結日 ◦ 契約期間 • 文書分類 ◦ 契約類型分類 • 紐付け ◦ 新たに契約書を作成する際に、内容が似てい たり、同一当事者と取り交わした過去の文書 を抽出
38. ©MNTSQ, Ltd. 38 実際にケースの爆発に立ち向かうために、 エンティティの型と輪郭（境界）をはっきりさせて、 複雑なリレーションを整理することが重要としてアプローチしています。 （リレーションって境界を跨ぐものですしね） リレーションの境界で爆発するケースと、エンティティに閉じて起こるケース、分けて考えます。 フロントエンドエンジニアもE-R図を見ます。 基本的方針として ・今あるAPI設計を信じて乗っかる（追加、改善は一緒にしますが） ・エンティティの定義はバックエンドと共通化する ・新たな世界を作ったりはしない（勝手にリレーションを想定しない） としています。 機械学習プロダクトのデータを扱う ディテールについて公開するのはやはりちょっと難しく、ここでは割愛します。
39. ©MNTSQ, Ltd. 39 最後に MNTSQは「すべての合意をフェアにする」という目標を掲げています。 「すべての合意」は、即ち「すべての人にとっての合意」です。 A11Y(Accessibility) も重要な課題となります。 その一方で「機械学習の社会実装」という文脈も、組織の成り立ちから色濃くDNAに持っています。 これはこの尖った技術を社会に届ける事、誰が見ても気持ちが持てるものにする事を意味します。 これらはフロントエンドエンジニアの重要なミッションです。 一緒に取り組んでいける仲間を、本気で探しています。 We are hiring!
40. ©MNTSQ, Ltd. 40 オープンオフィスやります！
41. ©MNTSQ, Ltd. 41
42. ©MNTSQ, Ltd. 42 MedPeerさん、hakomonoさんと Vue Fesアフターイベントやります！ なんと！ @kazuponさんも登壇！
43. ©MNTSQ, Ltd. 43 ご清聴ありがとうございました！