FEConf2022 방문기

윤뿔소·2022년 10월 8일
0

외부 경험

목록 보기
1/2
post-thumbnail

개발 시작한지 3달 째지만 현장 분위기, 내가 알지못해도 체감할 수 있게 경험 차원에서 와봤다. 거금 3만원 지불하고 왔으니 제대로 봐보자
A트랙 많이 이동한 주제 : 프론트엔드 DDD 개발법

B Track

FLEX - 이소영

디자인 시스템, 형태를 넘어서

디자인 시스템 어떻게 정의(구축)할 것인가

  • 형태가 강하게 결합된 디자인시스템은 문제점이 있음-유연성 x, 병목발생
  • 그래서 디자인 시스템을 처음부터 제대로 구축해야함
  • \<Select /> 사례
    • 닫힌 태그로 전체 작성하면 무거워짐, 각 요소로 원하는 걸 넣으면 복잡해짐
    • 즉 어떻게 디자인을 설계할지 관건
  • 형태 기능 접근성 커스텀으로 디자인 시스템 접근
    • 형태 : 기본스타일, 컬러, 레이아웃 등 나타나는 외모
    • 기능 : N개 아이템 선택, 아이템표현 등 수행하는 동작
    • 접근성
    • 커스텀
    • 형태와 커스텀이 중요, 각 시스템에 맞춰서
  • 기본 형태를 유지하고 나머지 커스텀 등을 맞춰서 가는게 문제를 명확히 하고 해결 보다 쉽게
  • LINEAR로 그 문제 쉽게 해결 가능, FDS 에서 발달
    • 디자인 시스템을 구축하는데 좋은 튤
    • 원칙 기능은 형태와 독립적, 기본동작 보장, 최소한의 제약만 가짐
      • ㄷㄹㅈ : 예 - 체크백스, 라디오는 형태만 다르고 같은 기능(의미)
      • ㄱㅂㄷㅈ : 반복 코드 줄이고(효율성), 일관성 유지해야함, 당연해도 제일 어려움, 예 - 스크롤영역: 어떠한 모달들 하나가 아닌 모두 스크롤이 존재해야 일관성을 유지할 수 있음, 즉 기본동작을 정의하자! 기본동작이 아니면 제거
      • ㅈㅇ : 리니어는 어떠한 모달이든 커스텀이 가능해 제약이 적음, 추상화된 인터페이스
  • 리니어도 단점 발생
    • 컴포넌트의 추상화 레벨에 따라 요구사항이 많은 것에는 괜찮지만 작은 것에는 비효율 조합에 대한 비효율
    • 리니어 익스텐션 발출 : 반복작업의 비효율 감소, 구체적 데이터타입 설정 가능,

토스 - 오창영

일백개 패키지 모노레포 우아하게 운영하기

우아하게 운영? 라이브러리는 이렇게 운영하자

  • 모노레포 ✨️잘 정의된 관계를 가진 여러개 독립된 컴포넌트
  • 기본은 멀티레포(지토리), 생성 비용 증가, 프로젝트끼리 코드 공유 어려움, 각각 레포에 커밋 필요, 히스토리 관리 비용 증가, 제각각의 툴링으로 개발자 경험이 노일반적
  • 모노레포가 해결 : 새 프로젝트 생성비용 감서, 코드 공유 쉬움, 아토믹 커밋, 히스토리 관리 저하, 공통된 툴링
  • 근데 다 좋은 건 아님, 잘 정의해야 좋은거임
  • 툴들
    • 속도 : 로컬 컴퓨테이션 캐싱, 로컬태스크오케스트래이션, 멀티캐싱,
    • 관리 : 코드공유 가능, 쉽게 코드 일반화-통일, 프로젝트 컨스트래인트 앤드 비지빌러티
  • 그러면 우아하게 개발하자는 건 무엇? 토스의 모노레프 라이브러리를 보자
    • 실무에 적용하는 라이브러리를 모노레포로 라이브러리만, 서비스 관련 라이브러리로 나눠 관리함
    • 기술적 요구사항 ; 의존성관리, 버전관리, 코드품질관리, 문서화
      • ㅇㅈㅅㄱㄹ : 유령 의존성으로 인한 오류가 있기에 PnP + Yarn으로 툴을 만들어 사용, peer 디펜던스를 잘 사용하기- 싱글턴 패키지만 써주는게 좋음!
      • ㅂㅈㄱㄹ : Semver를 잘 쓰자!-요구사항 중시(0.0.0 맞춰 버전 관리-네이버블로그에 있는데..?), Lerna 툴을 사용해 버전을 광리한다!
      • ㅋㄷㅍㅈㄱㄹ : RFC-렌더링 엊ㅅ이 아이디어(풀리퀘스투)만으로 라이브러리의 이슈에 대해 건의해 쉽게 피드백 받기 가능
      • ㅁㅅㅎ : 누구든지 사용 가능하게 문서화하기, 주석 잘 달고 그러기

박신연·구글 검색

UX 개발자, 대형 서비스 빠르게 프로토타입하기

