68 2021-09-07 ~ 2022-01-07 금 중간체크 - 4개월간 해온 것들

source: categories/study/vue-experiance/vue-experiance_9-68.md

68 2021-09-07 ~ 2022-01-07 금 중간체크 - 4개월간 해온 것들

목표 1. UI 개발 - 컴포넌트 리뉴얼 및 고도화

  • PC 컴포넌트: 링크

  • MO 컴포넌트: 링크

  • 해당목표설정 이유
    1. 기존 UI와 달라진 UI 디자인
    2. 사용자에게 깔끔하고 부드러운 UX 제공
      • 과거 여러 인터렉션을 구현해본 경험을 토대로 사용자 경험을 증대시킬 수 있는 부드러운 인터렉션을 가진 컴포넌트 개발하고자함
  • 과정
    1. 사용자 입장에서 각 컴포넌트를 설계 및 구현
      • ex1) dropdown 컴포넌트 같은 경우 해당 컴포넌트의 위치에 따라 select box 생성되는 위치 조정
      • ex2) popup dimmed 영역 클릭시 인터렉션 효과 고민 > 기존대로 팝업을 강조하며 사용자에게 팝업의 중요성을 알리는 방식으로 결정
    2. 재사용성과 확장성을 고려하여 컴포넌트 설계 및 구현
    3. 라이브러리 사용한 컴포넌트들은 API를 충분하게 조사 후 구현
      • 라이브러리에서 이미 제공하고있는 기능임을 인지못하고 직접 개발할 수 있는 문제 차단
    4. range slider 컴포넌트 구현시 크로스브라우징 및 자잘한 버그 이슈 직면
      • IE, Safari, Chrome 등 각 브라우저에서 체크 및 테스트
      • 보완 코드 작성 및 해결 안될 경우를 위해 대안책 강구
      • 대안책으로 vuetify 라이브러리 리서치
    5. 구현 후 Window OS, Mac OS, IE, Chrome, iPhone, Galaxy 등에서 기능 테스트
  • 결과
    1. 모든 컴포넌트들을 무리없이 개발 완료
    2. 인터렉션 및 애니메이션 효과 적용을 통해 보다 더 나은 사용자 경험 제공
    3. 개발하며 폴더 구조 및 효율적인 컴포넌트 적용 방식에 대해 정리
      • 이를 토대로 추후 개발에 보다 더 효율적으로 개발진행할 수 있을 것으로 기대

목표 2. FE 개발 - DB 데이터 구조에 적합한 컴포넌트 개발

  • PC 컴포넌트: 링크

  • MO 컴포넌트: 링크

  • 해당목표설정 이유
    1. 데이터 구조에 적합한 컴포넌트 개발을 통해 BE 개발자들의 수고를 덜어주기 위함
    2. 데이터 구조를 미리 생각함으로인해 좀 더 완성도 높은 컴포넌트 개발
  • 과정
    1. 스웨거를 통해 더미 데이터 작성
    2. 해당 더미 데이터를 통해 가짜 데이터통신 코드 작성 > UI 컴포넌트 개발
    3. 더미 데이터 통신을 통해 구현되는 UI 컴포넌트 경우의 수 정리
  • 결과
    1. BE 개발자분들이 컴포넌트를 다시 데이터 구조에 맞도록 커스텀해야하는 시간 제거
    2. 미리 데이터 구조를 고려함으로인해 인터렉션을 보다 더 수월하게 개발

