1. 세션 요약 - 빈칸 채우기
(기본 원칙) 코드는 _______처럼 읽혀야 하며, _______과 _______가 자연스럽게 매칭되어, _______에서 _______로 흐르듯 읽혀야 한다.
(’코드가 글처럼 읽히게 하기’ 패턴 전문가 6단계)
1.
구현 전, 요구사항 문서를 훑으며 머릿속에 _______ 형태'에 대한 간략한 흐름 모델을 만든다.
2.
문서와 코드를 나란히 놓고 컴포넌트의 이름을 중심으로 '_______에서 _______로' 훑으며 읽히는지 확인한다.
3.
'_______ 소리치는 요소'들이 발견되면 리팩토링 트리거로 삼는다.
4.
바람직한 형태에 가깝게 컴포넌트와 로직을 _______한다.
5.
'바람직한 _______ 먼저' 작성하고, 동작과 책임이 _______를 따르도록 한다.
6.
처음부터 읽어보며 _______가 내려갔는지 점검한다.
2. 세션 목표
개발을 하다보면 코드를 읽는 시간이 쓰는 시간보다 10배는 더 많습니다
•
복잡한 함수를 이해하기 위해 여러 파일을 오가며 '해독'하는 시간이 너무 길어집니다
•
요구사항과 코드가 매칭되지 않아 수정할 때마다 예상치 못한 부분이 깨집니다
•
팀원들이 작성한 코드를 이해하기 어려워 협업 효율이 떨어집니다
이번 세션에서 다루는 내용을 잘 이해하면,
•
복잡한 로직도 단순하게 작성할 수 있게 됩니다
•
함수와 컴포넌트의 인터페이스만으로 동작을 예측할 수 있어 시점 이동이 줄어듭니다
•
요구사항 문서와 코드가 1:1로 매칭되어 변경사항 반영이 쉬워집니다
•
팀원 누구나 쉽게 이해할 수 있는 자명한 코드를 작성할 수 있게 됩니다
3. 인접 개념
•
글처럼 읽히는 코드는 → ‘시점 이동 줄이기’의 조건도 만족하게 됨
•
가독성 - 
시점 이동 줄이기
시점 이동 줄이기•
응집도 - 함께 수정되는 파일을 같은 디렉토리에 두기
함께 수정되는 파일을 같은 디렉토리에 두기•
단일 책임 원칙(SRP)
•
제어의 역전(IoC)
4. 멘탈 모델 & 시각화 자료
[요구사항 문서]
↓
[머릿속 모델 구성]
↓
[코드 읽기 시작]
↓
[위에서 아래로 흐름]
↓
예상과 일치? ──No──→ [리팩토링 트리거]
↓ Yes ↓
[다음 섹션] [재조정 & 분리]
↓ ↓
완료 [다시 읽기]
TypeScript
복사
// ❌ 뜬금없는 요소들
function PostEditor() {
const isLogin = useSearchParams().get('token'); // 왜 갑자기 로그인?
const navigate = useNavigate(); // 에디터인데 왜 네비게이션?
// ...
}
// ✅ 예측 가능한 요소들
function PostEditor({ value, onSave, onCancel }) {
const [title, setTitle] = useState('');
const [content, setContent] = useState('');
// 에디터와 관련된 것들만
}
TypeScript
복사
5. ‘코드가 글처럼 읽히게 하기’ 패턴이란?
요구사항 문서를 읽듯이 코드를 위에서 아래로 자연스럽게 읽을 수 있으며, 함수와 컴포넌트의 이름만으로 동작이 예측되는 코드
코드를 '해독'하는 것이 아니라 '읽는' 것이 가능하며, 요구사항과 코드가 1:1로 매칭되어 인지 부하를 최소화합니다.
•
선형적으로 이어지는 코드 읽기의 흐름
◦
코드가 위에서 아래로 자연스럽게 읽히면서, 시점 이동이 최소화되고 논리적인 흐름을 유지
•
예측 가능한 인터페이스
◦
네이밍이 일반적인 관례를 따르며, 인터페이스가 명확하여 동작을 예측할 수 있음
◦
관련도가 높은 코드끼리 모아두며, 각 모듈은 하나의 책임만 가짐
•
요구사항과 코드의 1:1 매칭
◦
문서나 디자인에서 사용하는 비즈니스 용어와 분기 등을 가급적 그대로 사용하며, 자의적 추상화나 용어의 발명을 지양함
6. 예시 코드
7. 전문가들의 패턴 적용
7-1. 미니 과제 - Before
7-2. 전문가 영상
1.
구현 전, 요구사항 문서를 훑으며 머릿속에 ‘바람직한 형태’에 대한 간략한 흐름 모델을 만든다.
•
ex. “음, 목록 페이지에서 시작해서, 데이터 보이고, 상세에서 상품 담아서, 구매하고, 확인 페이지 갔다가, 원래 페이지로 돌아오는구나.”
•
ex. “음, Editor 페이지에서 보여야 하는게 타이틀 하나, Select 두 개, Input 하나, 위지윅 에디터랑 버튼이구나.”
2.
문서와 코드를 나란히 놓고 검토하고자 하는 ‘컴포넌트의 이름’을 중심으로 ‘위에서 아래로’ 훑으며 코드가 문서 그대로 읽히는지 확인한다. 함수의 인터페이스나 컴포넌트의 이름에 대해서도 자연스럽게 읽히는지도 동일하게 확인한다.
•
ex. (컴포넌트 구성) 카테고리 페이지니까 → 카테고리 데이터를 받아서 → 카테고리 목록을 보여주는데 → 각 목록 아이템 컴포넌트에는 버튼이 있고 → …
•
ex. (컴포넌트 이름, 인터페이스) 각 컴포넌트 사이에는 구분자가 있네? 컴포넌트는 Seperated 될건데, 무엇에 의해서? Seperator에 의해서 → <Seperated by={<Seperator />}
3.
만약 읽어내려가면서 기대한 내용이 나오지 않거나, 예상한 내용보다 다른 내용들이 더 중심이 되는거 같다고 느껴지거나, ‘뜬금없이 소리치는 요소’들이 발견된다면 리팩토링 트리거로 삼는다.
•
ex. 근데 요구사항에는 이동하라는 문구가 없는데 useNavigate가 갑자기 왜 나와?
•
ex. useProductCalucateItem()이 뭐야?
•
ex. 게시물 등록 컴포넌트인데 isEdit이 왜 나와?
•
‘뜬금없이 소리치는 요소’란?
◦
함수의 이름이나 인터페이스를 보고 동작이 예상되지 않아, 한번 더 생각하게 하는 코드.
▪
이 경우 결국 함수 안쪽을 들여다 보아야 하기 때문에 ‘시점 이동’으로 인한 비효율이 발생한다.
◦
요구사항을 읽고 기대했던 내용이 아닌데 등장한 코드.
▪
이 경우 현재 검토 중인 컴포넌트 외 다른 컴포넌트의 구현 세부사항일 가능성이 높다.
4.
구현 전 떠올렸던 바람직한 형태에 가깝게 컴포넌트와 로직을 재조정(ex. 분리 or 역으로 노출)한다.
•
응집:
◦
특정 함수나 컴포넌트에 대해 “이 함수 / 컴포넌트는 _____ 을 한다” 라는 한 줄을 적어본다. 도저히 ‘그리고’를 빼고는 설명할 수 없거나 2) 파라미터로 넘겨지는 값에 일관성이 없고 번잡하다면 분리를 고려한다.
◦
컴포넌트에 props로 전달되는 리모트 데이터가 굳이 외부에 있을 필요가 없다면 호출하는 곳을 사용처와 가깝게 내부로 옮겨 응집도를 높인다.
•
인터페이스:
◦
수정하기 쉬운가? (제품의 성장과 변경에 유연하게 대응할 수 있나? = 적절한 선언 레벨을 따르는가)
◦
인터페이스만 보고도 동작이 예측되는가? (시점 이동을 유발하지는 않나?)
◦
네이밍이 일반적인 관례(ex. 웹 표준)에 가깝도록 작성한다(ex. value, onChange, onSelect, min, max, …)
◦
제어의 역전(IoC) 개념을 적절히 활용하고 있는가? (함수와 컴포넌트가 동작을 적절히 외부에 위임하고 있는가)
▪
ex. 세부 동작을 컴포넌트 내부에서 정의하지 않고 callback 함수로 외부에서 받도록 함
▪
ex. children prop을 통해 컴포넌트를 외부에서 전달받기
◦
함수의 경우 전달되는 인자의 갯수가 2~3개를 넘지 않도록 하고, 인자의 순서가 첫 번째에 가까울 수록 함수의 핵심적인 요소( 마지막 요소는 부수적인 옵션)를 반영할 수 있도록 한다.
마지막 요소는 부수적인 옵션)를 반영할 수 있도록 한다.•
요구사항(비즈니스):
◦
요구사항(ex. 기획, 디자인)에서 표현된 개념들이 코드에 적절히 표현되어 있는가
◦
개발자가 자의적인 단위로 추상화 하고 있지 않는가? (컴포넌트의 일부에 변경이 생겨 분기 플래그를 넣을 가능성을 고려하였는가?)
•
주의 사항:
◦
한번에 하나씩만 해야 한다.
▪
리팩토링 과정에서는 절대 기능을 수정하면 안 된다. 리팩토링 하기로 한 요소 하나에만 집중한다. 예를 들면, 코드를 분리할 때는 반드시 코드를 분리하는 것에만 집중해야 하고, 동시에 변수명을 고치거나 다른 쪽의 구조를 개선해서는 안 된다.
5.
옮겨담는 과정에서 함수와 컴포넌트의 구현보다 ‘바람직한 인터페이스 먼저’ 작성하고, 동작과 책임이 인터페이스를 따르도록 한다.
•
인터페이스를 작성하는 단계에서 적절한 형태가 만들어지지 않는다면 4번으로 되돌아간다.
6.
다시 처음부터 읽어보며 처음 기대했던 형상대로 코드가 작성되었는지 확인하고, 최종적으로 인지부하가 내려갔는지 점검한다.
•
컴포넌트가 글처럼 읽히도록 잘 구성되었다면, 해당 컴포넌트나 함수의 스토리라인이 그려져야 한다.
•
여전히 인지부하가 높다면, 충분히 정리되지 않았거나 잘못 정리된 것이다.
7-3. 미니 과제 - After
8. Wrap-up
(기본 원칙) 코드는 글처럼 읽혀야 하며, 요구사항과 코드가 자연스럽게 매칭되어, 위에서 아래로 흐르듯 읽혀야 한다.
(’코드가 글처럼 읽히게 하기’ 패턴 전문가 6단계)
1.
구현 전, 요구사항 문서를 훑으며 머릿속에 바람직한 형태'에 대한 간략한 흐름 모델을 만든다.
2.
문서와 코드를 나란히 놓고 컴포넌트의 이름을 중심으로 ‘위에서 아래로' 훑으며 읽히는지 확인한다.
3.
'뜬금없이 소리치는 요소'들이 발견되면 리팩토링 트리거로 삼는다.
4.
바람직한 형태에 가깝게 컴포넌트와 로직을 재조정한다.
5.
'바람직한 인터페이스 먼저' 작성하고, 동작과 책임이 인터페이스를 따르도록 한다.
6.
처음부터 읽어보며 인지부하가 내려갔는지 점검한다.