카테고리 없음

공용 컴포넌트 설계 방법 도찰(📜Frontend Fundamentals 정리)

minnote29 2025. 1. 29. 02:45

 


변경하기 쉬운 프론트엔드 코드를 위한 지침서
공용 컴포넌트를 만들기 위해 frontend fundamentals를 참고했다. 유용해보여서 따로 정리해보고자 한다.

 

변경하기 쉬운 코드

좋은 프론트엔드 코드는 변경하기 쉬운 코드. -> 코드 변경을 쉽게 하기 위한 4가지 기준

 

#1 가독성

  • 코드가 읽기 쉬운 정도. 쉽게 변경하기 위해 어떤 동작을 하는지 이해하는 게 필요하다.
  • 코드 flow가 자연스러워야 한다.
  • 전략 => 중복 지양해야 한다. 
    • 맥락 줄이기: 같이 실행되지 않는 코드를 분리하고, 구현 상세를 추상화하고, 로직 종류에 따라 합쳐진 함수를 쪼개야 한다.
    • 이름 붙이기: 복잡한 조건에 이름을 붙이고, 매직 넘버( 정확한 뜻을 밝히지 않고 소스 코드 안에 직접 숫자 값을 넣는 것 )에 이름을 붙여야 한다. ex) 숫자를 상수로 선언하기 
    • top-down 방식으로 읽히게 하기: 시점 이동( 코드를 읽을 때 코드의 위아래를 왔다갔다 하면서 읽거나, 여러 파일이나 함수, 변수를 넘나들면서 읽는 것 )을 줄이고, 삼항 연산자를 단순하게 해야 한다. 

 

#2 예측 가능성 

  • 함께 협업하는 동료들이 함수나 컴포넌트의 동작을 얼마나 예측할 수 있는지.
  • 일관된 규칙 따라야 한다.
  • 전략 => 3가지는 결국 다 연결된다.
    • 이름 겹치지 않게 관리: 같은 이름 쓰면 혼란 발생한다. -> 오류, 버그, 디버깅 문제 생길 수 있다.
    • 같은 종류의 함수는 반환 타입 통일하기: api 호출과 관련된 훅들처럼 같은 종류의 함수..서로 다른 반환 타입을 가지면 일관성 유지가 어렵다.
    • 숨은 로직 드러내기: 함수나 컴포넌트의 이름, 파라미터, 반환 값에 드러나지 않는 숨은 로직이 존재해도 혼란이 온다.

 

#3 응집도

  • 수정되어야 할 코드가 항상 같이 수정되는지.
  • 특정 코드/요소가 여러 컴포넌트에서 사용된다고 해도 함께 수정되어 적용되어야 한다.
  • 응집도를 높이면 변수나 함수를 추상화하는 등 가독성을 떨어뜨리는 결정을 해야 한다. -> 위험성 높은 경우는 응집도를 우선! 위험성이 높지 않으면, 가독성을 우선해서 코드 중복 허용!
  • 전략
    • 함께 수정되는 파일을 같은 디렉토리에 두기: Hook, 컴포넌트, 유틸리티 함수 등을 여러 파일로 나누어서 관리하는데, 이런 파일들을 쉽게 만들고, 찾고, 삭제할 수 있도록 올바른 디렉토리 구조를 갖추는 것이 중요하다. 함께 수정되는 소스 파일을 하나의 디렉토리에 배치하면, 참조하면 안 되는 파일 참조를 막고, 연관된 파일 한 번에 삭제 가능하다. 
    • 매직 넘버 없애기: 
    • 폼의 응집도 생각하기: Form으로 사용자에게 값을 입력받아야 하는 경우가 많은데, 이 경우 2가지의 방법으로 응집도를 관리. 
      1. 필드 단위 응집도: 개별 입력 요소를 독립적으로 관리하는 방식. 각 필드가 고유의 검증 로직을 가지므로 변경이 필요한 범위가 줄어들어 특정 필드의 유지보수가 쉬워진다. -> 다른 필드에 영향 주지 않음. 
      2. 폼 전체 단위 응집도: 모든 필드의 검증 로직이 폼에 종속되는 방식. 폼 전체에서의 흐름을 고려하여 설계되며, 변경 단위가 폼 단위로 발생할 때 고려한다. 검증이 한 곳에서 관리되어 로직이 간결해지고, 상태가 중앙 집중식으로 관리되어 전체 흐름을 이해하기 쉬워진다. 필드 간의 결합도가 높아지므로 폼의 재사용성은 떨어질 수 있다.

 

#4 결합도

  • 코드를 수정했을 때의 영향범위.
  • 영향범위 적을수록 좋다. -> 예측 가능.
  • 전략
    • 책임을 하나씩 관리하기: 쿼리 파라미터, 상태, API 호출과 같은 로직의 종류에 따라서 함수나 컴포넌트, Hook을 나누면, 한 번에 다루는 맥락의 종류가 많아져서 이해하기 힘들고 수정하기 어렵다.
    • 중복 코드 허용하기: 여러 페이지나 컴포넌트에 걸친 중복 코드를 하나의 Hook이나 컴포넌트로 공통화하는 경우가 많은데, 중복 코드를 하나의 컴포넌트나 Hook으로 공통화하면, 좋은 코드의 특징 중 하나인 응집도를 챙겨서, 함께 수정되어야 할 코드들을 한꺼번에 수정할 수 있다. -> 불필요한 결합도 발생. 영향을 받는 코드의 범위가 넓어져서, 오히려 수정이 어려워질 수도..처음에는 공통화시켜도 이후에 특정 요구사항으로 인해 점점 복잡해질 수 있다. 
    • Props Drilling 지우기: 부모 컴포넌트와 자식 컴포넌트 사이에 결합도가 생겼다는 것을 나타내는 명확한 표시. 만약에 Drilling되는 프롭이 변경되면, 프롭을 참조하는 모든 컴포넌트가 변경되어야 함.-> 참고. 조합(Composition) 패턴은 단순히 Props를 전달하는 문제를 줄이는 것을 넘어, 불필요한 중간 추상화를 제거하여 개발자가 컴포넌트의 역할과 의도를 명확히 이해할 수 있도록 도와준다.

 

Frontend Fundamentals