프로토타이핑 - 현업에 소통을 위한 기술로 '시제품'을 만들어 더 나은 협동으로 나아가자

  • 프리토타입(있는 척 해보기), 디자인프로토타입(피그마, 스토리북 등), 기술프로토타입(디자인이 못한, 데이터 이용한, 모션, 제품 정보를 이용한 새로운 상호작용(동작)을 제시, 동적 변수 고려)
  • 목적이 중요! 목적을 설정하자
    • 무엇을 테스트, 몇명? 어떤 사용자 대상?
  • 어떤 기능 구현에 따라 목업 환경, 컴포넌트 환경, 실제환경
    • ㅁㅇ : 특정 기능에 집중한 테스트나 구현에 좋음, 데이터 상관없이
    • ㅋㅍㄴㅌ : 데이터 반영, 비교적 실제과 같은 경험 제시, 대형 서비스에서는 매우 다수의 컴포넌트를 런칭하고 있음
    • ㅅㅈㅎㄱ : 실제환경 테스트로 추가적인 테스트 안해도 됨

박서진 토스

내 import 문이 그렇게 이상했나요?

핫한 ESM과 import의 깊은 얘기

  • import, export는 컴파일돼 require이 된다.. 신기
  • Common JS의 Require 문제(비동기 불가, 정적 분석 어려움, 언어표준x)로 import가 생김
  • 쉬운 정적 분석, 쉬운 비동기 모듈, 언어표준(ESM)
  • require 오류 이유: 동기와 비동기 관계로 오류가 왜뜨는지?
    • common JS는 동기, esm은 비동기인데 비동기에서 동기를 하기엔 쉽지만 반대는 어려움
    • 그래서 esm을 기반으로 모듈을 사용하는게 좋아!
  • esm 규칙(옮길때 주의사항)
    • JSON에 "type": "module"라고 작성하면 모든 js파일이 esm으로 동작
    • require 삭제
    • 확장자 꼭 작성
    • .cjs는 CJS(require), .mjs는 ESM(import)
  • 하지만 옮기기 어려움
    • 가짜 ESM이 될수도 : require(파일을 순회해서 얻어옴)과 달리 파일에 .js같은 확장자 꼭 붙여야 제대로된 ESM 가능
    • 부족한 생태계 : jest, node, ts, yarn 등 지원 x, 하지만 얼마전 TS에 도입됐음, 근데 현재 .ts가 아닌 사실 .js로 임포트 해야함(add.ts가 있다면 add.js로)
    • 일부만의 라이브러리(next/app.js) 참조 불가능
  • ts, Yarn PnP, ts-node는 쓰지않고 리액트, 이모션 등만 조건이 만족되는 것만 esm을 사용하자!

esm? yarn??

최수형 메가테라

상태관리, 이 전쟁을 끝내러 왔다

전역 상태관리를 지워라

  • Redux는 많은 비판을 받고있음, 순수함수만 써야되고 거대해지는 단일 스토어, 등등
  • 직접 코딩하며 스토어에 대한 효율성을 알려주샸는데 난 거의.. 무슨 내용인지..
  • 그나마 알게된 건 리팩토링할 때 테스트 코드를 사용해서 하면 더 막 할 수 있대..
  • usestore-ts 에 쉽게 상태관리할 수 있는 툴 쓸수 있움!
  • 테스트코드를 잘 써서 사용하자! UI에는 테스트 하지말기

store?? hook-useSyncExternalStore? ✨️TDD?

후기

솔직히 자신을 많이 돌아봤다.
물론 뭐 얼마나 했다고 돌아볼게 있냐만은 발표자님들이 만들어놓은 컴포넌트나 깨달은 것들, 또 직접 코드를 작성하시는 모습을 보고 되게 감명받으면서도 의욕이 꺾인 듯한 느낌을 받았다. '나도 저렇게 될 수 있나?', '저렇게 안되면 어떡할까?' 하는 막연한 부정적 생각들을 펼쳤다. 그도 그럴 것이 깨달은 거에 대한 포인트, 코드를 작성하는데 막힘 없는 모습들을 보면서도 감이 안잡히는 나의 모습과 내가 걸어온 3개월간 모습을 봤을 때 초라해지는 나를 느꼈다. 당연히 3개월한 나와 그 분들을 비교하여 '못뛰어넘다니..!'하는 오만한 생각이 아니라 그동안의 나의 나태에 대해서 돌아보게 됐다. 내가 어떤 기술, 요령을 가지고 있다고 그동안 조금의 어떤 공부라도 게을리 했었나 하고 반성했다.
그러면서도 나는 내가 이쪽 업계에 발을 들인 이유와 왜 하고싶은지에 대한 이유를 복기했다. 나는 그저 돈벌려고 온 것이 아니라 나만의 기술과 내가 만들어낼 수 있는 가시적인 작품을 만들어내는 것, 또 그것이 엄청 재밌다는 것, 이 분야가 비단 컴포넌트 개발에만 국한되지 않고 다양한 분야 및 사업으로 확장할 수 있는 것 등을 생각했다.
결론은 '모르는 것에 대한 공부와 개발에 익숙해지는 것만이 내가 추구하고 싶고 원하는 목표로 갈 수 있다!'라고 지어졌다. 더 열심히만 말고 잘해보자 ㅎㅎ

  • 맥북 가져오기 핸폰으로 필기하니 힘듦
  • 컨퍼런스 전날 페이스북 페이지 보고 계획 짜기, 1시간 일찍 와서 자리 꼭 맡고 부스 돌자
  • 페이스북에 티켓팅 후 며칠 뒤에 스태프 구인하니 실패했으면 해보기
  • 1년마다 듣기 좋은듯 알차다
profile
코뿔소처럼 저돌적으로

0개의 댓글