Frontend Fundemental (토스, 프론트엔드 좋은 코드 작성하기) 정리

Props Drilling 지우기

Props Drilling 지우기

 

---

 

구독중인 유튜버가 하나의 영상을 새롭게 올렸는데, 토스에서 작성한 Frontend Fundemental을 소개하는 영상이었다. Frontend Fundemental은 Toss 개발자가 작성한 좋은 프론트엔드 코드의 기준을 자신들의 기준에 맞춰 작성한 문서이다. 프론트엔드 개발을 하면서 다양한 소스를 보지 못해 어떤 코드가 좋은 코드인지 모르겠다는 생각을 했는데 이 문서를 정독하여 좋은 코드란 무엇인지 읽어보고 현재 나의 코드는 어떤지 돌아보고 나만의 좋은 코드를 작성하기 위해 생각을 정리해보는 시간을 가지고자 한다.

 

Frontend Fundemental에서 제시한 좋은 코드의 4가지 원칙은 아래와 같다. 해당 원칙은 결국 “변경하기 쉬운 코드”라느 생각에서 나온다. 새로운 요구사항이 발생했을 때 기존 코드를 수정하고 배포하기 수월한 코드가 좋은 코드이다. “변경하기 쉬운 코드”의 기준을 아래 4가지 기준으로 판단하는 것이다.

• 가독성(Readability)
  • 읽기 쉬운 코드
  • 코드를 쉽게 변경하려면 우선 코드가 어떤 동작을 하는지 쉽게 이해할 수 있어야 한다.
  • 읽기 좋은 코드는 읽는 사람이 한 번에 머릿속에서 고려하는 맥락이 적고, 위에서 아래로 자연스럽게 이어진다.
• 예측 가능성(Predictability)
  • 협업하는 동료들이 함수나 컴포넌트의 동작을 얼마나 예측할 수 있는지
  • 예측 가능성이 높은 코드는 일관적인 규칙을 따르고, 함수나 컴포넌트의 이름과 파라미터, 반환값만 보고도 어떤 동작을 하는지 알 수 있다.
• 응집도(Cohesion)
  • 수정되어야 할 코드가 항상 같이 수정되는가
  • 코드의 한 부분을 수정해도 의도치 않게 다른 부분에서 오류가 발생하지 않는 코드
  • 가독성과 응집도는 서로 상충할 수 있다. 일반적으로 응집도를 높이기 위해서는 변수나 함수를 추상화하는 등 가독성을 떨어트리는 결정을 해야 한다. 함께 수정되지 않으면 오류가 발생할 수 있는 경우에는 응집도를 우선하고, 추상화하고, 위험성이 높지 않은 경우에는 가독성을 우선하여 코드 중복을 허용한다.
• 결합도(Coupling)
  • 코드를 수정했을 때의 영향범위
  • 코드를 수정했을 때 영향범위가 적어서, 변경에 따른 범위를 예측할 수 있는 코

위의 4가지 원칙 중 몇 가지는 클린코드나 여러 다른 관련 책에서 들어봤을 것이다. 해당 문서는 위의 4가지 원칙에 대하여 어떻게 해당 원칙에 따라 좋은 코드를 만들 것인지 상세하게 알려준다.

---

1. 가독성

맥락 줄이기

A. 같이 실행되지 않는 코드 분리하기

• 동시에 실행되지 않는 코드가 하나의 함수 또는 컴포넌트에 있으면, 동작을 한눈에 파악하기 어렵다.
• 하나의 컴포넌트는 하나의 분기만 관리한다.

B. 구현 상세 추상화하기

• Wrapper 컴포넌트 사용
• HOC(Higher-Order Component) 사용
• 추상화

C. 로직 종류에 따라 합쳐진 함수 쪼개기

• 쿼리 파라미터, 상태, API 호출과 같은 로직의 종류에 따라 함수나 컴포넌트, Hook을 나누지 말 것
• 좋은 성능을 위해서는 특정한 상태 값이 업데이트되었을 때 최소한의 부분이 리렌더링되도록 설계해야 한다.
  • → 파라미터별로 별도의 Hook 작성

 

이름 붙이기

A. 복잡한 조건에 이름 붙이기

• 복잡한 조건식이 특별한 이름 없이 사용되면, 조건이 뜻하는 바를 한눈에 파악하기 어렵다.
• 따라서 조건에 명시적인 이름을 붙이면, 코드를 읽는 사람이 한 번에 고려해야 할 맥락을 줄일 수 있다.

