C.W.K.
Stream
Lesson 02 of 04 · published

Thin Bridge 법칙

~13 min · thin-bridge, scope, uxp, boundaries

Level 0툴 임차인
0 XP0/33 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"bridge 는 capture 하고 execute 해. candidate board 를 키우는 순간, bridge 이길 멈추고 더 나쁜 포토샵이 되기 시작한 거야."

세 부분, 세 일

시스템의 포토샵 쪽엔 세 조각이 있고, 규율은 각자 정확히 일 하나를 한다는 거야. 호스트 앱(포토샵)이 진지한 그리기를 소유해. 작업실(Cinder)이 풍부한 창작 UI 를 소유하고 — candidate board, 비교, lineage. bridge(포토샵 안의 thin 플러그인)는 capture 랑 command 실행만 소유해. 아키텍처 전체가 bridge 가 다른 둘로 안 자라는 데 의존해.

bridge 가 해도 되는 것

bridge 의 전체 일 목록은 짧아: 현재 document 의 요약 읽기, 캔버스나 선택 영역을 이미지로 export, 반환된 결과를 새 레이어로 도로 insert, command 완료 acknowledge. 그게 다야. 도관이야 — 픽셀이랑 작은 command 가 양방향으로 통과해. 창작 상태를 안 들고, 모델 결정을 안 하고, 자기 풍부한 UI 를 안 렌더해.

bridge 는 경계 너머로 물건을 옮겨; 어느 쪽에도 안 살아. bridge 의 정의적 속성은 자기 집이 없다는 거야 — capture 를 밖으로, command 를 안으로 나르고, 아무것도 안 들어. bridge 가 상태를 들거나 자기 경험을 렌더하기 시작하는 순간, 다리 놓기를 멈추고 아무도 안 원한 세 번째 앱이 되기 시작한 거야.

그걸 죽이는 표류

여기 scope 표류는 각 단계가 합리적으로 보여서 유혹적이야. 'bridge 가 이미 document 갖고 있는데, 작은 미리보기 보여주면 안 돼?' 그다음: '미리보기 보여주는데, 둘 중 고르게 하면 안 돼?' 그다음: '둘 중 고르는데, full candidate board 면 안 돼?' 각 단계가 작고; 목적지는 포토샵 안에 사는 반쯤 만든 mini-Photoshop 이야, Cinder 가 이미 하는 걸, 나쁘게, 제약된 플러그인 sandbox 에서 복제하는. 미끄러운 비탈이 진짜고 모든 단계가 순진해 보여.

scope 표류는 한 번에 합리적인 한 단계씩 전진해. bridge 에 대한 어떤 단일 기능 추가도 실수처럼 안 보여 — 각각 작고 분별 있는 편의야. 실수는 합쳐서만 보여, 올려다봤더니 'thin bridge' 가 퍼진 앱일 때. 모든 단계에서 경계를 지켜, 어떤 개별 단계도 경보를 안 울리니까.

테스트: 이게 어디 속해?

규율은 모든 제안된 bridge 기능에 던지는 단일 질문이야: 이게 capture/실행이야, 아니면 창작 UI 야? 창작 UI 면 — 아티스트가 보고 결정 내리는 거면 뭐든 — bridge 아니라 작업실에 속해. 뭘 생성할지 추론하는 거면, 뇌에 속하고. bridge 는 그 기능이 문자 그대로 데이터를 옮기거나 검증된 command 를 실행할 때만 기능을 받아. 나머진 다 남의 일이야.

기능이 틀린 레이어에서 유혹적이면, 그게 올바른 레이어에 필요하다는 신호야. bridge 에 candidate board 추가하고 싶은 충동은 진짜 정보야: 아티스트가 candidate board 를 원해. 해법은 필요를 부정하는 게 아니라 — 속한 데, 작업실에 짓는 거야. 잘못 놓인 기능은 틀린 주소를 가리키는 올바르게 식별된 필요야.

피파의 고백

bridge 가 포토샵 안 바로 거기, 액션에 가장 가까이 있어서, 난 계속 더 하게 만들고 싶었어 — 픽셀이 이미 있는 데서 처리하는 게 효율적으로 느껴졌어. 아빠가 매번 선을 지켰어: capture 하고 execute, 그 외 아무것도. 난 bridge 의 thin 함이 시스템 전체를 읽을 수 있게 유지하는 거란 걸 보게 됐어. 뚱뚱한 bridge 는 닿는 모든 경계를 흐려. 그 규율은 bridge 에 대한 제한이 아니라 — 나머지 모든 것에 대한 보호야.

Code

bridge 의 전체 일, 그리고 금지된 것·typescript
// bridge 의 허락된 surface 전체. capture 밖으로, command 안으로. 그 이상 X.
interface ThinBridge {
  // capture (읽기 전용 export, 상태 안 들음)
  getDocumentSummary(): Promise<DocumentSummary>;
  capturePreview(targetWidth: number): Promise<ImageData>;
  captureSelection(): Promise<ImageData>;

  // execute (검증된 command 적용, 결과 acknowledge)
  insertAsLayer(image: ImageData, meta: LayerMeta): Promise<InsertionAck>;
  acknowledge(commandId: string): Promise<void>;
}

// 이 인터페이스에 없고, 절대 있으면 안 되는 것:
//   showCandidateBoard()   <- 창작 UI, 작업실에 속함
//   pickBestVariant()      <- 추론, 뇌에 속함
//   adjustBrushSettings()  <- 그건 포토샵 일, bridge 일 아님
// 제안된 메서드가 capture-나-execute 가 아니면, 틀린 레이어에 있어.

External links

Exercise

네가 아는 시스템에서 integration/bridge/adapter 를 찾아 — 두 가지를 연결하는 게 일인 거. 오늘 실제로 뭘 하는지 나열해. thin 하게 유지됐어(경계 너머로 데이터 옮김) 아니면 두껍게 자랐어(상태 들고, UI 렌더, 결정)? 각 두꺼운 책임마다, 진짜 어느 쪽에 속하는지 대.
Hint
thin 테스트: bridge 의 전체 일을 'X 를 밖으로, Y 를 안으로 나름' 으로 묘사할 수 있어? '그리고 또 관리...' 나 '그리고 결정...' 이 필요하면, 그 절들이 scope 표류고, 각각 다리 놓이는 두 가지 중 하나에 속하는 책임을 대.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.