オブジェクト指向の視点からのフロントエンドエンジニアリングシステム

はじめに

プロセス指向の角度からフロントエンドエンジニアリングを見ると、各プロセス、およびプロセス間の接続です：

（プロセス指向の視点での）フロントエンドエンジニアリング = プロセス + プロセス間の接続

その中で、プロセスは効率問題の解決を目的とし、プロセス間の接続はより多く体験問題に注目します。フロントエンドワークフローに関連するすべてのエンジニアリング施設はこの基準で分類でき、プロセスか接続のいずれかです

逆に問題の角度から見ると、体験問題は接続を通じて緩和できます。例えば上流下流のツール/プラットフォームをつなぐ、バッチ処理ツールを書く、管理プラットフォームを構築するなど。効率問題はより優れ、より速いプロセスを通じて解決する必要があります。例えば協力モデルのアップグレード、構築速度の最適化など

しかしプロセス指向の分類にもいくつかの問題が存在します。例えば：

いくつかの類似したプロセスが複数の生産环节に横跨します：パッケージングツールは開発、構築段階に跨り、デバッグスイートは開発、テスト段階に跨り、イテレーション管理は全フローに跨ります
プロセス間に大量の接続が必要です：いくつかのツールは配合して使用する必要があります。例えばスキャフォールディングと公共ライブラリ、エディタと構築ツール、デバッグスイートなど
プロセスの境界が不明確で、階層構造が不足しています：簡単に一堆の零散したツール/プラットフォームが生じます。例えば性能ログ导出ツール、性能分析診断ツール、性能監視プラットフォーム、性能データ可視化プラットフォームなど

既然如此、視点を変えて観察してみましょう。オブジェクト指向の角度から見ます

一.フロントエンドエンジニアリング中の OO 概念

オブジェクト

オブジェクトは、フロントエンドアプリケーション生産活動中の各実体の抽象です。その中でいくつかのオブジェクトは主体（例えば異なる役割を果たす人）で、他は客体（例えばツール、プラットフォームなどの各種具体事物）です

オブジェクト間は一連の交互行為を通じてフロントエンドアプリケーションの開発とデリバリーを完了します：

プロダクトマネージャー：現実生活中的問題からユーザー需要を発見し、ユーザー需要をプロダクト需要に変換
デザイナー：プロダクト需要に基づいて UI 効果と交互操作フローを設計し、設計稿の形式で出力
バックエンドエンジニア：プロダクト需要に基づいてデータモデルを設計し、データ読み書きを実装し、前後端データプロトコルを約定
フロントエンドエンジニア：プロダクト需要に基づいて設計稿を還元し、前後端データプロトコルに基づいて交互機能を実装し、フロントエンドアプリケーションを産出
テストエンジニア：フロントエンドアプリケーションを十分にテストし、プロダクト需要が一貫して満足されることを保証
運用エンジニア：品質が信頼できるフロントエンドアプリケーションを生産環境にデプロイ
運営専員：オンライン済みのフロントエンドアプリケーションをユーザーに推廣

プロセス指向の視点と異なり、ここではよりオブジェクトとオブジェクト間の交互行為を关心します。フロントエンド開発作業を例に：

プロセス指向視点：現在開発段階にあり、モジュール拆分、コーディング、デバッグなどのステップを通じて開発タスクを完了し、次にプロジェクトは次の段階に入ります
オブジェクト指向視点：私はフロントエンドエンジニアで、プロダクトマネージャー、デザイナー、バックエンドエンジニアが提供するプロダクト需要、設計稿とデータプロトコルが必要で、フロントエンドアプリケーションを産出してテストエンジニアに渡します

つまり：

（オブジェクト指向の視点での）フロントエンドエンジニアリング = オブジェクト + オブジェクト間の関係および交互

その中で、オブジェクトの数量は体験に関係します。オブジェクト数量が多いほど、主体が注目するものが多くなり、体験は悪くなります。オブジェクト依存関係の複雑さは効率を決定します。オブジェクト関係が複雑なほど、交互が多く煩雑になり、効率は低くなります

インターフェース

