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

by cyber_snufkin

Slide 1

Slide 1 text

©MNTSQ, Ltd. 2023/10/28 Vue.jsプロジェクト設計のベストプラクティスを求めて Vue Fes Japan 2023 クラウドサイントラック

Slide 2

Slide 2 text

©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

Slide 3

Slide 3 text

©MNTSQ, Ltd. 3 フロントエンドにおける設計とは

Slide 4

Slide 4 text

©MNTSQ, Ltd. 4 いきなりですがまず設計フェーズのアウトプットの例

Slide 5

Slide 5 text

©MNTSQ, Ltd. 5 設計フェーズのアウトプットの例 (1) Vue SFCの命名規則

Slide 6

Slide 6 text

©MNTSQ, Ltd. 6 設計フェーズのアウトプットの例 (2) 分割されたVue SFCの論理名、Componentのname属性と構造

Slide 7

Slide 7 text

©MNTSQ, Ltd. 7 設計フェーズのアウトプットの例 (3) APIアクセス部分処理シーケンス（現在はここから新しくなっています）

Slide 8

Slide 8 text

©MNTSQ, Ltd. 8 設計はなぜ必要なのか何故こんなものが必要なのか誰得？

Slide 9

Slide 9 text

©MNTSQ, Ltd. 9 ゼロイチの次のMNTSQ フェーズの境界を超えるために、自らを変化させる

Slide 10

Slide 10 text

©MNTSQ, Ltd. 10 ゼロイチの次のMNTSQ MNTSQは現在多くのエンタープライズ企業様に導入頂いています。 PMF (Product Market Fit) 前の0→1フェーズで必死に探索する時期からその後、如何にスケールさせるかを考えるフェーズに入っています。

Slide 11

Slide 11 text

©MNTSQ, Ltd. 11 コードレベルでの変化ゼロイチの次のMNTSQ 書く速さが重要使われて初めてPSF (Problem Solution Fit) しているか判断出来る PMF前プロダクトの価値を決めるのは市場とにかく使ってもらえるものを早く出したい Scrap & Build ! Feedbackはすぐに反映させたいコードレベルでも、価値観は随分変化しました。

Slide 12

Slide 12 text

©MNTSQ, Ltd. 12 コードレベルでの変化ゼロイチの次のMNTSQ 読む速さが重要書く速さが重要 PMF前現在プロダクトの価値を決めるのは市場とにかく使ってもらえるものを早く出したいプロダクトはすでにBizの前提になっている新機能も既存コードとの界面は意識しながら書く改修はもちろん既存コードを読んで直すコードレベルでも、価値観は随分変化しました。使われて初めてPSF (Problem Solution Fit) しているか判断出来る Feedbackはすぐに反映させたい Scrap & Build !

Slide 13

Slide 13 text

©MNTSQ, Ltd. 13 人を増やすと加速するプロジェクトとは、満たさなければならない幾つかの条件があります。読む速さの重要性読む速さが重要な理由ゼロイチの次のMNTSQ チームの人数が増える人数を増やす事で逆に減速するPJ、ありますよね？新メンバーが参加してAdd Valueできるまでのリードタイムをどう短縮するか

Slide 14

Slide 14 text

©MNTSQ, Ltd. 14 読む速さが重要な理由ゼロイチの次のMNTSQ 読む速さの重要性動くものが早く出来たとしても、読む事にコストが掛かるコードはじわじわと真綿で首を締めるようにプロダクトとチームを蝕みます。読むことにコストが掛かるコードは

Slide 15

Slide 15 text

©MNTSQ, Ltd. 15 チームが読めるものをチームで書くために設計をする

Slide 16

Slide 16 text

©MNTSQ, Ltd. 16 もちろん、チーム全員が読む技術を持っている事も重要です。エンジニア入社時の業務オンボーディングにはデバッグの講習も行います。デバッグ手法の共有速く読める事に拘るゼロイチの次のMNTSQ

Slide 17

Slide 17 text

©MNTSQ, Ltd. 17 現在のMNTSQのフロントエンドは、「高速に開発するため」に「遅くならない事を担保する」ための施策を行っています。速くする前に、まず遅くならないように速くするより、遅くならないゼロイチの次のMNTSQ 遅くなる要因として読めないコードの他に ● 考慮漏れ ● 外部要因 ● 想定外の事態等があります。どれも踏み抜くと、一気に想定完了時期の精度が下がります。 (見積もりが難しくなってしまう)

Slide 18

Slide 18 text

