객체 지향 관점에서의 프론트엔드 엔지니어링 시스템

서두

프로세스 지향의角度来看 프론트엔드 엔지니어링 을 보면, 각 프로세스, 그리고 프로세스 간의 연결입니다:

(프로세스 지향 관점에서의) 프론트엔드 엔지니어링 = 프로세스 + 프로세스 간의 연결

그 중에서, 프로세스는 효율 문제 해결을 목적으로 하며, 프로세스 간 연결은 더 많이 체험 문제에 주목합니다. 프론트엔드 워크플로우와 관련된 모든 엔지니어링 시설은 이 기준으로 나눌 수 있으며, 프로세스이거나 연결입니다

반대로 문제의角度来看, 체험 문제는 연결을 통해 완화할 수 있습니다. 예를 들어 상류 하류 도구/플랫폼 연결, 배치 처리 도구 작성, 관리 플랫폼 구축 등. 효율 문제는 더 우수하고 더 빠른 프로세스를 통해 해결해야 합니다. 예를 들어 협력 모델 업그레이드, 구축 속도 최적화 등

그러나 프로세스 지향 분류에도 몇 가지 문제가 존재합니다. 예를 들어:

몇 가지 유사한 프로세스가 여러 생산环节에 걸쳐 있습니다: 패키징 도구는 개발, 구축 단계에 걸쳐, 디버깅 스위트는 개발, 테스트 단계에 걸쳐, 이터레이션 관리는 전 프로세스에 걸쳐 있습니다
프로세스 간에 대량의 연결이 필요합니다: 몇 가지 도구는配合하여 사용해야 합니다. 예를 들어 스캐폴딩과 공공 라이브러리, 에디터와 구축 도구, 디버깅 스위트 등
프로세스 경계가 불명확하고, 계층 구조가 부족합니다: 쉽게一堆의零散한 도구/플랫폼이 생깁니다. 예를 들어 성능 로그导出 도구, 성능 분석 진단 도구, 성능 모니터링 플랫폼, 성능 데이터 가시화 플랫폼 등

既然如此, 관점을 바꿔 관찰해 봅시다. 객체 지향의角度来看

일.프론트엔드 엔지니어링 중의 OO 개념

객체

객체는, 프론트엔드 애플리케이션 생산 활동 중의 각 실체의 추상입니다. 그 중에서 몇 가지 객체는 주체 (예를 들어 다른 역할을 담당하는 사람) 이고, 다른 것은 객체 (예를 들어 도구, 플랫폼 등 각종 구체적 사물) 입니다

객체 간은 일련의 상호작용 행위를 통해 프론트엔드 애플리케이션의 개발과 전달을 완료합니다:

프로덕트 매니저: 현실 생활 속의 문제에서 사용자 요구를 발견하고, 사용자 요구를 프로덕트 요구로 전환
디자이너: 프로덕트 요구에 따라 UI 효과와 상호작용 작업 흐름을 설계하고, 설계도 형식으로 출력
백엔드 엔지니어: 프로덕트 요구에 따라 데이터 모델을 설계하고, 데이터 읽기 쓰기를 구현하며, 전후단 데이터 프로토콜을 약정
프론트엔드 엔지니어: 프로덕트 요구에 따라 설계도를 복원하고, 전후단 데이터 프로토콜에 따라 상호작용 기능을 구현하여, 프론트엔드 애플리케이션을 산출
테스트 엔지니어: 프론트엔드 애플리케이션을 충분히 테스트하여, 프로덕트 요구가 일관되게 만족됨을 보증
운영 엔지니어: 품질이 신뢰할 수 있는 프론트엔드 애플리케이션을 생산 환경에 배포
운영专员: 이미 온라인된 프론트엔드 애플리케이션을 사용자에게推广

프로세스 지향 관점과 달리, 여기서는 더 객체와 객체 간의 상호작용 행위에 관심을 가집니다. 프론트엔드 개발 작업을 예로:

프로세스 지향 관점: 현재 개발 단계에 있으며, 모듈 분할, 코딩, 디버깅 등 단계를 통해 개발 작업을 완료한 후, 프로젝트는 다음 단계로 진입
객체 지향 관점: 나는 프론트엔드 엔지니어로, 프로덕트 매니저, 디자이너, 백엔드 엔지니어가 제공하는 프로덕트 요구, 설계도와 데이터 프로토콜이 필요하며, 프론트엔드 애플리케이션을 산출하여 테스트 엔지니어에게 전달

즉:

(객체 지향 관점에서의) 프론트엔드 엔지니어링 = 객체 + 객체 간의 관계 및 상호작용

그 중에서, 객체의 수는 체험과 관계가 있습니다. 객체 수가 많을수록, 주체가 관심 가져야 할 것이 많아지고, 체험은 나빠집니다. 객체 의존 관계의 복잡도는 효율을 결정합니다. 객체 관계가 복잡할수록, 상호작용이 많고 번거로우며, 효율은 낮아집니다

인터페이스

