•
Why
◦
결합은 ‘서로 다른 요소들이 얼마나 독립적으로 존재할 수 있나’라는 문장으로 표현할 수 있음. 결합도가 높다면 각자의 변경이 서로에게 영향을 미쳐 변경에 불리해질 수 있다.
◦
도미노 효과: 한 파일에 작은 변경을 가해도 연쇄적으로 다른 모듈까지 수정해야 한다.
◦
검증 난이도 상승: 외부 의존성 주입이 어려워 단위 테스트가 거칠어지고 회귀 버그가 숨어든다.
◦
업무 복잡도 증가: “이 함수가 왜 라우터를 직접 호출하지?”처럼 서로 다른 개념이 뒤엉켜 개발자 작업 기억을 소모한다.
•
How
1.
검토하고자 하는 모듈을 새 파일에 복사한다.
•
ex. 테스트 코드를 작성하는 상황
2.
해당 모듈이 정상 동작하기 위해 필요한 요소들을 목록화 한다. 특히, 결합도를 침습적 요소들에 주목한다.
•
"침습적"은 의료 용어에서 온 표현으로, 원래는 몸속 깊이 침투하는 시술을 뜻한다. 코드에서는 한 번 들어오면 전체를 지배하는 요소를 의미한다.
•
ex. useLoaderData, useQuery 등으로 인해 스마트 컴포넌트가 됨, 페이지 단위 로직이 침투함, 추상화의 누출, …
3.
해당 모듈이 독립적이지 못하도록 만드는 외부 의존성을 제거하는 방법에 대해 최대한 여러가지 종류의 아이디어를 내어본다.
•
ex. 의존성 주입? 구체 대신 추상에 의존? 이벤트로 분리, …
4.
해당 개선책을 적용하고 난 뒤의 결과물을 새 파일에 복사해보고 개선 전 파일과 비교해본다.
•
Expectation
◦
상황 인식: "이 컴포넌트 다른 프로젝트에 복사했더니 import 에러가 15개...” "Button 컴포넌트 하나 쓰려는데 왜 전체 상태관리를 알아야 하지?"
◦
패턴 매칭: "아, useNavigate를 컴포넌트 깊숙이 쓰면 안 되는구나" "API 호출은 페이지에서 하고 props로 내려주는 게 맞구나" "이 컴포넌트가 너무 많은 걸 알고 있네"
◦
자동 대응: 침습적인 외부 의존성을 컴포넌트에 덥석 추가하여 얽힘을 만들지 않고, 콜백 함수나 인터페이스 형태로 결합을 낮추는 선택을 함.