インターフェースは、フロントエンドアプリケーション生産過程中のいくつかの抽象産物で、最終デリバリー物に直接体现されません。例えば：

プロトコル/約定
規範

これらの抽象産物はオブジェクト間通信のメッセージフォーマットを定義し、人と人、ツールとツール、ツールと人が緊密に協力できるようにします

抽象クラス

抽象クラスも、フロントエンドアプリケーション生産過程中のいくつかの抽象産物で、異なるオブジェクト間の関連と交互方式を定義します。例えば：

研發モード
技術方案
フロー標準
ツールチェーン

インターフェースと異なり、これらの「抽象クラス」は複数のオブジェクト間の連動関係を拘束できます。インターフェースが拘束するのは 2 つのオブジェクト間の 1 回の交互行為です

二.オブジェクト指向のフロントエンドエンジニアリング設計

フロントエンド生産活動の审视

まず視点を白雲の上に十分に高い場所に這い上がらせて、フロントエンド生産活動を見ます：

現実問題（ユーザー需要） -> フロントエンド生産活動 -> （解決策）フロントエンドアプリケーション

P.S. フロントエンド生産活動とは、フロントエンドプロジェクトが需要から发布オンラインまでの全ライフサイクルを指します

つまり、フロントエンドアプリケーションを通じて現実問題を解決し、中間の生産活動がフロントエンドエンジニアリングが注目する領域です

フロントエンドエンジニアリングを 1 つのシステムと見なすと、その运作原理は概ねこの通り：

いくつかの人々が、いくつかの交互を通じて、いくつかの中間産物を生成し、最終的にフロントエンドアプリケーションをデリバリー

ユーザー需要を入力し、フロントエンドアプリケーションを出力します。フロントエンドエンジニアリングがこれまで解決してきた問題は無非 2 つ：

効率：いくつかの人々を減少、いくつかの交互を減少、いくつかの中間産物を規範化
体験：いくつかの交互を簡素化、いくつかの中間産物を減少

P.S. もちろん、品質は前提条件です。CAP 中の P のように、実質選択の余地がありません。そのため品質を損なう効率、体験向上は討論範囲内にありません

フロントエンドエンジニアリングのモデリング

まず、システム中のすべての主体オブジェクトを識別：

プロジェクトマネージャー
プロダクトマネージャー
デザイナー
フロントエンドエンジニア
バックエンドエンジニア
テストエンジニア
運用エンジニア
運営専員

ではトップ層はフロントエンド生産プラットフォームで、研發モードとフロー標準を定義し、これらの役割が協同作業できるようにします：

-----------------------------------------------------
|                    フロントエンド生産プラットフォーム                    |
-----------------------------------------------------
| プロジェクトセンター | 研發センター | 发布センター | 監視センター | 運営センター |
-----------------------------------------------------

第 2 層は 5 大センターで、フロントエンドアプリケーションがライフサイクルの異なる段階での生産活動を承载します。主要クラスは以下の通り：

プロジェクトセンター：プロジェクト、イテレーションおよびその関連リソースクラス（需要ドキュメント、設計稿、データプロトコル）
研發センター：スキャフォールディング、物料プール、IDE、構築ツール、デバッガー、テストスイートなどのクラス
发布センター：デプロイサービスクラス
監視センター：アプリケーションデータレポート、アラームサービスクラス
運営センター：ユーザーデータレポート、設定バックエンドクラス