목표 3. vuetify 적용

  • PC
  • MO
  • 목표설정 이유
    1. 복잡한 컴포넌트를 직접 구현할 필요가 없음 (생산성 증대)
      • 기존엔 복잡한 컴포넌트를 포기하거나 다른 방향으로 바꿔 진행하는 경우가 많았음, 이를 vuetify 라이브러리를 통해 해결
      • ex1) range slider 컴포넌트같이 고려해야될 점이 많은 복잡한 컴포넌트를 직접 구현할 필요가 없음
    2. 많은 개발자가 만든 라이브러리이므로 버그가 적음
      • vuetify 라이브러리에 기여한 개발자 수 - 703명
    3. 버그가 생기더라도 이슈 트래킹이 수월
      • vuetify 관련 블로그, stackoverflow 글 등이 많음
  • 과정
    1. vuetify 라이브러리 적용
    2. vuetify 라이브러리 적용으로인한 사이드이팩트 확인 및 제거
      • v-application, v-main 등 vuetify 클래스를 가진 root 요소가 추가되면서 기존 css overwrite 이슈 발생
      • postcss-filter-rules 라이브러리를 통해 컴파일시 v-application, v-main 등 root 요소 선택자를 통해 부여되는 스타일 제거
      • vuetify의 elements, generic 스타일이 기존 스타일을 overwrite하는 이슈 발생
      • 웹팩 번들 실행되기 전에 해당 스타일들을 초기화하는 코드 추가:
  • 결과
    1. 사이드 이펙트 없이 적용 완료 및 복잡한 컴포넌트도 쉽게 적용할수 있음으로인한 생산성 증대
    2. 적용한 컴포넌트에 버그가 있어도 이슈 트레킹이 수월하여 빠른 시간내에 픽스 가능
    3. 향후 훨씬 더 다이나믹하고 부드러운 효과를 가진 컴포넌트 적용이 가능할 것으로 기대 (디자인, 기획 범위 확대)

목표 4. sprite image 자동생성 기능 적용

  • PC: sprite image 자동화 코드

  • MO: sprite image 자동화 코드

  • 목표설정 이유
    1. 기존 작업 방식의 비효율성
      • 이미지들을 일일이 포토샵 또는 스캐치에서 합침
      • 각 이미지들의 좌표 또한 일일이 작업자가 계산
      • 단순한 작업임에도 불구하고 큰 리소스 발생 및 실수 유발
    2. 작업 시간과 실수 유발을 방지하기 위해 해당 기능 구현
  • 과정
    1. sprite image 자동 생성 코드작성 및 테스트
      • 이전 회사에서 webpack을 통해 sprite image 자동 생성 기능 구현 경험을 바탕으로 기능 구현
    2. wiki 해당 내용 가이드 작성
  • 결과
    1. sprite image 자동 생성 기능 추가 완료
    2. sprite image를 수작업으로 직접 생산 안해도되어 작업시간 단축 및 생산성 증대
    3. 단순 반복 업무로인해 유발되는 개발자의 실수 차단

목표 5. Storybook 적용

  • PC
  • MO
  • 목표설정 이유
    1. 기존 환경: 어떤 UI 컴포넌트가 존재하는지 히스토리는 어떻게 되는지 파악 어려움
      • 나중에 들어온 개발자가 작업하기 어려운 환경
    2. 위와 같은 점을 개선하기 위해 해당 기능 구현
  • 과정
    1. 현재 프로젝트에 vue storybook 기능 추가
      • 이전엔 react 환경에서 storybook 사용
      • vue 환경에선 처음 적용해보는거라 리서치 및 테스트를 여러번 거침
    2. 리뉴얼한 컴포넌트들 storybook 정리
    3. wiki 해당 내용 가이드 작성
  • 결과
    1. storybook 적용 완료
    2. 현재 사용되는 컴포넌트 및 히스토리 파악 용이