**<조건식에 이름을 붙이는 기준>**

**조건식에 이름을 붙이는 것이 좋을 때**
1. 복잡한 로직을 다룰 때
- 조건문이나 함수에서 복잡한 로직이 여러 줄에 걸쳐 처리되면, 이름을 붙여 함수의 역할을 명확히 드러내는 것이 좋다. 
2. 재사용성이 필요할 때
- 동일한 로직을 여러 곳에서 반복적으로 사용할 가능성이 있으면, 변수나 함수를 선언해 재사용할 수 있다. 
3. 단위 테스트가 필요할 때
- 함수를 분리하면 독립적으로 단위 테스트를 작성할 수 있다. 

**조건에 이름을 붙이지 않아도 괜찮을 때**
1. 로직이 간단할 때
2. 한 번만 사용되며 로직이 복잡하지 않을 때

B. 매직 넘버에 이름 붙이기

• 매직 넘버(Magic Number)란 정확한 뜻을 밝히지 않고 소스 코드 안에 직접 숫자 값을 넣는 것
• 상수 선언을 통해 매직 넘버에 이름 붙이기

 

위에서 아래로 읽히게 하기

A. 시점 이동 줄이기

• 코드를 읽을 때 코드의 위아래를 왔다갔다 하면서 읽거나, 여러 파일이나 함수, 변수를 넘나들면서 읽는 것
• 코드를 위에서 아래서, 하나의 함수나 파일에서 읽을 수 있도록 코드를 작성하면, 읽는 사람이 동작을 빠르게 파악할 수 있다.

B. 삼항 연산자 단순하게 하기

• if문으로 풀어서 사용

---

2. 예측 가능성

A. 이름 겹치지 않게 관리하기

• 같은 이름을 가지는 함수나 변수는 동일한 동작을 해야 한다.

B. 같은 종류의 함수는 반환 타입 통일하기

• API 호출과 관련된 Hook들처럼 같은 종류의 함수나 Hook이 서로 다른 반환 타입을 가지면 코드의 일관성이 떨어진다.
• 서버 API를 호출하는 Hook의 반환 타입이 서로 다르다면, 동료들은 Hook을 쓸 때마다 반환 타입이 무엇인지 확인해야 한다.
• 유효성 검사 함수의 반환 값이 다르면, 위와 동일하게 동료들은 함수를 쓸 때마다 반환 타입을 확인해야 한다.

C. 숨은 로직 드러내기

• 함수나 컴포넌트의 이름, 파라미터, 반환 값에 드러나지 않는 숨은 로직이 있으면 협업하는 동료들이 동작을 예측하는 데 어려움을 겪을 수 있음

---

3. 응집도

A. 함께 수정되는 파일을 다른 디렉토리에 두기

• 함께 수정되는 소스 파일을 하나의 디렉토리에 배치하면 코드의 의존 관계를 명확하게 드러낼 수 있다.
• 함께 수정되는 코드 파일을 하나의 디렉토리 아래에 둔다면, 코드 사이의 의존 관계를 파악하기 쉽다.

└─ src
   │  // 전체 프로젝트에서 사용되는 코드
   ├─ components
   ├─ containers
   ├─ hooks
   ├─ utils
   ├─ ...
   │
   └─ domains
      │  // Domain1에서만 사용되는 코드
      ├─ Domain1
      │     ├─ components
      │     ├─ containers
      │     ├─ hooks
      │     ├─ utils
      │     └─ ...
      │
      │  // Domain2에서만 사용되는 코드
      └─ Domain2
            ├─ components
            ├─ containers
            ├─ hooks
            ├─ utils
            └─ ...

 

B. 매직 넘버 없애기

• 숫자의 의미를 명확히 표시하기 위해 상수로 선언한다.

 

C. 폼의 응집도 생각하기

필드 단위 응집도

• 필드 단위 응집은 개별 입력 요소를 독립적으로 관리하는 방식이다.
• 각 필드가 고유의 검증 로직을 가지므로 변경이 필요한 범위가 줄어들어 특정 필드의 유지보수가 쉬어진다.

폼 전체 단위 응집도

• 폼 전체 응집은 모든 필드의 검증 로직이 폼에 종속되는 방식이다.
• 폼 전체에서의 흐름을 고려하여 설계되며, 변경 단위가 폼 단위로 발생할 때 로겨한다.
• 폼 전체 응집도를 높이면, 폼 전체의 검증이 한 곳에서 관리되어 로직이 간결해지고, 상태가 중앙집중식으로 관리되므로 폼 전체 흐름을 이해하기 쉬어진다.
• 필드 간의 결합도가 높아지므로 폼의 재사용성은 떨어질 수 있다.

