노트변경하기 쉬운 프런트엔드 코드
Frontend Fundamentals
프런트엔드#refactoring · 연결된 개념 13개
쉽게 말하면
Frontend Fundamentals는 좋은 코드를 고치기 쉬운 코드로 보는 가이드예요. 읽기 쉬운지, 이름만 보고 동작이 짐작되는지, 함께 바뀌는 게 모여 있는지, 고쳤을 때 번지는 범위가 좁은지 네 가지로 따져요.
비유가 깨지는 곳 네 기준을 한꺼번에 만점으로 만들 순 없어요. 중복을 없애려고 성급하게 공통화하면 결합이 커지는 것처럼 서로 부딪치니, 상황마다 무엇을 우선할지 고르는 게 핵심이에요.
Frontend Fundamentals는 "좋은 프런트엔드 코드 = 변경하기 쉬운 코드"라는 관점에서 가독성(Readability)·예측 가능성(Predictability)·응집도(Cohesion)·결합도(Coupling) 네 기준과 구체적인 기법을 정리한 공개 가이드다. 네 기준은 서로 부딪치기도 해서 상황에 맞게 무엇을 우선할지 고르는 것이 핵심이다.
가독성: 한 번에 머릿속에 둘 맥락을 줄인다
- 같이 실행되지 않는 코드는 분리한다(권한별로 완전히 다른 화면이면 컴포넌트를 나눔)
- 구현 세부는 래퍼 컴포넌트나 훅 뒤로 숨긴다
- 복잡한 조건과 숫자에 이름을 붙인다(변수 추출하기, 매직 넘버와 설명 상수)
- 위에서 아래로 읽히게 한다. 중첩 삼항 연산자(Nested Ternary Operator) 대신 if 문으로 펼친다(조건문 분해·통합)
예측 가능성: 이름·매개변수·반환값만 보고 동작을 안다
- 같은 이름이 다른 동작을 하지 않게 한다(언어적 안티패턴)
- 같은 종류의 함수(예: 쿼리 훅들)는 반환 타입을 통일한다
- 숨은 부수 효과를 드러낸다. 데이터 요청 함수 안에서 몰래 로그를 남기지 말고 호출하는 쪽에서 한다(명령-질의 분리, 최소 놀람의 원칙)
응집도: 함께 바뀌는 코드는 함께 둔다
- 함께 수정되는 파일은 같은 디렉터리에 둔다. 종류별(components/hooks)보다 기능별로 묶는다(응집도)
- 폼은 필드 단위(독립 검증·재사용)와 폼 전체 단위(필드 간 의존, 단계별 입력) 중 상황에 맞는 응집을 고른다
결합도: 바꿨을 때 영향 범위를 좁힌다
- 한 훅이나 컴포넌트가 책임을 하나씩만 가진다
- 중복을 허용한다. 서로 다르게 바뀔 코드를 성급하게 공통화하면 오히려 결합이 커진다(3의 법칙, DRY 원칙)
- prop drilling은 조합이나 Context로 없앤다(결합도)
출처: Frontend Fundamentals - 좋은 코드를 위한 4가지 기준
연결된 개념
이 노트를 가리키는 문서
뜻이 가까운 노트
- 마이크로 프론트엔드
마이크로 프론트엔드는 하나의 큰 프론트엔드 앱을 기능별 조각으로 나눠, 팀마다 따로 개발·배포하고 런타임에 하나의 화면으로 조립하는 아키텍처다. 백엔드의 마이크로서비스(microservices) 발상을 프론트엔드로 가져온 것이다.
- 코드 냄새
당장 버그는 아니지만 이해나 변경 비용을 높이는 구조적 신호. 리팩터링을 언제 시작하고 멈출지에 정확한 공식은 없어서, 냄새라는 어휘로 직관을 공유한다.
- 집단 코드 소유
코드의 주인을 개인으로 두지 않고 팀 전체가 코드베이스 전체를 소유해, 누구나 필요한 곳을 고칠 수 있게 하는 XP 실천법.
- 구성요소 줄이기
셀 수 있는 모든 구성요소(파일, 폴더 깊이, 클래스, 함수, 분기, 변수, 테이블, 필드, 테스트 케이스…)는 비용이라는 관점. 심플 디자인의 네 번째 규칙을 실무 기준으로 풀어낸 것이다.
- 기본형 집착
전화번호·금액·우선순위 같은 도메인 개념을 끝까지 문자열이나 숫자로만 다루는 냄새. 같은 검증과 포맷 코드가 여기저기 반복되고, 문자열로 모든 걸 표현하는 "stringly typed" 코드가 된다.