인터페이스는, 프론트엔드 애플리케이션 생산 과정 중의 몇 가지 추상 산물로, 최종 전달물에 직접 나타나지 않습니다. 예를 들어:

프로토콜/약정
규범

이러한 추상 산물은 객체 간 통신의 메시지 형식을 정의하여, 사람과 사람, 도구와 도구, 도구와 사람이 긴밀히 협력할 수 있게 합니다

추상 클래스

추상 클래스도, 프론트엔드 애플리케이션 생산 과정 중의 몇 가지 추상 산물로, 서로 다른 객체 간의 연관과 상호작용 방식을 정의합니다. 예를 들어:

연구개발 모드
기술 방안
프로세스 표준
도구 체인

인터페이스와 달리, 이러한 "추상 클래스"는 여러 객체 간의 연동 관계를 구속할 수 있습니다. 인터페이스가 구속하는 것은 두 객체 간의 한 번의 상호작용 행위입니다

이.객체 지향의 프론트엔드 엔지니어링 설계

프론트엔드 생산 활동 심의

먼저 관점을 백운 위에 충분히 높은 곳으로 올려, 프론트엔드 생산 활동을 봅니다:

현실 문제 (사용자 요구) -> 프론트엔드 생산 활동 -> (해결책) 프론트엔드 애플리케이션

P.S. 프론트엔드 생산 활동이란, 프론트엔드 프로젝트가 요구에서 배포 온라인까지의 전체 라이프사이클을 가리킵니다

즉, 프론트엔드 애플리케이션을 통해 현실 문제를 해결하며, 중간 생산 활동이 프론트엔드 엔지니어링이 주목하는 영역입니다

프론트엔드 엔지니어링을 하나의 시스템으로 보면, 그 작동 원리는 대략 이렇습니다:

몇몇 사람들이, 몇몇 상호작용을 통해, 몇몇 중간 산물을 생성하고, 최종적으로 프론트엔드 애플리케이션을 전달

사용자 요구를 입력하고, 프론트엔드 애플리케이션을 출력합니다. 프론트엔드 엔지니어링이一直以来 해결해 온 문제는无非 두 가지:

효율: 몇몇 사람들을 감소, 몇몇 상호작용을 감소, 몇몇 중간 산물을 규범화
체험: 몇몇 상호작용을 간소화, 몇몇 중간 산물을 감소

P.S. 물론, 품질은 전제 조건입니다. CAP 중의 P 처럼, 실질적으로 선택의 여지가 없습니다. 따라서 품질을 손상하는 효율, 체험 향상은 논의 범위 내에 없습니다

프론트엔드 엔지니어링 모델링

먼저, 시스템 중의 모든 주체 객체를 식별:

프로젝트 매니저
프로덕트 매니저
디자이너
프론트엔드 엔지니어
백엔드 엔지니어
테스트 엔지니어
운영 엔지니어
운영专员

그렇다면 최상층은 프론트엔드 생산 플랫폼으로, 연구개발 모드와 프로세스 표준을 정의하여, 이러한 역할들이 협력 작업할 수 있게 합니다:

-----------------------------------------------------
|                    프론트엔드 생산 플랫폼                    |
-----------------------------------------------------
| 프로젝트 센터 | 연구개발 센터 | 배포 센터 | 모니터링 센터 | 운영 센터 |
-----------------------------------------------------

제 2 층은 5 대 센터로, 프론트엔드 애플리케이션이 라이프사이클의 서로 다른 단계에서의 생산 활동을 담당합니다. 주요 클래스는 다음과 같습니다:

프로젝트 센터: 프로젝트, 이터레이션 및 그 관련 리소스 클래스 (요구 문서, 설계도, 데이터 프로토콜)
연구개발 센터: 스캐폴딩, 자재 풀, IDE, 구축 도구, 디버거, 테스트 스위트 등 클래스
배포 센터: 배포 서비스 클래스
모니터링 센터: 애플리케이션 데이터报表, 경보 서비스 클래스
운영 센터: 사용자 데이터报表, 설정 백엔드 클래스