필드 단위 vs 폼 전체 단위 응집도

• 필드 단위 응집도를 선택하면 좋을 때
  • 독립적인 검증이 필요할 때
    • 필드별로 복잡한 검증 로직이 필요하거나 비동기 검증이 필요한 경우
    • 이메일 형식 검사, 전화번호 유효성 검증, 아이디 중복 확인, 추천 코드 유효성 확인처럼 각 필드가 독립적이고 고유한 검증이 필요할 때 유용
  • 재사용이 필요할 때
    • 필드와 검증 로직이 다른 폼에서도 동일하게 사용될 수 있는 경우
• 폼 전체 단위 응집도를 선택하면 좋을 때
  • 단일 기능을 나타낼 때
    • 모든 필드가 밀접하게 관련되어 하나의 완결된 기능을 구성하는 경우
    • 결제 정보나 배송 정보처럼 모든 필드가 하나의 비즈니스 로직을 이룰 때 유용
  • 단계별 입력이 필요할 때
    • Wizard Form과 같이 스텝별로 동작하는 복잡한 폼의 경우
    • 회원가입이나 설문조사처럼 이전 단계의 입력값이 다음 단계에 영향을 주는 경우
  • 필드 간 의존성이 있을 때
    • 여러 필드가 서로를 참조하거나 영향을 주는 경우
    • 비밀번호 확인이나 총액 계산처럼 필드 간 상호작용이 필요한 경우

---

4. 결합도

A. 책임을 하나씩 관리하기

• 쿼리 파라미터, 상태, API 호출과 같은 로직의 종류에 따라서 함수나 컴포넌트, Hook을 나누지 말 것

B. 중복 코드 허용하기

• 다소 반복되어 보이는 코드일지 몰라도, 중복 코드를 허용하는 것이 좋은 방향일 수 있다.

C. Props Drilling 지우기

• Props Drilling은 부모 컴포넌트와 자식 컴포넌트 사이에 결합도가 생겼다는 것을 나타내는 명확한 표시이다.
• 만약 Drilling되는 프롭이 변경되면, 프롭을 참조하는 모든 컴포넌트가 변경되어야 한다.
• 조합(Composition) 패턴을 활용해 Props Drilling을 제거한다.

---

기타. 도움된 정보

1. 속성 접근자

• 객체 뒤에 [] 대괄호를 사용하면 대괄호 안에 들어있는 값을 키로 사용하여 해당 객체의 속성을 가져올 수 있음

function Page() {
  const user = useUser();
  const policy = {
    admin: { canInvite: true, canRead: true },
    viewer: { canInvite: false, canRead: true },
  }[user.role];

  return (
    <div>
      <Button disabled={!policy.canInvite}>Invite</Button>
      <Button disabled={!policy.canRead}>Read</Button>
    </div>
  );
}

2. 조합 패턴

• 컴포넌트의 재사용성과 유연성을 극대화하기 위해, 컴포넌트를 다른 컴포넌트에 조합하여 사용하는 설계 방식

function ItemEditModal({ open, items, recommendedItems, onConfirm, onClose }) {
  const [keyword, setKeyword] = useState("");

  return (
    <Modal open={open} onClose={onClose}>
      <div style={{ display: 'flex', justifyContent: 'space-between' }}>
        <Input
          value={keyword}
          onChange={(e) => onKeywordChange(e.target.value)}
        />
        <Button onClick={onClose}>닫기</Button>
      </div>
      <ItemEditList
        keyword={keyword}
        items={items}
        recommendedItems={recommendedItems}
        onConfirm={onConfirm}
      />
    </Modal>
  );
}

 

---

 

해당 글을 읽으며, 현재 내가 작성하고 있는 코드에 안좋은 코드 예시로 든 것과 같은 코드가 얼마나 많은지..

Props Drilling이나 매직넘버 그리고 파일 구조도 코딩을 하면서 굉장히 불편하다고 느꼈는데 천천히 리팩토링을 하는 시간을 가져야겠다는 생각을 했다. 

 

글의 양이 많지 않아서 단시간에 읽을 수 있었는데 이제부터 코딩을 할 때 오늘 봤는 내용들을 두고두고 상기시키면서 유지보수하기 좋은 코드를 작성할 수 있게 노력해야겠다.