その中で、ソースコード編集を中心とした研發ワークベンチが趨勢になっています。フロントエンドワークフローに関連するツール、プラットフォームと [カスタマイズ端 IDE/ 雲 IDE](/articles/定制化 ide のコア価値/#articleHeader8) が提供する開発環境が十分に融合し、集中してプロセス間の接続の体験問題を解決します

另一方面、伝統的なフロントエンド研發モードも変革を起こしています。例えば：

ツール化/自動化設計還元：デザイナーが直接使用可能なフロントエンドコードを産出し、設計稿を出力しなくなり、視覚効果を確認する低効率の交互を減少
標準コンポーネントに基づくローコード開発モード：中間産物を規範化し、全套開発ツール（スキャフォールディング、IDE、構築ツールなど）から離脱してもフロントエンドアプリケーションを産出でき、同様にいくつかのオブジェクト間の交互を減少し、効率が向上

フロントエンドエンジニアリングシステム全体はより快捷にフロントエンドアプリケーションをデリバリーするためです。この角度から見ると、研發モード上のこれらの変革も順理成章です

三.抽象、カプセル化、継承と多態

抽象

抽象の目的は**柔軟性と通用性（変化に抵抗）**を増加することです。フロントエンドエンジニアリング中には 3 種類の一般的な抽象があります：

多くの同類客体オブジェクトから通用モデルを抽象：跨容器フレームワーク（例えば Rax）、跨エンジンインターフェース（例えば React Native JSI）、標準容器
中間産物から標準プロトコルを抽象：跨端コンポーネント、通用 API
オブジェクト交互活動から規範フローを抽象：研發モード、技術方案（例えば [Lottie](/articles/lottie アニメーション简介/)）

その中で、抽象層の作用は 2 種類に分かれます：

変化する部分を囲い込む：抽象層以下は柔軟に変化でき、抽象層以上はこれらの変化に対して感知がありません
不変の部分を固化する：フローは固定不変ですが、フロー中のいくつかの环节は置換可能です。テンプレートメソッドパターンのように

カプセル化

カプセル化の目的は情報隠蔽です。カウンター窓口のように、後厨と前庁を隔て、実装者と使用者を区別するために使用

フロントエンドエンジニアリング中は注目点でプラットフォーム維持者とユーザーを区分します。例えば：

IDE：フロントエンド開発に関連する整套ツール環境のカプセル化で、スキャフォールディング、エディタ、デバッガー、依存管理ツール、構築ツールなどを含みます
構築ツール：ローカル開発、テスト/ 正式デプロイなどの环节に必要なリソース処理ステップのカプセル化で、ソースコードコンパイル、リソース最適化、ソースコード/ 産物静的検査などのステップを含みます
发布サービス：正式、テスト環境下のデプロイ、グレーデ发布、ロールバックなどの機能のカプセル化で、テストエンジニア、プロダクトマネージャーが専門の運用知識がなくてもフロントエンドアプリケーションのデプロイと发布を完了できるようにします

カプセル化は効果的にトップ層オブジェクト数量を減少でき、内部の依存を隠蔽します。主体オブジェクトが注目するオブジェクトがより少なくなり、内部具体交互詳細を了解しなくても簡単にいくつかの複雑な作業を完了できます

継承

継承の目的は現有オブジェクトの属性または行為の再利用です。フロントエンドエンジニアリング中の一般的な再利用形式は以下の通り：

ツールパッケージ：比較的完全なエンジニアリング能力を CLI/GUI ツールまたは IDE プラグインパッケージにパッケージングし、他のエンジニアリングシステムに統合可能
SDK：エンジニアリング能力中の再利用可能な部分を抽離し、この基礎上での二次開発と拡張を許可

その中で、IDE プラグインパッケージは比較的新しい再利用形式で、カスタマイズ IDE と GUI クライアントのコストがより低く、良い選択の 1 つでもあります

多態

多態の目的は拡張です。フロントエンドエンジニアリングから見ると、多態は以下に体现：

ロール面向の定制：例えばプロダクトマネージャー、フロントエンドエンジニアに対応するシステム主页が異なる
シーン面向の横断拡張：例えばミニプログラム、Web、モバイル端、PC 中后台など、1 つのフロー环节が異なるシーンで各自の実装に対応

そのため、異なる役割が 1 つのシステム中で各自の作業を完了でき、同様の研發モードが異なるタイプのフロントエンドアプリケーションを産出できます

四.まとめ

オブジェクト指向の角度から見ると、フロントエンドエンジニアリングはオブジェクトとオブジェクト間の関係および交互行為です：

いくつかの人々が、いくつかの交互を通じて、いくつかの中間産物を生成し、最終的にフロントエンドアプリケーションをデリバリー

オブジェクトの数量は直接体験に関係し、オブジェクト間依存関係の複雑さは効率を決定します。そのため、主体オブジェクトが注目するトップ層オブジェクト数量を減少するか、オブジェクト間の依存関係を簡素化します