목표 6. 코드 리팩토링 및 코드 작성 규칙 강화 eslint, prettier, stylelint, git hook

  • PC
  • MO
  • 목표설정 이유
    1. 웹, 앱 성능 향상 및 예측 불가능한 에러 방지
    2. 코드 컨벤션 익혀야되는 번거로움 없앰
  • 과정
    1. 필요없는 코드(사용되지 않는 변수, 함수, 실행되지 않는 구문) error로 인식
    2. vue에서 반드시 지켜야되는 코드 규칙 지키도록 강제, 안지키면 error로 인식
    3. 데이터 유형까지 비교하는 ===와 같은 연산자 사용하도록 강제 (값만 비교하는 ==와 같은 연산자 사용하면 error로 인식)
      • 일부 데이터 유형이 일치하지 않게 넘어오는 데이터에서 이슈 발생
      • 데이터 유형을 일치시키는 코드 작성해서 해결
    4. Tab size, css Style 속성 정의 순서, 개행 규칙 등 정의
    5. Error 로 잡히는 내용이 한개라도 있으면 git commit 자체가 안되도록 git hook 기능 추가
    6. 원래는 Import 순서 및 vue docs의 recommand 사항들도 준수하도록 해당 규칙들도 설정
      • 그런데 docker에 배포할 때 빌드 이슈 발생, 로컬에선 빌드 이슈 X
      • 빌드 에러를 해결하기위해 테스트 진행
      • essential(필수) 규칙들만 강제하도록 lint 기능 수정, 해당 이슈 해결
  • 결과
    1. 기능적용 완료
    2. 작업자가 많아도 사용하는 에디터가 달라도 같은 코드 스타일 유지 ( 서로 다른 코드 스타일로인한 불편함 방지 )
    3. git에 최소한의 diff만 잡힘 ( 코드 파악 용이 )
    4. 필요없는 코드 등 여러 규칙 강제로 인한 웹, 앱 성능 향상 및 예측 불가능한 에러 방지될 것으로 기대
    5. 컨벤션을 안 읽어봐도 코드 규칙을 준수할 수 있게함으로써 생산성 증대될 것으로 기대

목표 7. 트리쉐이킹 기능 강화

  • PC
    • eslint 규칙 lodash 라이브러리 사용하면 error lodash-es 라이브러리 사용 강제
      • lodash는 예전 CommonJS 문법으로 작성된 라이브러리로 트리쉐이킹 미지원
      • lodash-es는 이런 단점을 보완하기위해 ES6 Module 문법으로 작성된 라이브러리
    • 기존 lodash 코드 lodash-es로 수정
    • vuetify 경로 수정
      • 전체가 아닌 필요한 부분만 불러오도록 수정
    • chart.js 2버전에서 3버전으로 마이그레이션 : 이 부분은 다른분이 지원해주심
      • chart.js 2버전 또한 트리쉐이킹 미지원, 3버전부터 지원
  • MO
  • 목표설정 이유
    1. 현재 빌드 결과물의 자바스크립트 용량이 큼 (자바스크립트 리소스는 웹, 앱 성능에 다른 리소스에 비해 훨씬 더 큰 영향을 끼침)
    2. 레거시 라이브러리 및 코드 개선
      • 트리쉐이킹 기능 구현을 통해 레거시 라이브러리, 코드를 알아낼 수 있음
  • 과정
    1. webpack-bundle-analyzer 라이브러리로 현재 프로젝트에서 각 라이브러리 및 코드들이 차지하는 용량 비중 파악
    2. Is-esm 라이브러리를 통해 해당 라이브러리들이 트리쉐이킹을 지원하는지 안하는지 파악
    3. 용량 비중이 높은 라이브러리 트리쉐이킹 기능 강화 및 트리쉐이킹 지원하는 라이브러리로 교체
      • 라이브러리: CommonJS로 작성된 라이브러리인지 ES6 Module 문법으로 작성된 라이브러리인지 파악 (is-esm 라이브러리 활용)
      • CommonJS로 작성된 라이브러리는 트리쉐이킹에 부적합한 라이브러리 > ES6 Module 문법으로 작성된 라이브러리로 교체 및 코드 마이그레이션
    4. 레거시 코드 개선
    5. 위 과정 반복
  • 결과
    1. 기능 구현 방법 파악 및 적용 완료
    2. 레거시 코드 제거
    3. 빌드 결과물 용량 최소 1mb ~ 2mb 감소 기대 -> 자바스크립트 파일 용량이라 웹 성능이 크게 향상될 것으로 기대
    4. 향후 라이브러리 선택 및 코드 작성 가이드를 만들 수 있을 것으로 기대

다음 목표

  1. 타입스크립트
  2. Jest 테스트코드
  3. 포스트맨 사용