©MNTSQ, Ltd. 18 あとは何と言ってもやっぱりこれですね。質を上げることでスピードも手に入れたい。本当にこうありたい、と日々思っています。質とスピードゼロイチの次のMNTSQ https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition

Slide 19

Slide 19 text

©MNTSQ, Ltd. 19 自分自身の一日の振り返りの中で「今日は捗ったな」と思う日であっても、エディターで書いている時間は思った以上に長くないと思っています。エディター上で書く以外の時間に自分は何をしていたのか調べると、「ドキュメンテーション」と「コミュニケーション」に続いて、「構造と名前」について考えている事が多いことに気が付きました。きちんと作ろうと思うとこの時間、しっかり取る事が多いと思うのですがそれは迷っている時間とも言えると思います。チーム内でそれぞれが個別に考えているとすると、それは最初から高めの解像度で考えておいた方が結果的にスムーズにゴールにたどり着けるのではないか、と考えました。迷わないために決めておく速くするより、遅くならないゼロイチの次のMNTSQ

Slide 20

Slide 20 text

©MNTSQ, Ltd. 20 工数の中身は、コードの行数やドキュメントの量ではなく、思考の深さと量最初に決める事で考える量と迷う時間を削減して「遅くならない事」を実現できるのではないか、と考えました。工数の中身は「思考の深さと量」速くするより、遅くならないゼロイチの次のMNTSQ

Slide 21

Slide 21 text

©MNTSQ, Ltd. 21 決めておくという事はコードを書く際のエンジニアの自由を奪うという見方もできます。コードを書くという行為は実際の所、様々な決断をする事も含まれています。選択肢の前では、設計者と同様の目的に向かって結論を導けるように「なぜ」の部分も含めてドキュメントで提示するという目的意識も設計者に求められると考えています。迷わないためには「なぜ」も必要速くするより、遅くならないゼロイチの次のMNTSQ

Slide 22

Slide 22 text

