Skip to content
This repository has been archived by the owner on Dec 19, 2024. It is now read-only.

[Refactor] 픽미업 리팩토링 포인트 #167

Open
chorom-ham opened this issue Oct 5, 2020 · 0 comments
Open

[Refactor] 픽미업 리팩토링 포인트 #167

chorom-ham opened this issue Oct 5, 2020 · 0 comments

Comments

@chorom-ham
Copy link
Member

[픽미업 리팩토링 포인트]

  1. 목표
  • 코드의 복잡성을 낮추고 퍼포먼스를 향상한다.
  • 유지보수와 가독성이 좋은 코드를 작성한다.
  1. 디렉토리 구조
    pages/ 라우팅
    public/ 정적파일
    src/_actions 리덕스 액션
    src/_reducers 리덕스 리듀서
    src/_store 리덕스 스토어
    src/components 리액트 컴포넌트(아래는 아토믹 디자인 패턴 따름)
    src/lib 아예 외부로 뺄 수 있는 코드들이지만 편의상 진짜로 빼지 않은 코드
    src/types 밖으로 뺄 수 있는 타입 정의지만 편의상 빼지 않은 코드(외부 라이브러리나 기타 파일들의 모자란 d.ts / ex. 프론트와 백에서 동시에 쓰이는 타입)
    src/utils 말그대로 util 모듈 코드
  • components에서 lib아래 혹은 types 폴더로 코드를 빼는 기준

별도의 npm라이브러리라고 생각하고 사용할 수 있을 정도로 메인 코드에 대한 종속성이 없는 경우:
보통 api/.ts 혹은 hooks/.ts는 메인코드에 대한 종속성이 없으니 따로 뺀다(api나 hook에 사용되는 타입은 api/hook을 독립된 라이브러리로 생각할 수 있어야 하니 타입 정의도 api/hook 정의 바로 옆 두기)
type도 컴포넌트에 종속적인 경우 뺄 수 없으므로 컴포넌트 안에 정의함(반대의 경우에는 뺌)

  1. 세부방향
  • typeScript로 리팩토링한다.

타입에 any를 최대한 쓰지 않는다

  • 시맨틱 마크업을 고려한다

  • typescript-eslint를 도입한다(airbnb-base +@)

경고대로 문법을 수정한다

  • 독립적인 hook은 따로 빼 다른 디렉토리에 저장하고 import해서 사용한다

  • 코딩 컨벤션을 준수한다

변수명, 함수명은 lowerCamelCase로 작성한다
함수명은 동사로 시작한다
배열은 복수형 명사로 작성한다
축약어를 사용하지 않는다
변수명, 함수명만 보고 무슨 역할을 하는지 알 수 있도록 한다
컴포넌트는 UpperCamelCase로 작성한다
상수는 영문 대문자 SNAKE_CASE로 작성한다
URL, HTML 같은 범용적인 대문자 약어는 대문자 그대로 사용한다
custom hook의 이름은 use로 시작한다
외부 모듈 import와 내부 모듈 import를 따로 배치한다.(외부가 더 위에)
var을 사용하지 않는다. 정말 필요한 경우가 아니면 let을 사용하지 않는다. const를 사용한다. const를 let보다 위에 선언한다
배열 및 복잡한 객체 복사시 순환문을 사용하지 않는다. 전개 연산자를 사용한다.
모듈 로드 방법은 import/export를 이용한다
매 파일 가장 상위에 import React from "react";를 추가한다
인터페이스가 정말 필요한 경우(클래스 관련) 제외하고는 타입으로 타입 선언

  • 복잡한 상대경로를 사용하는 대신 @src를 사용한다

  • 배열 mapping시 key에 index를 넣은 것을 찾아 수정한다.

  • 객체를 prop에 통째로 넘기는 것을 찾아 수정한다.

  • 아토믹 디자인 패턴에 맞지 않는 컴포넌트를 수정한다.

파일이 위치한 디렉토리의 층위가 맞지 않는 경우
같은 형식의 코드가 반복되는 경우 컴포넌트로 따로 뺀다
재사용성이 없는 코드의 경우(필요시) 컴포넌트를 합친다

  • 불필요한 import나 중복 코드가 없는지 확인하고 수정한다.

  • 스파게티 코드나 중첩 깊이가 깊은 코드를 수정할 수 있으면 수정한다. (불필요하게 styled component 중첩 들어간걸 줄인다)

  • 동등 비교 연산시 삼중등호연산자(=== or !==)를 사용한다

  • 단항 증감 연산자를 사용하지 않는다(++ or --)

<참고>
https://ui.toast.com/fe-guide/ko_CODING-CONVENSION
https://ui.toast.com/fe-guide/ko_ANTI-PATTERN

  1. 이후 할 일
  • 각 브라우저 별로 제대로 렌더링 되는 지 확인한다
  • 백엔드 개발 / 디자인 완료 시 추가 기능 개발한다
  • 테스트 코드를 작성한다
  • 검색 엔진 최적화 작업을 한다
  • 리드미 문서를 작성한다

컴포넌트의 복잡성을 낮추는 데 어려움을 겪을 때는 같이 논의하고 고민해봐요~!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant