From f17070ba88d9219aa03daa0f789dc0220dc3f18e Mon Sep 17 00:00:00 2001 From: Hyewon Lee Date: Sun, 22 Dec 2024 15:14:22 +0900 Subject: [PATCH] Create 20241222.mdx --- data/blog/20241222.mdx | 234 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 234 insertions(+) create mode 100644 data/blog/20241222.mdx diff --git a/data/blog/20241222.mdx b/data/blog/20241222.mdx new file mode 100644 index 0000000..648f19c --- /dev/null +++ b/data/blog/20241222.mdx @@ -0,0 +1,234 @@ +> 어제 Devfest Incheon / Songdo 2024를 다녀와서 인상깊었던 2가지 세션을 개발팀 팀원들과 공유해 봅니다 ☺️ + +# 1. DevRel이 말하는 개발자의 문장력 - 최가인님 + +## 오늘의 목표 + +1. 나한테 어떤 글 습관이 있는지 인지 +2. 최소한의 원칙으로 내일은 오늘의 문장보다 조금 더 나은 문장으로 업그레이드해서 커뮤니케이션 할 수 있다 + +## 우리는 왜 글을 쓰는가 + +- 조지 오웰, <나는 왜 쓰는가> + - 개인의 이기심 + - 미학적 열정 + - 역사적 충동 + - 정치적 목적 + +## 쉽지 않은 커뮤니케이션 + +- Scrum +- Squad : 작은 애자일 팀 +- 역할, 우선순위, 프로세스, 결과물, 가지고 있는 정보 등등… 차이가 존재함 + +- 각 플랫폼에 맞는 글의 형식, 구성, 분량이 존재함 +- 읽는 사람이 부담없고 받아들이기가 쉬워야 함 +- 당근, 노션에서는 노션으로 발표를 진행함 + +### 메일 + +- 드림/**올림** + - 배상 (→ 올림으로 순화해서 사용) + +## 맥락을 품어라 + +- (슬랙, 디스코드) 스레드로 근거를 설명 + +## 본질이 중요하다 + +- **허세를 부리지 말자** + - Charles Derver, <대화 나르시시즘> + - 주도권을 자신에게 돌려놓으려는 욕망 + - 엔지니어에게 주로 보임 + - 본인은 모르는 경우가 많다 + - **자신의 언어에 국한되지 않는, 사용자 중심적인, 엔드 유저에게 전해질 수 있는 표현을 사용해야 한다** + - William Knowlton Zinasser, <공부가 되는 글쓰기> + - 각종 명사와 현학적인 전문용어로 점철된 글 == 자신이 조직 내에서 중요한 존재라는 느낌을 가질 뿐, 아무 뜻도 없는 단어 + - 엔지니어에게 주로 보임2 +- **생존에 필요한 문장** + - 우리에게 필요한 문장은 예술이 아니다 + - **표현법 == 머릿속 생각을 누군가에게 전달할 수 있는 상태로 치환하는 일** + - **무엇을 말할 것인가** + - 호의나 존경심을 느낄 때 + - 독창적인 관점이 있는가 + - 새로운 깨달음을 주는가 + - 나를 진정으로 배려하고 나의 시간을 효과적으로 아껴주었는가 +- **불필요하고 예민한 이야기를 세심하게 전달할 수 있어야 한다** + - SPIKES Model + - Setting (편안한 환경 조성) + - Perception (환자의 인식 정도) → 그 사람이 뭘 알고 있는지 먼저 인지 + - Invitation (얼마나 알고 싶어 하는가) + - Knowledge (정확한 정보 전달) + - Emotion (공감) + - Strategy and Summary (계획 수립과 요약) + - ‘안녕하세요’ 인삿말 하나만 넣어도 그 뒤에 날카로운 얘기를 해도 조금의 편안한 환경을 조성할 수 있다 + - 기본적인 원칙만이라도 잘 지키자 + +## 본인의 관점과 경험을 담아라 + +- 테크 블로그를 보면, 보통 자신의 ‘관점’이 없다 +- **직접적인 관계가 있어야 메시지의 힘이 강해진다** +- **설득력을 높이기 위해 많이 쓰고 많이 퇴고하라** + - 언어화 과정 + - 무의식 속 표현 저장고를 가득 채우자 + - 쓰기가 쉽지 않다면 많이 보고 많이 분석하라 + - 퇴고 체크리스트 + - Why와 What에 글 쓰는 시간의 80%를 투입하지만, 그만큼 중요한 퇴고를 놓치지 말 것 + - 자신이 무의식적으로 반복하는 안 좋은 표현을 골라내라 + - 같은 글을 오래 들여다 보면 확증 편향을 빠지기 쉬우니 동료를 활용하라 + +## 글의 얼굴은 ‘제목’입니다 + +- 제목이 중요하다 + +## 글의 리듬을 살려라 + +- **쉼표를 언제 찍지?** + - 같은 자격의 어구를 열거할 때 + - 비전, 미션, 핵심 가치 등 + - 짝을 지어 구별할 때 + - 테스트 커버리지 향상과 개발 속도 증가, 완벽한 테스트와 빠른 출시는 상극이다 + - 이웃하는 수를 계략적으로 나타낼 때 + - 5, 6월 + - 열거 순서를 나타내는 어구 다음 + - 특별한 효과를 위해 끊어 읽는 곳을 나타낼 때 + - 한 문장 안에서 앞말을 같은 어구로 다시 설명할 때 +- **말줄임표도 잘 쓰자** + - 이거 누가 한 거예요? + - 이거… 누가 한 거예요…? + +## 책 추천 + +- 김선영(글밥), <어른의 문장력> + +
+ +# 2. Compose UI 조합 심화 - 김수현님 + +## 용어 정리 + +- `Composition` : 객체 지향 프로그래밍에서 객체들을 조합하여 복잡한 기능을 구현하는 Composition + - 객체를 조합하여 구조를 설계하는 방식 +- `컴포넌트`는 UI 컴포넌트 + +## 중복을 제거한 컴포넌트 분리 + +- DRY 원칙 : 중복을 제거하여 재사용 가능한 코드 블럭을 만들어라 +- ex) 공통점 & 차이점이 있는 컴포넌트 (프로필 카드인데, ‘내’ 프로필인 경우에만 하단에 수정 및 공유 버튼 추가되는 컴포넌트) + - 가장 직관적인 해결책 - 조건문 + - **But, 무분별한 조건문은 컴포넌트의 복잡도 증가로 이어진다 (조건문 지옥)** + - DRY 원칙의 함정 → 만약 두 코드가 동일한 이유가 수정되어야 한다면 ‘중복’이지만, 수정되는 이유가 다르면 중복이 아님! + + ⇒ 컴포넌트 내 조건문 추가는 **서로 다른 수정 이유**를 갖는 컴포넌트들이 묶였다는 뜻 (해당 로직은 재사용에 적합하지 않다!) + + - 변경에 유연하게 대응할 수 있는 UI 구조가 필요하다! + +## 컴포넌트 조합 아이디어 1 - Slot 패턴 + +### Slot 패턴 + + +> 특정 영역을 외부에서 자유롭게 구성할 수 있도록 하는 디자인 패턴 +> +- 부모 컴포넌트는 자식 컴포넌트의 구체적인 구현에 대한 의존성 없이 UI 구조 정의하는 식으로 구현 가능 +- `bottomContent` 라는 Slot으로 받자 → 캡슐화 +- 요구사항이 바뀌어도 Slot으로 전달되는 컴포넌트만 수정하면 된다 + +### 활용 사례 - Compose Material Design Components + + +- 내부에서 대부분 Slot 패턴 활용 + +### Slot 패턴을 쓰기 좋은 상황 + + +- 컴포넌트의 레이아웃 구조는 유지하면서 특정 영역의 컨텐츠만 변경해야 하는 경우 + +### 한계 + +- 요구사항 추가 가정 + - 차이점이 여러 군데에서 발생하는 경우 + - UI 변경 사항이 발생할 때마다 Slot을 추가해야 하는가? + + → Component API가 오히려 복잡해질 수 있다 + + +## 컴포넌트 조합 아이디어 2 - Compound Component 패턴 + +### Compound Component 패턴 + +- 하나의 컴포넌트를 여러 조각으로 나눈 후, 외부에서 이들을 조합 +- 부모 컴포넌트가 상태를 관리, 자식 컴포넌트는 상태를 받아 UI 렌더링 + - 자식 컴포넌트들을 상태 관리 로직에서 분리되어 UI 표현에만 집중 +- React에서는 일반적으로 Context API를 통해 구현 + +### Kotlin + +1. Scope **인터페이스 생성** + - 자식 컴포넌트들이 접근할 수 있는 함수 등등 가지고 있음 +2. 대상 리시버 지정 +3. 자식 컴포넌트 (상태 접근) + +- 자식 컴포넌트들은 부모 컴포넌트의 상태를 공유하면서도, 부모 컴포넌트에 직접 의존하지 않음 +- 새로운 요구사항이 생겨도 자식 컴포넌트를 유연하게 조합 가능 + +### Compound Component 패턴이 언제나 적합하진 않다 + +- 비즈니스 로직과 밀접하게 연결된 경우 : 복잡도가 증가함에 따라 Scope 관리가 어려움 + - UI는 동일하지만, UI에서 참조하는 클래스가 변경되는 경우 + - Scope 인터페이스 수정, 관련된 모든 자식 컴포넌트에 영향! +- 부모의 상태가 변경되더라도 자식들은 그 변경을 감지할 수 없는 경우가 있을 수 있음 + - 컴포넌트의 상태가 자주 변경될 가능성이 있는 경우 **State Wrapping** 고려 +- **잘 사용하기 위해서는 리컴포저블과 선언형에 대한 이해가 필요함** + +### 활용 사례 - 디자인 시스템 + + +- 여러 하위 컴포넌트들을 부모 컴포넌트와 조합해서 사용할 때 진가를 발휘한다 +- 외부에서 사용하기 편리하고 일관된 API 제공 가능 + +### 활용 사례 - Lazy lists + +- `LazyColumn`, `LazyRow` +- `LazyListScope` + +## 컴포넌트 조합 아이디어 중간 정리 + +- 사진 + +### Slot 패턴과 Compound Component 패턴 + + +- 둘은 서로 배타적인 관계가 아니라 상호 보완적인 관계 + - Slot 패턴은 컴포넌트의 재사용성을 위한 기반 마련 + - Compound Component 패턴은 이를 바탕으로 더욱 유연한 UI 구축 가능 +- Stateless 컴포넌트는 UI에 집중, Stateful 컴포넌트는 상태 관리 로직 캡슐화 + +## UI Composition Best Practices + + +### Stream Video SDK + + +- 화상 통화, 오디오 룸 및 라이브 스트리밍 앱을 구축하기 위한 SDK +- 화상 통화 기능의 **하단 액션 바** 예시 + - Slot 패턴 사용 +- 오픈소스 프로젝트를 통해 디자인 패턴과 소프트웨어 아키텍처를 비롯한 다양한 모범 사례를 무료로 보고 아이디어를 얻을 수 있다 + +## 되돌아보기: 조건문이 정말 나쁜가? 중복이 정말 나쁜가? + + +- **중복은 코드의 겉모습이 아닌, 코드 수정의 이유가 같은지에 따라 판단** +- 핵심은 조건문 자체를 피하는 것이 아닌, +**조건문의 남용으로 인해 발생하는 복잡성 증가를 경계해야 한다**는 것 + - 일단은 조건문으로 적용하고, 복잡성이 증가하면 패턴을 적용하는 것도 좋다 +- 굳이 복잡한 패턴을 적용하는 게 더 나쁜 경우도 있다 (간단한 조건문으로 끝날 수 있는 경우도 있다) + +- UI 개발에서 지나치게 DRY 원칙에 집착하면, 오히려 코드의 복잡성을 높이고 유연성을 떨어뜨릴 수 있다 +- 나의 프로필과 다른 사람의 프로필 UI가 현재는 유사하지만, 미래의 비즈니스 요구사항 변경에 따라 두 UI가 완전히 다른 형태로 진화할 가능성도 있다 + +## 결론 + +- 각 패턴의 장단점을 정확히 이해하고, +컴포넌트의 역할과 책임, 예상되는 변경 사항을 고려하여 적절한 패턴을 선택해야 한다 +- 패턴 및 원칙 중심의 개발보다는, 구현하고 보니 패턴화 되어 있다 → 이런 게 더 좋다