Frontend Engineering System from an Object-Oriented Perspective

Preface

From a Process-Oriented Perspective on Frontend Engineering, it is about various processes, and the connections between processes:

(Frontend Engineering from a Process-Oriented Perspective) = Processes + Connections between Processes

Among them, processes aim to solve efficiency problems, while connections between processes focus more on experience problems, all engineering facilities related to frontend workflow can be divided according to this standard, either processes or connections

Conversely from a problem perspective, experience problems can be alleviated through connections, such as connecting upstream and downstream tools/platforms, writing batch processing tools, building management platforms, efficiency problems must be solved through better, faster processes, such as collaboration model upgrades, build speed optimization

But process-oriented division also has some problems, for example:

Some similar processes span multiple production stages: packaging tools span development, build stages, debugging kits span development, testing stages, iteration management spans the entire process
Processes need a lot of connections: some tools need to be used together, such as scaffolding and public libraries, editors and build tools, debugging kits
Process boundaries are unclear, lacking hierarchical structure: easy to produce a bunch of scattered tools/platforms, such as performance log export tools, performance analysis diagnostic tools, performance monitoring platforms, performance data visualization platforms

Since this is the case, might as well change perspective to observe, from an object-oriented perspective

I. OO Concepts in Frontend Engineering

Objects

Objects are abstractions of various entities in frontend application production activities, where some objects are subjects (such as people playing different roles), others are objects (such as tools, platforms and other concrete things)

Objects complete the development and delivery of frontend applications through a series of interaction behaviors:

Product Manager: Discover user needs from problems in real life, and convert user needs into product requirements
Designer: Design UI effects and interaction operation processes according to product requirements, output in the form of design drafts
Backend Engineer: Design data models according to product requirements, implement data reading and writing, agree on frontend-backend data protocols
Frontend Engineer: Restore design drafts according to product requirements, and implement interaction functions according to frontend-backend data protocols, produce frontend applications
Test Engineer: Fully test frontend applications to ensure product requirements are consistently met
Operations Engineer: Deploy quality-reliable frontend applications to production environment
Operations Specialist: Promote launched frontend applications to users

Different from process-oriented perspective, here more care is about interaction behaviors between objects and objects, taking frontend development work as an example:

Process-Oriented Perspective: Now in development stage, I need to complete development tasks through module splitting, coding, debugging and other steps, then project enters next stage
Object-Oriented Perspective: I am a frontend engineer, I need product requirements, design drafts and data protocols provided by product managers, designers, backend engineers, produce frontend applications to test engineers

That is to say:

(Frontend Engineering from an Object-Oriented Perspective) = Objects + Relationships and Interactions between Objects

Among them, number of objects relates to experience, the more objects, the more things subjects need to pay attention to, the worse the experience, complexity of object dependency relationships determines efficiency, the more complex object relationships, the more interactions, the more cumbersome, the lower the efficiency

Interfaces

Interfaces are some abstract products in frontend application production process, not directly reflected in final deliverables, such as:

Protocols/Agreements
Specifications

These abstract products define message formats for communication between objects, allowing people and people, tools and tools, tools and people to collaborate closely

Abstract Classes

Abstract classes are also some abstract products in frontend application production process, defining associations and interaction methods between different objects, such as:

R&D Models
Technical Solutions
Process Standards
Tool Chains

Different from interfaces, these "abstract classes" can constrain linkage relationships between multiple objects, while interfaces constrain one interaction behavior between two objects

II. Object-Oriented Frontend Engineering Design

Examining Frontend Production Activities

First climb the perspective to a high enough place above the clouds, then look at frontend production activities:

Real Problems (User Needs) -> Frontend Production Activities -> (Solutions) Frontend Applications

P.S. Frontend production activities refer to the entire lifecycle of frontend projects from requirements to release

That is, solving real problems through frontend applications, the intermediate production activities are the areas frontend engineering focuses on

If frontend engineering is viewed as a system, its operating principle is roughly like this:

Some people, through some interactions, generate some intermediate products, finally deliver frontend applications

Input user needs, output frontend applications, the problems frontend engineering has always needed to solve are nothing more than two:

Efficiency: Reduce some people, reduce some interactions, standardize some intermediate products
Experience: Simplify some interactions, reduce some intermediate products

P.S. Of course, quality is a prerequisite, just like P in CAP, really no choice. So efficiency, experience improvements that hurt quality are not within discussion scope

Modeling Frontend Engineering

First, identify all subject objects in the system:

