프론트엔드 코딩 컨벤션 리마인드

일정에 쫓겨 정신줄 놓고 코딩하다 보면 오히려 동료들의 코드리뷰 시간과 

수정하는 리소스가 들어 비효율을 초래하게 된다.

 

이틀 동안 바쁘게 개발하다 보니 호되게 코드리뷰를 받고, 다시는 같은 실수를 반복하지 않기 위해

글로 남기려고 한다~

 

 

---

코드리뷰

부끄럽지만 같은 실수를 하는 것은 나와 나의 동료의 리소스를 뺐을 수 있다.

적어두고 몸에 배어 단단한 습관이 되도록 기록하고 계속 읽어보자

 

 

props로 setter(setState)하는 콜백은 되도록이면 넘기지 말기

 

- 되도록이면 호출이 필요한 시점에 호출을 트리거하는 곳에서 호출하자 

- 코드를 유지보수하는 쪽에서 작동을 파악하는 데 더 용이함

- 호출 제어권을 밖으로 빼어 사이드 이펙의 가능성을 줄임

- 양방향 데이터 바인딩은 지양

 

---

 

핸들러 네임 컨벤션

 

- props 이름 = on + 이벤트 이름

- props에 적용하는 핸들러 이름 = handle + 이벤트 이름

 

사실 아래와 같은 경우는

onSelect도 onChange로 바뀌고

updateOptionNameEditMode도 onChangeOptionNameEditMode로 바뀌어야 한다.

 

(updateOptionNameEditMode은 boolean값을 받아 editMode를 set 하는 역할을 하기 때문)

---

 

안 쓰이는 구문

- 아래 eslint-plugin으로 싸악 청소해 주자 (게비스콘 짤)

https://www.npmjs.com/package/eslint-plugin-unused-imports?activeTab=dependencies

 

---

스타일 디테일

 

누가 봐도 거슬리는 스타일은 FE 개발자 선에서 처리해 보자

 

 

 

---

 

에러 처리

 

- 예상할 수 있는 에러는 명시적으로 Error 객체를 던져주자

- sentry & catch에서 에러를 잡아낼 수 있음

 

 

 

---

에러 처리 2

 

- else 대신 예상할 수 있는 에러는 명시적으로 Error 객체를 던져주자
- 유지보수가 더 용이하며 코드를 보고 의도를 파악하기 더 쉬워진다.

 

코드예시

const fetchRecommendOptionNames = useCallback(
    (sellingMarket: SellingMarket) => {
      switch (sellingMarket) {
        case SellingMarket.Coupang:
          fetchCoupangRecommendOptionName();
          break;
        case SellingMarket.St11:
        case SellingMarket.Auction:
          fetchEsmRecommendOptionName();
          break;
        default:
          throw new Error(
            `fetchRecommendOptionNames: ${sellingMarket} sellingMarket is invalid`,
          );
      }
    },
    [fetchCoupangRecommendOptionName, fetchEsmRecommendOptionName],
);

 

---

이벤트 props 네이밍 컨벤션

 

- 네이티브 이벤트 핸들러 기반으로 보편적인 네이밍

- 핸들러의 동작 여부 쉽게 파악 

 

 

---

 

이렇게 써보니 좀만 신경 썼다면 좋았던 경우가 대부분 인 것 같다..

 

명심하자 신경쓰지 않고 대충 짠 코드는

동료의 코드리뷰 리소스 + 나의 재수정 리소스
더 나아가 조직 전체의 리소스 저하로 초래된다 정신 차리고 차분하게 생각하고 더 신경 쓰자