•
Why
◦
사용자가 인지하는 단위(화면·행동)가 코드에 반영되면 패턴 기반 덩어리가 되어 인지적인 탐색 비용이 감소한다.
◦
문서와 코드가 멀어지면 “이 코드가 뭘 해결하는지” 기억 부하가 커져 추론 실수가 잦다.
•
How
1.
구현 전, 요구사항 문서를 훑으며 머릿속에 간략한 흐름 모델을 만든다.
•
ex. “음, 목록 페이지에서 시작해서, 데이터 보이고, 상세에서 상품 담아서, 구매하고, 확인 페이지 갔다가, 원래 페이지로 돌아오는구나”
2.
구현 시, 최대한 문서에 기반한 용어를 활용하여 변수, 타입, 컴포넌트 이름을 결정한다.
•
ex. 카테고리 → category
3.
리팩토링 단계에서, 문서와 코드를 나란히 놓고 위에서 아래로 훑으며 코드가 글처럼 문서 그대로 읽히는지 확인한다. 혹은 함수나 컴포넌트의 이름에 대해 내부 구현이 그렇게 읽히는지도 확인해본다.
•
ex. 카테고리 페이지니까 → 카테고리 데이터를 받아서 → 카테고리 목록을 보여주는데 → 각 목록을 클릭하면 탭 전환이 되고 → …
•
ex. 각 컴포넌트 사이에는 구분자가 있네? 컴포넌트는 Seperated 될건데, 무엇에 의해서? Seperator에 의해서 → <Seperated by={<Seperator />}
4.
‘뜬금없이 소리치는 친구’가 발견된다면 별도로 분리한다.
•
ex. 근데 요구사항에는 없는데 useNavigate가 갑자기 왜 나와?
•
Expectation
◦
상황 인식: 파일 구조가 문서 목차와 어긋나면 즉시 불일치를 감지.
◦
패턴 매칭: “문서-코드 한 덩어리” 원칙이 떠오름.
◦
자동 대응: 문서-코드 덩어리에 맞게 코드의 단위를 조정한다.
•
Caution
◦
‘뜬금없이 소리치는 친구’ 라는 것은 무엇인가?
▪
SRP를 위반하는 것에 가까운 코드, 혹은 낮은 응집을 유발하는 코드라고 설명할 수도 있을 것이다. 하지만 이러한 설명은 추상적이니 기존에 우리가 가지고 있는 상식적인 감각을 활용하는 것으로 이해하면 좋다.
▪
각자가 생각하는 ‘뜬금없이 소리치는 친구’에 대해 의견을 나누어 보면 좋을 것이다.