Project Manager
Product Manager
Designer
Frontend Engineer
Backend Engineer
Test Engineer
Operations Engineer
Operations Specialist

Then the top layer should be frontend production platform, defining R&D models and process standards, allowing these roles to collaborate:

-----------------------------------------------------
|                Frontend Production Platform         |
-----------------------------------------------------
| Project Center | R&D Center | Release Center | Monitoring Center | Operations Center |
-----------------------------------------------------

The second layer is 5 major centers, carrying production activities of frontend applications at different stages of lifecycle, key classes are as follows:

Project Center: Projects, iterations and their related resource classes (requirement documents, design drafts, data protocols)
R&D Center: Scaffolding, material pools, IDE, build tools, debuggers, test suites and other classes
Release Center: Deployment service classes
Monitoring Center: Application data reports, alarm service classes
Operations Center: User data reports, configuration backend classes

Among them, R&D workbench centered on source code editing has become a trend, tools, platforms related to frontend workflow fully integrate with development environments provided by [customized end IDE/cloud IDE](/articles/定制化 ide 的核心价值/#articleHeader8), centrally solving experience problems of connections between processes

On the other hand, traditional frontend R&D models are also undergoing changes, for example:

Tool化/Automated Design Restoration: Designers directly produce usable frontend code, no longer output design drafts, reducing inefficient interactions of repeatedly confirming visual effects
Low-code development model based on standard components: Standardizing intermediate products, can produce frontend applications even without full set of development tools (scaffolding, IDE, build tools, etc.), similarly reducing some interactions between objects, efficiency improved

The entire frontend engineering system is all for delivering frontend applications more quickly, from this perspective, these changes in R&D models are also natural

III. Abstraction, Encapsulation, Inheritance and Polymorphism

Abstraction

The purpose of abstraction is to increase flexibility and generality (resist changes), there are 3 common abstractions in frontend engineering:

Abstract general models from many similar object objects: cross-container frameworks (such as Rax), cross-engine interfaces (such as React Native JSI), standard containers
Abstract standard protocols from intermediate products: cross-end components, general APIs
Abstract standard processes from object interaction activities: R&D models, technical solutions (such as [Lottie](/articles/lottie 动画简介/))

Among them, the role of abstraction layers is divided into two types:

Circle the changing parts: Below abstraction layer can change flexibly, above abstraction layer has no perception of these changes
Solidify the unchanging parts: Processes fixed unchanged, but some links in the process can be replaced, just like Template Method Pattern

Encapsulation

The purpose of encapsulation is information hiding, just like a counter window, separating kitchen from front hall, used to distinguish implementers and users

In frontend engineering, divided by focus points are platform maintainers and users, for example:

IDE: Is encapsulation of complete set of tool environments related to frontend development, including scaffolding, editors, debuggers, dependency management tools, build tools, etc.
Build Tools: Is encapsulation of resource processing steps needed for local development, test/formal deployment and other stages, including source code compilation, resource optimization, source code/product static checks and other steps
Release Services: Is encapsulation of deployment, gray release, rollback and other functions under formal, test environments, letting test engineers, product managers complete deployment and release of frontend applications without professional operations knowledge

Encapsulation can effectively reduce number of top-level objects, hide internal dependencies, subject objects need to pay attention to fewer objects, can easily complete some complex work without understanding internal specific interaction details

Inheritance

The purpose of inheritance is reuse existing object attributes or behaviors, common reuse forms in frontend engineering are:

Toolkits: Pack relatively complete engineering capabilities into CLI/GUI tools or IDE plugin packages, can be integrated into other engineering systems
SDK: Extract reusable parts from engineering capabilities, allow secondary development and extension on this basis

Among them, IDE plugin packages are a relatively new reuse form, lower cost than custom IDE and GUI clients, also a good choice

Polymorphism

The purpose of polymorphism is extension, from frontend engineering perspective, polymorphism is reflected in:

Role-oriented customization: Such as different system homepages for product managers, frontend engineers
Scenario-oriented horizontal expansion: Such as mini-programs, Web, mobile, PC middle后台 etc., one process link corresponds to respective implementations in different scenarios

Therefore, different roles can complete their respective work in one system, same R&D models can produce different types of frontend applications

IV. Summary

From an object-oriented perspective, frontend engineering is the relationships and interaction behaviors between objects:

Some people, through some interactions, generate some intermediate products, finally deliver frontend applications

Number of objects directly relates to experience, complexity of dependency relationships between objects determines efficiency. Therefore, either reduce number of top-level objects subject objects need to pay attention to, or simplify dependency relationships between objects