그 중에서, 소스 코드 편집을 중심으로 한 연구개발 워크벤치가 추세가 되었습니다. 프론트엔드 워크플로우와 관련된 도구, 플랫폼과 [커스터마이즈 단 IDE/ 클라우드 IDE](/articles/커스터마이즈 ide 의 핵심 가치/#articleHeader8) 가 제공하는 개발 환경이 충분히 융합되어, 집중적으로 프로세스 간 연결의 체험 문제를 해결합니다

다른 한편, 전통적인 프론트엔드 연구개발 모드도 변혁을 일으키고 있습니다. 예를 들어:

도구화/자동화 설계 복원: 디자이너가 직접 사용 가능한 프론트엔드 코드를 산출하고, 더 이상 설계도를 출력하지 않으며, 시각 효과를 반복 확인하는 저효율 상호작용을 감소
표준 컴포넌트 기반의 로우코드 개발 모드: 중간 산물을 규범화하여,全套 개발 도구 (스캐폴딩, IDE, 구축 도구 등) 에서 벗어나도 프론트엔드 애플리케이션을 산출할 수 있으며, 마찬가지로 몇몇 객체 간의 상호작용을 감소하여, 효율이 향상

전체 프론트엔드 엔지니어링 시스템은 더快捷하게 프론트엔드 애플리케이션을 전달하기 위한 것입니다. 이角度来看, 연구개발 모드상의 이러한 변혁도 순리成章입니다

삼.추상, 캡슐화, 상속과 다형

추상

추상의 목적은 **유연성과 범용성 (변화에 저항)**을 증가하는 것입니다. 프론트엔드 엔지니어링 중에는 3 가지 일반적인 추상이 있습니다:

많은 동류 객체 객체에서 범용 모델을 추상:跨容器 프레임워크 (예를 들어 Rax), 跨엔진 인터페이스 (예를 들어 React Native JSI), [표준 容器](/articles/모바일端跨플랫폼 기술 아래의 변과 불변/#articleHeader6)
중간 산물에서 표준 프로토콜을 추상:跨端 컴포넌트, 범용 API
객체 상호작용 활동에서 규범 프로세스를 추상:연구개발 모드, 기술 방안 (예를 들어 [Lottie](/articles/lottie 애니메이션简介/))

그 중에서, 추상층의 작용은 두 가지로 나뉩니다:

변하는 부분을 둘러싸기: 추상층 이하는 유연하게 변할 수 있으며, 추상층 이상은 이러한 변화에 대해 감지가 없습니다
불변하는 부분을 고정: 프로세스는 고정 불변하지만, 프로세스 중의 몇몇环节은 교체 가능합니다. 템플릿 메서드 패턴 처럼

캡슐화

캡슐화의 목적은 정보 은닉입니다. 카운터 창구처럼, 후厨와 전厅을隔开, 구현자와 사용자를 구분하는 데 사용

프론트엔드 엔지니어링 중에는 관심점으로 플랫폼 유지자와 사용자를 구분합니다. 예를 들어:

IDE: 프론트엔드 개발과 관련된整套 도구 환경의 캡슐화로, 스캐폴딩, 에디터, 디버거, 의존 관리 도구, 구축 도구 등을 포함
구축 도구: 로컬 개발, 테스트/정식 배포 등环节所需的 리소스 처리 단계의 캡슐화로, 소스 코드 컴파일, 리소스 최적화, 소스 코드/산물 정적 검사 등 단계를 포함
배포 서비스: 정식, 테스트 환경 하의 배포, 그레이드 배포, 롤백 등 기능의 캡슐화로, 테스트 엔지니어, 프로덕트 매니저가 전문적인 운영 지식이 없어도 프론트엔드 애플리케이션의 배포와 배포를 완료할 수 있게 함

캡슐화는 효과적으로 최상층 객체 수를 감소할 수 있으며, 내부의 의존을 은닉합니다. 주체 객체가 관심 가져야 할 객체가 더 적어지고, 내부 구체적 상호작용 세부사항을 알지 않아도 쉽게 몇몇 복잡한 작업을 완료할 수 있습니다

상속

상속의 목적은 기존 객체의 속성 또는 행위의 재사용입니다. 프론트엔드 엔지니어링 중의 일반적인 재사용 형식은 다음과 같습니다:

도구 패키지: 비교적 완전한 엔지니어링 능력을 CLI/GUI 도구 또는 IDE 플러그인 패키지로 패키징하여, 다른 엔지니어링 시스템에 통합 가능
SDK: 엔지니어링 능력 중 재사용 가능한 부분을 추출하여, 이 기반 위에서 이차 개발과 확장을 허용

그 중에서, IDE 플러그인 패키지는 비교적 새로운 재사용 형식으로, 커스터마이즈 IDE 와 GUI 클라이언트의 비용이 더 낮으며, 좋은 선택의 하나이기도 합니다

다형

다형의 목적은 확장입니다. 프론트엔드 엔지니어링에서 보면, 다형은 다음에 나타납니다:

역할面向의定制: 예를 들어 프로덕트 매니저, 프론트엔드 엔지니어에 대응하는 시스템主页이 다름
장면面向의 횡단 확장: 예를 들어 미니프로그램, Web, 모바일端, PC 중后台 등, 하나의 프로세스环节이 다른 장면에서 각자의 구현에 대응

따라서, 서로 다른 역할이 하나의 시스템 중에서 각자의 작업을 완료할 수 있으며, 같은 연구개발 모드가 서로 다른 유형의 프론트엔드 애플리케이션을 산출할 수 있습니다

사.정리

객체 지향의角度来看, 프론트엔드 엔지니어링은 객체와 객체 간의 관계 및 상호작용 행위입니다:

몇몇 사람들이, 몇몇 상호작용을 통해, 몇몇 중간 산물을 생성하고, 최종적으로 프론트엔드 애플리케이션을 전달

객체의 수는 직접 체험과 관계하며, 객체 간 의존 관계의 복잡도는 효율을 결정합니다. 따라서, 주체 객체가 관심 가져야 할 최상층 객체 수를 감소하거나, 객체 간의 의존 관계를 간소화합니다

서두