맞춤형 IDE 선정 노트

零.왜 커스터마이징하는가?

IDE 와 같은 거대한 블랙박스의 일각을 들춰내어, 심층 커스터마이징을 꾀하는 것은, 그것은 정말 어리석어 보입니다. 플러그인을 작성하는 것만으로는 안 되는 것일까요? 이렇게 하는 주된 이유는 2 가지 있습니다:

더 높은 유연성: 확장 메커니즘의 제한을 받지 않아, 기존 기능의 커스터마이징이든 신기능의 확장이든 실현 가능합니다
더 세밀한 제어 입도: 심층의 이차 개발로 세부 사항까지 완전히 제어 가능하여, 세 입도의 커스터마이징 니즈를 충족시킬 수 있습니다

실제로, 유연성 수익의 많고 적음은 확장 메커니즘의 제한 정도에 의존합니다. 플러그인 메커니즘이 완전히 개방되어 있다면, 이차 개발로 인한 유연성 향상은 그다지 필요하지 않습니다. 예를 들어 Atom 의 확장 메커니즘은 거의 제한이 없어, 플러그인 메커니즘만으로 완전히 새로운 IDE 를 작성할 수 있습니다. 예를 들어 Nuclide

제어 입도는 커스터마이징 능력에 중점을 두고, 예를 들어 테마 스타일, UI 레이아웃, 구문 확장 등입니다. 이차 개발은 플러그인 메커니즘이 커스터마이징을 허용하지 않는 부분을 지원할 수 있어, 애플리케이션 이름/아이콘에서 UI 레이아웃/인터랙션 조작까지 다양합니다

한편, 니즈 시나리오의 관점에서 보면, 전용 IDE 에는 몇 가지 장점이 있습니다:

원스톱 도구: 통합. 호로소금강의 느낌으로, 다른 7 개의娃의 모든 능력을 가집니다
몰입형 체험: 연결. 툴체인을 유기적으로 조합하여, 스캐폴딩 - 구문 힌트 -Lint 검사 - 구축 - 미리보기 - 디버그 - 패키징의 원스톱 서비스
플랫폼화 건설: 통합. 도구의 세분화, 체계화되지 않은 문제에 대응하여, 툴 체계 건설을 촉진
표준화 개발: 제약. 작성법의 유연성과车间流水线협력은 모순되며, 통일된 개발 환경은 더 강한 제약력을 제공

이것도 ReactNative, Weex, 微信미니프로그램, 支付宝미니프로그램 등의 특수 시나리오가 전용 IDE 를 제공하는 이유입니다. 첫 번째는 개발을 더 편리하게 하고, 체험을 더 좋게 하는 것. 두 번째는 작성법을 어느 정도 표준화하고, 스타일을 통일하는 것입니다

一.예상 특성

이용 가능한 커스터마이징 IDE 는 어떤 능력을 가져야 하는가:

기본 기능: 적어도 주류 프런트엔드 IDE 의 대부분 능력을 가져야 하며, 코딩의 변태 욕망을 충족시킬 수 있어야 합니다
통합 능력: 기존의 상용 도구를 통합할 수 있어야 합니다. 규범 검사, 구축, 미리보기, 디버그, API 문서 등을 포함합니다
확장성: 한편으로는 개방적인 플러그인 생태 지원이 있고, 다른 한편으로는 장래의 새로운 도구를 차분히 통합할 수 있어야 합니다

그 중에서, 각 능력의 지위는 각각:

공간/발전 확장성
-------
종자/성장 통합 능력
-------
물/생존 기본 기능

통합 능력과 기본 기능은 모두 없어서는 안 되며, 확장성은 상상 공간입니다. 종자가 없으면 모두 공론이고, 물이 없으면 신속하게 생명력을 잃습니다. 종자와 물이 있으면, 풀이 될지 나무가 될지는 공간에 달렸습니다. 발아 후, 물은 지속적으로 공급해야 하므로, 기본 기능이야말로 생존의 근본입니다 (코딩이 불쾌하면, 아무리 편리해도 사용하지 않습니다)

게다가, 기본 기능에는 특수성이 있습니다. 프런트엔드 IDE 의 선택은 항상 취향 문제입니다. IntelliJ IDEA/WebStorm 과 같은 중후한 것부터, Sublime Text/VS Code 와 같은 경량인 것, NotePad/Vim 과 같은 고속인 것까지, 1 개의 캔디로 이 중구난조의 문제를 해결하는 것은 거의 불가능합니다. 따라서, 오픈소스 IDE 를 기반으로 이차 개발하는 것이 유일한 선택처럼 보입니다. 고가용한 IDE Core 가 대부분의 IDE 기본 기능을 포함한다면 유감스럽게도,暫時 그러한 것은 존재하지 않습니다 (Monaco 는 비교적 가깝지만, 확장성 등의 중요한 것이 아직 부족합니다)

二.성숙 사례

커스터마이징 IDE 는 갑자기 많이 나타난 것 같습니다. 예를 들어:

대응 선정 방안은 다음과 같습니다:

명칭	크로스 플랫폼	기본 기능	구현 방안
微信개발자 도구	NWjs	monaco-editor	NWjs 手搓、IDE Core 는 Monaco 사용
支付宝미니프로그램 개발 도구	Electron	vscode editor	Electron 手搓、IDE Core 는 VS Code editor 부분을 剝가서 사용
React Native IDE	Electron	Atom	Atom 플러그인合集、IDE Core 는 Atom 사용

처음에 微信개발자 도구로 일을搞했습니다 (上不了線的小程序 참조).あのコーディング時に 손발이 묶이는ような感觉은 매우 불쾌했습니다 (어째서 xx 기능조차 없는가). 이는 위에서 서술한 물의 문제입니다 (물론, 선택의 여지가 없었으므로, 그들은 물의 문제를 고려할 필요가 없었습니다). 이만큼의 이터레이션을 거쳐, 코드 편집, 파일 관리 등의 면에서 상당히 개선된 것 같습니다. 다시 심층 체험은 하지 않았습니다

支付宝미니프로그램도 아마 물의 문제를 고려했기 때문에, VS Code 에서 editor 를 剝가는 방안을 선택했습니다. 아마 한 고생했을 것입니다

RN IDE 는 더 난폭해서, Atom package(플러그인) 를 많이 가져와서, Flow 에 강 의존하는 IDE 를 쌓아올렸습니다. 게다가 이렇게 주장합니다:

A unified developer experience for software development

실제 상황은, 프로젝트가 Flow 를 사용하지 않는 경우, 정의로의 점프조차 지원되지 않습니다

三.선택 가능 방안

실행 가능 방안은 2 종류뿐입니다:

手搓:IDE Core 를 찾아서 통합
이차 개발:IDE 를 찾아서 확장 강화

기술적으로 선택이 필요한 3 가지 중요한 포인트:

크로스 플랫폼 방안:NWjs 또는 Electron
IDE Core:Monaco 또는 기타
오픈소스 IDE:VS Code 또는 Atom 또는 기타

오픈소스 IDE 를 기반으로 이차 개발하는 경우, 어떤 IDE 를 사용할지만关心하면 됩니다. 手搓 방안의 경우, 크로스 플랫폼 방안과 IDE Core 를 선택해야 합니다

NWjs vs. Electron

배경

NWjs

Intel 上海오픈소스 기술 센터에서 孵化한 프로젝트 (처음에는 node-webkit 이라고 불렸습니다). Node 환경에서 Webkit 브라우저窗體를 생성할 수 있습니다. 후에 Webkit 에서 Chromium 으로 전환하고, Nodejs + Chromium 으로 데스크톱 애플리케이션을 개발하는 발전 방향을 명확히 했습니다
Electron

Github 가 Atom 개발 시 채택하여 오픈소스화한 기술.NWjs 와 몇 가지 联系가 있지만, 구현상으로는 크게 다릅니다 (프로세스 모델, Chromium 통합 방식 등)

차이

공통점:

프런트엔드 기술 스택으로 데스크톱 애플리케이션을 개발. 모두 성숙 사례가 있습니다. 예를 들어 釘釘(NWjs), VS Code(Electron)
기술 구현은 모두 Nodejs + Chromium

차이와 제한:

플랫폼 서포트:Electron 은 XP 와 Vista 를 서포트하지 않고, NWjs 는 서포트
프로세스 모델:NWjs 는 단일 프로세스 모델로, 힙 메모리를 공유.Electron 은 멀티 프로세스 모델로, 파이프 IPC 통신에 의존
소스 코드 보호:NWjs 는 소스 코드 보호를 서포트 (소스 코드를 V8 스냅샷으로 컴파일). Electron 은 서포트하지 않음
자동 업데이트:Electron 은 내장 서포트.NWjs 는 커뮤니티 모듈 서포트
개발 체험:Electron 의 문서는 NWjs 보다 우수합니다. 인기도에서는 Electron 55.6k star; NWjs 33.1k star

