UI 라이브러리 개발기

E6ab83a664e3508e199ef2114cdfc824?s=47 RIDI
January 11, 2019

UI 라이브러리 개발기

E6ab83a664e3508e199ef2114cdfc824?s=128

RIDI

January 11, 2019
Tweet

Transcript

  1. UI 라이브러리 개발기 퍼포먼스팀 백진욱

  2. 2 UI 라이브러리 자주 쓰이는 UI 컴포넌트를 한 데 모아

    놓은 것
  3. 2018. 8. “UI 라이브러리를 만드려는데 진욱님이 진행을 좀 맡아주시겠어요?”

  4. 상황 파악하기 “아무 것도 모르겠어요ㅠ”

  5. 상황 1. 이번이 처음이 아니다 이전에 만들어진 것들: RUI, RSG

    1.0, RSG 1.5, RSG 2.0...

  6. 상황 2. 미완성 상태 산재된 코드 (저장소에 코드가 없다!)
 컴포넌트

    간 일관성의 부족
  7. 기존 라이브러리 완성하기 코드를 한 데 모으자! ஹನք౟ ױਤ۽ ೞաঀ

    ৮ࢿदఃӝ!
  8. 잠깐! 옮기는 작업과 개선 작업이 동시에 진행 리뷰 과정에서 합의에

    이르기 까지 오래걸림 각 컴포넌트에 국한된 개선 라이브러리 전체 일관성 우려 어차피 다시 고치게될 것 8
  9. 옮기기만 하자 일단 산재된 코드를 모으는 것이 시급 동작만 되는

    수준으로 작업 고민 X 속도 O 전체적인 그림이 보이기 시작 9
  10. 모아놓고 보니.. 그 때 그 때 요구사항에 따라 구현된 것이

    많음 미처 라이브러리에 흡수되지 못하거나 요구사항 변경 → 돌연변이들이 나타나기 시작 10
  11. 걱정 또 만들어 놓고 또 안쓰게 되면 어떡하지? 11

  12. 잘 쓰이려면 쓰는 사람 → 사용자 사용자 → 사용성 쓰기

    편해야한다! 인터페이스 인터페이스를 다듬자! 12
  13. 인터페이스
 다듬기 인터페이스만 다듬기 구현 X 동작 코드 X 문서로만

    작성 마크다운 코드블럭 이용 구현 고민 없이 인터페이스에 집중 13
  14. 인터페이스
 다듬기 인터페이스만 다듬기 컴포넌트의 사용 예시 작성 인터페이스 정의

    X 컴포넌트 사용 예 O 컴포넌트를 어떤 식으로 사용하는 것이 편한가 여러 시안을 한 문서에서 비교 빠르게 여러 컴포넌트를 비교 14
  15. 구현하기 각 컴포넌트 별 인터페이스 문서 존재 구현에도 부담이 적음

    인터페이스 고민 X 15
  16. 16

  17. 17 아직 구현중입니다.. 조금만 기다려주세요^^; https://ridi.github.io/design-system/packages

  18. 어려웠던 점 18

  19. 결정장애 19 결정해야할 것이 너무 많음 인터페이스 패턴 선택 셋팅

    (Webpack, Rollup, CSSinJS...) 제공형식 (React, Non-React...) 답 없는 문제, 답이 너무 많은 문제 혼자 인고의 세월을...
  20. 커뮤니케이션 20 제3자적 입장 (ѐߊ੗X, ٣੗੉ցX, ࢎਊ੗X) 중간에 껴들어 와서

    의견을 강하게 어필하기 힘든 점 모든 것을 질문하게되는 상황이 됨 확신이 서지 않는 결정을 하면, 나중에 같은 논의가 반복
  21. 돌이켜보니.. 결국 최종 결정의 몫은 나 최선을 선택하더라도 바뀔 여지가

    많음 (그때는 맞고 지금은 틀리다) 해보고 별로면 다시 바꾸면 된다
 (는 자신감으로) 백지장도 맞들면 낫다 (회의, 리뷰를 진작에 할걸 ㅠ) 21
  22. 깨달은 점 협업에는 의사 결정자 필요 의사 결정자는 유연하지만 주관이

    강해야한다 22
  23. 디자인시스템 23 https://ridi.github.io/design-system

  24. 디자인시스템 디자인시스템 ⊃ UI 라이브러리 이상적 순서: 디자인시스템 → 구현

    안타깝게도 현실은 ㅠ 24
  25. 25 UI 라이브러리 → 테마 → ← 스타일가이드 ← 디자인시스템

  26. 마치며 “They dedicate just as much, if not more, effort

    to what I call the ‘second order’ API design: how code using this API would evolve over time.” - Optimized for Change, Dan Abramov 26
  27. 감사합니다 27