©MNTSQ, Ltd. 22 設計と開発においてチーム内では、以下の2つを意識するようにお願いしています。 Principle 開放閉鎖の原則（SOLID原則の１つ） ● 拡張に対しては開いている ○ ファイルを追加するだけで機能を拡張できるのがベスト ○ 既存ファイルへの改修は最小限になるように ● 修正に対しては閉じている ○ 修正が必要な場合は、その対象が限定されている YAGNI (You ain't gonna need it) ● いま必要ないものは実装しない

Slide 23

Slide 23 text

©MNTSQ, Ltd. 23 遅くならないために、設計をする

Slide 24

Slide 24 text

©MNTSQ, Ltd. 24 ドキュメントの力を活用する良いドキュメントは、書いた人の知らない所で勝手に見つけてもらえて勝手に疑問に答えて勝手に課題を解決してくれる

Slide 25

Slide 25 text

©MNTSQ, Ltd. 25 ドキュメントの力を活用する良いドキュメントは、書いた人の知らない所で勝手に見つけてもらえて勝手に疑問に答えて勝手に課題を解決してくれる勝手に仕事をしてくれる

Slide 26

Slide 26 text

©MNTSQ, Ltd. 26 良いドキュメントは、書いた人の知らない所で勝手に見つけてもらえて勝手に疑問に答えて勝手に課題を解決してくれる勝手に仕事をしてくれるドキュメントの力を活用するそうする事で、ドキュメントを書く者は自分の力にレバレッジを掛ける事が出来る何人分もの仕事が出来る

Slide 27

Slide 27 text

©MNTSQ, Ltd. 27 まとめ開発サイクルを速く回すためにまず遅くならない事を担保する改修と機能追加が遅くならないために読めるコードを書く開発作業が遅くならないために開発者の思考量と迷いを減らす設計はそのためにする設計フェーズの成果物は、設計者の代わりに勝手に仕事をする

Slide 28

Slide 28 text

©MNTSQ, Ltd. 28 設計と開発の中で考えていること流行とのおつきあい標準との乖離のコントロール機械学習プロダクトの設計

Slide 29

Slide 29 text

Slide 30

Slide 30 text

©MNTSQ, Ltd. 30 MNTSQのSLAで定めている対象ブラウザは Microsoft Edge（Chromium版）と Google Chrome の最新バージョンです。何と言ってもブラウザブラウザの進化を追いかける流行とのお付き合い新しい事はどんどん試せます。ブラウザの進化を味方につけたい！ FrontendチームではChromiumの更新タイミングに合わせて、その内容を皆でチェックする会を開催しています。あまりに面白いのでmtg時間が伸びる傾向に

Slide 31

Slide 31 text

©MNTSQ, Ltd. 31 スタイルシートの進化にも注目していますやはりStyleSheet ブラウザの進化を追いかける流行とのお付き合いやはり難しいものですし（敷居の低さが、タチが良くないとは思いますが） Baselineの進化を先取りできれば、という動機でCSSは（一部を除いて）PostCSSとしています。ちなみに2023年現在のBaseline機能の例としては ● :focus-visible 擬似クラス ● 新しいViewport 単位 ○ svh ○ lvh ● 要素 Nesting ModuleもCSS Valiablesも標準で使えるようになったので、 PostCSSもネタは探し中ではあります

Slide 32

Slide 32 text

Slide 33

Slide 33 text

©MNTSQ, Ltd. 33 現在MNTSQのフロントエンドはVue.jsで書かれています。使い続ける理由としては幾つかありますが、フロントエンド領域での標準的なエコシステムと、乖離が比較的少ないと考えている事も大きな理由です。 Vue.jsを使い続ける理由標準との乖離をコントロールする ● ブラウザのレンダリングエンジンがパースするのはHTMLであってJSXではない ○ JSX、Pug等は使っていません ○ エディタで書いているものをDevToolsでもそのまま見たい ○ 最後の手段でDOMを弄る選択肢も残しておきたい ■ そんな時は余裕なんて無いのでサクッと出来るようにしておきたい ● 将来的な視野にWebComponentsを入れたい ○ 現在すでに大きな開発はComponent志向 ■ PageComponentではなく、個別のComponentから開発するスタイル ● 親から作ると、子コンポーネントに親の知識が入ってしまいがちなのが理由です。

Slide 34

Slide 34 text

©MNTSQ, Ltd. 34 Sass/LESSは、依存しているUIコンポーネントのカスタマイズに限定しています。個別のライブラリの事情に左右されることは避けたいと考えています。実はCSSも CSSプリプロセッサー標準との乖離をコントロールする

Slide 35

Slide 35 text

Slide 36

Slide 36 text

©MNTSQ, Ltd. 36 どのような情報なのか機械学習プロダクトのフロントエンドの設計これらのデータを画面上に表示する中には、様々な条件分岐があります。このケースの爆発を整理することもフロントエンドのミッションです。 MNTSQ Company Deckより抜粋 https://speakerdeck.com/mntsq/mntsq-careersdeck?slide=19

Slide 37

Slide 37 text

©MNTSQ, Ltd. 37 どのような情報なのか機械学習プロダクトのフロントエンドの設計 MNTSQ Company Deckより抜粋 https://speakerdeck.com/mntsq/mntsq-careersdeck?slide=19 ● 構造解析 ○ 文書の木構造 ○ 条項分解 ○ 照応解析 ○ 当事者抽出（契約書上の「甲」「乙」） ● NER ○ 契約締結日 ○ 契約期間 ● 文書分類 ○ 契約類型分類 ● 紐付け ○ 新たに契約書を作成する際に、内容が似ていたり、同一当事者と取り交わした過去の文書を抽出

Slide 38

Slide 38 text

©MNTSQ, Ltd. 38 実際にケースの爆発に立ち向かうために、エンティティの型と輪郭（境界）をはっきりさせて、複雑なリレーションを整理することが重要としてアプローチしています。（リレーションって境界を跨ぐものですしね）リレーションの境界で爆発するケースと、エンティティに閉じて起こるケース、分けて考えます。フロントエンドエンジニアもE-R図を見ます。基本的方針として・今あるAPI設計を信じて乗っかる（追加、改善は一緒にしますが）・エンティティの定義はバックエンドと共通化する・新たな世界を作ったりはしない（勝手にリレーションを想定しない）としています。機械学習プロダクトのデータを扱うディテールについて公開するのはやはりちょっと難しく、ここでは割愛します。

Slide 39

Slide 39 text

©MNTSQ, Ltd. 39 最後に MNTSQは「すべての合意をフェアにする」という目標を掲げています。「すべての合意」は、即ち「すべての人にとっての合意」です。 A11Y(Accessibility) も重要な課題となります。その一方で「機械学習の社会実装」という文脈も、組織の成り立ちから色濃くDNAに持っています。これはこの尖った技術を社会に届ける事、誰が見ても気持ちが持てるものにする事を意味します。これらはフロントエンドエンジニアの重要なミッションです。一緒に取り組んでいける仲間を、本気で探しています。 We are hiring!