그 중에서, 비교적 중요한 것은플랫폼 서포트와 소스 코드 보호의 차이입니다

응용 시나리오

NWjs 를 선택하는 이유:

플랫폼이 XP 또는 Vista 를 서포트해야 함
단일 프로세스 모델의 데이터 공유의便捷함을 중시. 멀티窗體에서 상태 공유가 더 용이
同構方面의 이점.NWjs 커스터마이징 부분은 Electron 보다 적어, 더 많은 同構코드를 재사용 가능 (1 개의 코드를 유지하고, 데스크톱과 Web 환경에서 실행)
소스 코드 보호를 매우気に하는 시나리오. 예를 들어 게임 내 구매

Electron 을 선택하는 이유:

「순」클라이언트 애플리케이션.web 환경에 대한 서포트 계획 없음
멀티 프로세스 모델의 안전성을 중시. 프로세스 격리
커뮤니티 活跃度가 더 높고, 개발 비용이 더 낮음

Monaco

오픈소스이고,かつ고가용한 IDE Core는 Monaco 뿐인 것 같지만, 극복 곤란한 문제가 몇 가지 존재합니다:

TSX 서포트 정도는 일반적.JSX 구문 하이라이트를 서포트하지 않음
성숙한 플러그인 생태가 없고, VS Code 플러그인을 저비용으로 이전할 수 없음

JSX 구문 하이라이트의 서포트는 얼마나 어려운가?

Does monaco support JSX ? 를 참조할 수 있습니다. 16 년 말의 문제로, 현재 (18 년 3 월) 도 open 상태입니다.底层正則엔진의 제한으로 인한 것으로, .tmLanguage 에서 저비용으로 이전할 수 없습니다. 상세는 Colorization Clarification 참조

P.S.그렇다면 TSX 는 어떻게 서포트되는가. 모두 같지 않은가? TypeScript 도 MS自社メンテナンス이므로, 서포트하지 않는다고 할 수 없고, 충분한 이유가 없으면, 아무도 거량의 正則변환 작업을 수행하지 않습니다

확장 메커니즘에서 중요한 것은 생태입니다. 자원이 제한되어 있으므로, 오픈소스를「옹호」해야 합니다. Monaco 는 바로 이것이 부족합니다. Integrate VS Code extensions in the Monaco editor 참조

P.S.幸好微信미니프로그램은全新的인 것을 만들어내지 않았습니다 (XML, CSS, JS 만).否则 IDE 팀은 거대한 작업량에 직면할 것입니다

VS Code vs. Atom

오��소스 IDE	기술 구현	유지보수자	인기도	플러그인 생태
Atom	Electron	Github	43K star	플러그인은 많지만, 활발하지 않음
VS Code	Electron	Microsoft	42.6K star	플러그인은 많고,かつ활발
Brackets	Chrome Embedded Framework(Chromium 위의 커스터마이징 방안)	Adobe	28.6K star	플러그인은 많고,かつ활발

위의 대비만 보면, VS Code 가 가장 우세합니다. 그러나, 왜 RN 은 VS Code 가 아닌 Atom 을 기반으로 확장했을까요?

VS Code 는 확장 능력의 제한이 매우 크기 때문입니다. 예를 들어:

UI 커스터마이징의 자유도가 매우 낮아, 눈에 띄지 않는 위치에 아이콘 또는 옵션을 추가하는 것뿐
플러그인 프로세스 격리. 플러그인은 독립된 프로세스 환경에서 실행되며, 주입된 확장 API 외에는 IDE 주체에 전혀 손댈 수 없습니다. API 가 없으면 아무것도 할 수 없음을 의미합니다

Atom 은 정반대로, 프로세스 격리가 없고, 심층 UI 커스터마이징을 허용하며, 플러그인 API 는 비교적 底層的이고, VS Code 와 같이 고도로 캡슐화된 것만 제공하는 것과는 다릅니다. 확장 비용의 관점에서 보면, Atom 은 상당 우세합니다

P.S.Atom 이刚推出되었을 때, 퍼포먼스는 사람으로부터 비난받아, 그다지 좋지 않은 인상을 남겼지만, 일상 사용에서는 충분하고, 그다지 느리지 않습니다

四.결단

결정 나무는 다음과 같습니다:

[caption id="attachment_1678" align="alignnone" width="625"] 맞춤형 IDE 방안 결정 나무[/caption]

5 종류의 실행 가능 방안의优缺点 대비는 다음과 같습니다:

방안	简述	단점	장점
A) VS Code 를 기반으로 이차 개발	VS Code 플러그인 개발 + 가능한 한 작은 소스 코드 수정	UI 커스터마이징 비용이 높음 플러그인 능력이 엄격히 제한 UI 커스터마이징형 플러그인이 매우 적음	플러그인 시장 活跃度가 높음 코드 편집 체험이 좋음 기동 퍼포먼스가 높고, 플러그인은按需로드 확장이 용이.Vue 또는 업데이트된 프런트엔드 생태 산물 서포트 등
B) Atom 을 기반으로 이차 개발	Atom 플러그인 개발 + 가능한 한 작은 소스 코드 수정	코어 API 가 박약 플러그인 능력은 제한되지 않지만, 품질 보증이 없음 플러그인 시장 活跃度가 낮고, 후기 유지보수 비용이 큼 코드 편집 체험이 다소 떨어짐	UI 커스터마이징이 용이 플러그인 능력이 제한되지 않음 UI 커스터마이징형 플러그인이 많고, 전기 개발이 빠름 확장이 용이.Vue 또는 업데이트된 프런트엔드 생태 산물 서포트 등
C) RN IDE 를 수정	순 Atom 플러그인 개발	TypeScript, Flow 에 강 의존 JSX 서포트도가 높지 않고, 강화 비용이 낮음 기동 퍼포먼스가 다소 떨어짐	응용 시나리오가 유사하고, 구현 상세도借鉴 가능. 기술 리스크 없음 기성의 UI/ 인터랙션.专门 투입 불필요
D) Monaco + N	VS Code IDE core + Electron 개발	수동 구현. 안정 정도 보증 없음 JSX 를 서포트하지 않고, 강화 비용이 매우 높음 TSX 서포트 정도가 높지 않고, 강화 비용이 매우 높음	탈 중심. 유연성이 높음 개발 비용은 ABC 보다 높음
E) alm + N	VS Code IDE core 강화 + Electron 개발	수동 구현. 안정 정도 보증 없음 JSX 서포트 정도가 높지 않고, 강화 비용이 매우 높음	탈 중심. 유연성이 높음 개발 비용은 ABC 보다 높고, D 보다 낮음

종합적으로 보면, 정말 실행 가능한 것은 A 와 B 뿐입니다.進一步의 선택은작업량과 이용 가능 자원을 고려해야 합니다:

排程/중요한 시간 노드:프로젝트 시간跨度, 및 Alpha, Beta 시간점
인력/전투력:몇 명 참가, 병행 가능한가, 및 전투력이达标했는가
기술 스택 숙련 정도:착수 후 정상한 진도를 보증할 수 있는가
실제 작업량:작업량이 溢出했는가

1 인월만이라고 가정하면, B 를 선택. 리스크는 거의 없습니다. B 는 대 전기로, 신속하게 물건을 낼 수 있지만, 후기에 酱油를 치는 문제에 직면합니다

2 인월 있으면, A 를 선택可以尝试. 저 리스크.UI 커스터마이징 비용은 불확정 요인으로, 전기 진도에 영향을 미쳐, Alpha 등의靠前의 시간 노드에 압력이 커질 가능성이 있습니다. 그러나, 대 후기에는 절대적인 발전 우세가 있습니다

五.경험

0 에서 1 로

코끼리를 냉장고에 넣으려면 3 단계 필요:

먼저 종자와 물이 각각 무엇인지 명확
다음으로 상상 공간이 있는 좋은 종자 선택
마지막으로 끊임없이 급수

종자와 물은 모두 없어서는 안 되며, 극단 조건 하에서는, 종자 > 물 > 공간

실천에 입각

과정에서 2 가지 실수를 범했습니다:

한 마디 때문에, 임시로 방안을 조정. 결과는 3 일 낭비 + 2 일 재작업
작업 배분이 불합리. 적절한 사람이 적절한 일을 하지 않음. 결과는 2 일 조사 낭비 + 2 일 진도 지체

권위 압력에 직면하여, 이성적 판단력을 흔들어서는 안 됩니다. tell me why. 사실을 나열하고 이치를 설명합니다. 전투력의 판단은此刻의 사실에 기반해야 하고, 과거의 경험에 기반해서는 안 됩니다. 真真切切하게 문제에 직면했을 때만, 真实的인 전투력이 나타납니다

이 한 벌의 것, NB 는 어디에 있는가?

시점 전환

反向推進能力

그들의 컴퓨터에는 아무것도 들어있지 않다

결과 외의 것. 어떤 때는 결과 자체와 마찬가지로 중요합니다