안녕하세요! 그로스로그 입니다!😊 🌱
여러 장을 한 장으로, 여러 줄을 몇 줄로, 여러 개를 하나로. 2기 7회차 세 편입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 지난 기수의 성장일지를 다시 읽으면서, 그때 소개해드리지 못한 글을 하나씩 꺼내고 있습니다.
2기 7회차, 2024년 겨울로 들어서던 무렵입니다. 이번 회차에는 줄이는 일을 다룬 세 편이 모였어요. 개념을 줄이고, 반복을 줄이고, 상태를 줄입니다.
01
🌲 트리 정리
김영진 님
자료구조 과목의 트리 단원 전체를 한 장으로 압축한 정리 노트입니다.
기본 용어에서 시작해 쓰레드트리, 힙, 승자·패자트리, 숲, 이진탐색트리, Splay, AVL, BB, m원탐색트리, B계열, 2-3트리, 2-3-4트리, 레드블랙트리까지 열다섯 가지 넘는 트리가 순서대로 늘어섭니다.
대부분은 정의 한 줄인데, 삽입과 삭제만은 절차를 통째로 적어뒀어요.
이분의 자료구조 정리는 원래 회차별로 나뉘어 있었습니다. 같은 블로그에 「7. 트리」, 「8. 스레드 트리 9. 우선순위큐, 힙」, 「10.선택트리, 숲, 이진트리개수 11.이진탐색트리(BS),Splay,AVL,BB」, 「12,13 멀티웨이 탐색 트리」가 각각 올라와 있어요. 그 여러 편을 한 장으로 다시 모은 글이 이겁니다.
조금 더 들어가 보면
📏 정의부터 다시 세운다
글의 첫 네 줄이 용어 정의입니다.
트리의 차수: 트리가 가지고 있는 노드의 차수 중 가장 큰 값
루트의 레벨 : 1
트리의 높이: 트리가 가진 최대 레벨
"차수"라는 같은 단어가 노드에 붙을 때와 트리에 붙을 때 다르다는 걸 나란히 적어뒀습니다.
이게 시험에서 자주 틀리는 지점이에요. 노드의 차수는 그 노드 하나만 보면 되는데, 트리의 차수는 전체를 훑어 가장 큰 값을 찾아야 하거든요. 같은 단어인데 보는 범위가 다릅니다.
"루트의 레벨: 1"도 짧지만 필요한 줄입니다. 책마다 루트를 0으로 두기도 하고 1로 두기도 하는데, 어느 쪽 기준으로 적었는지를 미리 못박아둔 것이니까요. 이게 없으면 뒤에 나오는 높이 계산이 한 칸씩 어긋납니다.
🪜 트리가 늘어선 순서
열다섯 가지가 나열되어 있는데, 순서에 흐름이 있습니다.
먼저 순회를 빠르게 하려는 시도가 나옵니다. 쓰레드트리요.
이진트리를 순회하려면 보통 스택이 필요한데, 비어 있는 포인터 자리에 다음에 갈 노드를 미리 적어두면 스택 없이도 순회할 수 있습니다. 남는 공간을 활용한 아이디어예요.
그다음은 최댓값을 빨리 꺼내려는 시도입니다. 힙이요. 그리고 힙에서 자연스럽게 승자트리·패자트리로 이어집니다.
패자트리 — 각 노드가 두 자식 노드의 큰 값(패자)이며 최종 승자는 0번 노드에 저장
여기서 앞에 나온 합병정렬 정의와 이어집니다. "차례로 정렬한 데이터 리스트 k개를 완전한 순서를 유지하는 하나의 리스트로 만드는 과정"이요. k개 리스트의 맨 앞 값들 중 가장 작은 걸 반복해서 꺼내야 하는데, 그걸 트리로 만들면 매번 전체를 뒤지지 않아도 됩니다.
그다음이 찾기를 빠르게 하려는 시도입니다. 이진탐색트리요. 그런데 이진탐색트리는 한쪽으로 치우치면 느려지죠. 그래서 균형을 잡는 트리들이 뒤따릅니다. Splay, AVL, BB요.
마지막이 디스크를 덜 읽으려는 시도입니다. m원탐색트리와 B계열이요.
한 노드에 자식을 많이 두면 트리 높이가 낮아지고, 높이가 낮으면 디스크를 덜 읽습니다. 데이터베이스 인덱스가 B계열을 쓰는 이유예요.
정의만 나열된 것 같은데, 읽어보면 "무엇을 빠르게 하려고 만든 트리인가"로 묶입니다.
✍️ 삽입·삭제만 절차로 적은 이유
이 노트에서 분량이 확 늘어나는 대목이 딱 두 군데입니다. 힙의 삽입·삭제, 그리고 이진탐색트리의 삽입·삭제요.
힙 삭제 설명이 특히 꼼꼼합니다.
루트노드 (1번인덱스) 자식노드(2번인덱스, 3번인덱스)부터 아래로 내려가면서 temp값과 비교한다
temp값이 자식노드중 큰값보다 더 작다면 자식노드중 큰값을 부모로 올린다
temp값이 자식노드중 큰값보다 크다면 그 부분이 temp의 적정 위치이므로
그리고 마지막에 한 문장으로 다시 묶습니다.
절차를 다 적고, 그 절차가 결국 뭘 하는 건지 한 줄로 요약했어요.
왜 이 부분만 길까요. 나머지는 정의를 알면 되지만, 삽입·삭제는 손으로 따라 그려봐야 하는 것이기 때문입니다. AVL트리가 무엇인지는 한 줄로 외울 수 있어도, 힙에서 값을 하나 빼면 트리가 어떻게 재배치되는지는 한 줄로 안 되죠.
이진탐색트리 삭제도 마찬가지로 세 경우로 나눠 적었습니다. 단말노드일 때, 서브트리가 하나일 때, 둘 다 있을 때요. 마지막 경우가 제일 까다로운데, 글이 실제로 쓰는 방법 하나를 골라 끝까지 적었습니다.
"~한다고 하면"이라고 조건을 걸고 하나만 끝까지 따라간 게 좋습니다. 두 방법을 모두 어중간하게 적는 것보다 훨씬 쓸모 있어요.
📝 원문에서는 이렇게 씁니다
이 노트에는 설명하는 문장이 거의 없습니다.
"~입니다"체가 아니라 "~하는 것", "~인 트리" 같은 명사형으로 끝나고, 예시나 비유도 없어요. 남에게 보여주려고 쓴 글이 아니라 자기가 다시 읽으려고 쓴 글입니다.
그런데 그래서 밀도가 높습니다. 열다섯 가지 트리가 스크롤 몇 번 안에 다 들어와요. 시험 직전에 필요한 건 설명이 아니라 이 밀도입니다.
앞선 회차의 글들이 「8. 스레드 트리 9. 우선순위큐, 힙」처럼 진도 단위로 나뉘어 있었다는 점과 대비됩니다. 진도 노트는 배우는 순서대로 쌓이는데, 그 순서는 다시 찾아볼 때의 순서와 다르거든요.
그래서 마지막에 한 장으로 다시 모았습니다. 쌓는 노트와 꺼내는 노트를 따로 만든 셈입니다.
큐레이터 노트
총정리를 따로 만들었다는 점에서 고른 글입니다.
공부 기록을 남기는 사람은 많은데, 대부분 진도별 노트에서 끝납니다. 학기가 끝나면 노트 열 개가 남는데, 정작 다시 볼 때는 열 개를 다 열어야 해요.
이분은 거기서 한 걸음 더 갔습니다. 여러 편에 흩어져 있던 트리 이야기를 한 장으로 다시 압축했어요. 이건 그냥 복사해 붙이는 작업이 아닙니다. 무엇을 남기고 무엇을 뺄지 정해야 하니까요.
그리고 뺀 기준이 일관됩니다. 정의는 남기고, 설명은 뺐고, 절차는 통째로 남겼습니다.
정리를 잘하는 것과 아는 것은 다른 일이라고들 하는데, 무엇을 뺄지 정하려면 결국 알아야 합니다.
02
⏭️ C언어 기초 기타 제어문
전일수 님
C의
break와 continue를 다룬 글입니다.각각에 정의 → 사용 사례 → 예제를 붙였는데, 사례를 쓰이는 자리별로 나눴어요.
break는 반복문·switch·중첩 반복문 세 자리, continue는 for·while·do-while·중첩 반복문 네 자리요.마지막에 네 항목짜리 비교표로 둘을 갈라둡니다.
2·4·5회차에서도 이분의 C 연재를 소개해드렸습니다. 선행처리기, 연산자, 선택 제어문에 이어 이번엔 기타 제어문이에요. 5회차에서 예고편처럼 짚었던 switch의 break가 여기서 정면으로 다뤄집니다.
조금 더 들어가 보면
🚪 가장 가까운 것만
두 제어문의 정의에 똑같은 표현이 반복해서 나옵니다.
break는 또한 중첩된 반복문에서 가장 가까운 반복문만 종료합니다.continue 문은 가장 가까운 반복문에서만 적용됩니다."가장 가까운"이 이 글의 핵심어입니다.
처음 배울 때 가장 많이 하는 오해가 이거예요. 이중 for문 안에서 break를 쓰면 둘 다 빠져나올 거라고 생각하는데, 안쪽 하나만 끝납니다. 바깥 반복문은 다음 회차를 그대로 시작해요.
글이 예제로 그걸 확인시킵니다. j == 2일 때 break가 실행되면 안쪽만 종료되고 바깥쪽은 계속 돈다고요.
이 규칙이 왜 이렇게 정해졌을까요. 어디까지 끊을지를 코드에 적을 방법이 없기 때문입니다. break 2;처럼 개수를 적는 언어도 있지만, C는 그런 문법을 두지 않았어요. 그래서 "가장 가까운 것"이라는 단순한 규칙 하나로 고정했습니다.
바깥까지 빠져나오고 싶으면 플래그 변수를 하나 두거나, 5회차에서 다룬 goto를 쓰거나, 아예 함수로 빼서 return을 씁니다. 규칙이 단순한 대신 우회로가 필요해진 셈이죠.
🔀 끝내기와 건너뛰기
두 제어문의 차이를 글이 이렇게 적었습니다.
break — 그 즉시 반복문을 종료하고, 반복문 이후의 코드로 제어가 넘어갑니다.continue — 그 이후의 코드는 실행되지 않고, 반복문의 조건을 평가하여 다음 반복이 시작됩니다."반복문 이후"와 "반복문의 조건". 제어가 어디로 가는지가 다릅니다.
여기서 짚어둘 게 하나 있습니다. continue가 조건을 평가하러 간다는 부분요. for문에서는 조건을 보기 전에 증감식을 먼저 실행합니다. 그래서 for (i=0; i<10; i++) 안의 continue는 안전해요.
그런데 while문에서는 증감식이 본문 안에 있죠. 본문 끝에 i++를 두고 중간에서 continue를 하면 증가를 건너뛰고 조건으로 갑니다. 같은 조건이 계속 참이니 무한루프가 되고요.
글이 for, while, do-while을 따로 나눠 예제를 붙인 이유가 여기 있습니다. 같은 continue인데 반복문 종류에 따라 다음에 실행되는 게 달라지거든요.
do-while도 마찬가지입니다.
do-while 문에서도 continue가 동일하게 동작합니다. continue가 실행되면 do-while 문에서 조건식을 다시 평가합니다.do-while은 본문을 먼저 실행하고 조건을 나중에 보는 구조라, continue가 본문 끝으로 뛰는 것처럼 동작합니다. "동일하게 동작한다"고 적었지만 실제로 뛰는 위치는 앞의 둘과 다른 자리예요.
📋 표 한 장으로 갈라두기
글 끝의 비교표가 네 줄입니다.
| 구분 | break | continue |
|---|---|---|
| 역할 | 반복문을 즉시 종료 | 현재 반복을 건너뛰고 다음 반복으로 |
| 사용 위치 | 반복문, switch 문 |
반복문 |
| 제어 흐름 | 반복문 또는 switch 문을 종료 |
현재 반복을 건너뛰고 다음 반복 진행 |
| 주로 쓰는 경우 | 반복문을 중단하고 싶을 때 | 일부 조건을 건너뛰고 싶을 때 |
두 번째 줄이 이 표에서 가장 실용적입니다. "사용 위치"요.
break는 switch에서도 쓰이는데 continue는 안 됩니다. 그래서 switch 안에 continue를 쓰면, 그건 switch를 빠져나가는 게 아니라 그 switch를 감싸고 있는 반복문의 다음 회차로 갑니다. 반복문 안에 switch가 있는 구조에서 실수하기 딱 좋은 자리예요.
5회차에서 이분이 switch의 break를 다뤘고, 이번 글이 break 자체를 다뤘습니다. 두 편이 이어져서 하나가 됩니다.
📝 원문에서는 이렇게 닫습니다
결론이 두 줄인데, 두 번째 줄에 판단 기준이 들어 있습니다.
break는 반복문을 완전히 종료하는 데 사용하고, continue는 반복문 내에서 조건에 맞지 않거나 불필요한 작업을 건너뛰고자 할 때 사용합니다."불필요한 작업을 건너뛰고자"가 정확한 표현입니다.
continue가 없어도 같은 코드를 짤 수 있어요. 조건을 뒤집어서 if 안에 본문 전체를 넣으면 되니까요. 그런데 그러면 들여쓰기가 한 겹 깊어집니다. 걸러낼 조건이 셋이면 세 겹이 되고요.
continue로 앞에서 걸러내면 본문이 들여쓰기 없이 평평하게 남습니다. "이건 넘어간다"를 위에 모아두고, 진짜 하려는 일은 아래에 두는 구조예요.
break도 비슷합니다. 찾으면 더 볼 필요가 없을 때 즉시 끝내는 것. 둘 다 "덜 하기 위한" 문법입니다.
큐레이터 노트
사례를 자리별로 쪼갠 게 이 글의 특징입니다.
break와 continue를 설명하는 글은 보통 예제 하나씩으로 끝납니다. 그런데 이 글은 break를 세 자리, continue를 네 자리로 나눠서 각각 예제를 붙였어요. 일곱 개의 경우를 따로 확인한 셈입니다.
문법 자체는 한 줄로 설명되는데, 어디에 놓느냐에 따라 결과가 달라지는 게 제어문입니다. 정의를 아는 것과 중첩 반복문에서 어떻게 되는지 아는 것은 다른 일이고요.
5회차 큐레이션에서 이분의 C 연재를 두고 "회차가 쌓이면 한 권의 노트가 된다"고 적었습니다. 이번 편의 앞뒤 글이 「C언어 기초 반복 제어문」과 「C언어 기초 함수의 개념과 표준함수」예요. 목차를 순서대로 밟고 있습니다.
03
🧺 여러 개의 state, handler를 하나로 만들기
이주희 님
리액트 폼에서 state 세 개와 핸들러 세 개를 각각 하나로 합치는 리팩터링 기록입니다.
바꾸기 전 코드와 바꾼 뒤 코드를 통째로 두 벌 올렸어요.
핵심은 한 줄입니다.
[name]: value — 입력칸의 name 속성을 그대로 프로퍼티 이름으로 쓰는 문법이요.3·4회차에서도 이분의 리액트 기록을 소개해드렸습니다. 매번 바꾸기 전후를 나란히 두는 방식이에요.
조금 더 들어가 보면
🧮 세 개가 하나로
바꾸기 전 코드에는 state가 셋이었습니다.
const [title, setTitle] = useState('');
const [rating, setRating] = useState(0);
const [content, setContent] = useState('');
핸들러도 셋이고요. handleTitleChange, handleRatingChang, handleContentChange. 하는 일은 전부 같습니다. 이벤트에서 값을 꺼내 해당 state에 넣는 것요.
바꾼 뒤에는 이렇게 됩니다.
const [values, setValues] = useState({
title: '',
rating: 0,
content: '',
});
객체 하나에 세 필드를 담았습니다. 초기값은 그대로 유지했어요. 문자열 둘은 빈 문자열, 별점은 숫자 0으로요.
글이 붙인 설명이 정확합니다.
state를 합치니까 핸들러도 따라서 합쳐집니다. 원인과 결과가 순서대로 적혀 있어요.
이게 왜 자연스러운가 하면, 핸들러가 셋이었던 이유가 넣을 곳이 셋이었기 때문이거든요. setTitle, setRating, setContent는 서로 다른 함수라 하나로 부를 수가 없습니다. 넣을 곳이 하나가 되면 함수도 하나면 됩니다.
🔑 [name]이 하는 일
합쳐진 핸들러가 이겁니다.
const handleChange = (e) => {
const { name, value } = e.target;
setValues((prevValues) => ({
...prevValues,
[name]: value,
// name의 값으로 프로퍼티명을 지정하고 : 해당하는 값을 지정해줄 수 있음
}));
}
대괄호가 붙은 [name]이 핵심입니다.
객체를 만들 때 { name: value }라고 쓰면 name이라는 이름의 프로퍼티가 만들어집니다. 그런데 { [name]: value }라고 대괄호를 씌우면, name 변수에 들어 있는 값이 프로퍼티 이름이 돼요. 변수에 'title'이 들어 있으면 { title: value }가 되는 겁니다.
그래서 입력칸마다 name="title", name="rating", name="content"를 달아두면, 어느 칸에서 이벤트가 와도 같은 함수가 알아서 맞는 자리에 넣습니다.
글이 붙인 주석이 이 문법을 정확히 짚었습니다. "name의 값으로 프로퍼티명을 지정하고".
여기서 생기는 변화가 하나 있습니다. HTML의 name 속성이 이제 필수가 됩니다. 전에는 입력칸마다 전용 핸들러가 붙어 있어서 name이 없어도 됐어요. 이제는 name이 빠지면 undefined라는 프로퍼티가 만들어집니다.
줄인 대신 규칙이 하나 생긴 것이죠. 이런 교환은 리팩터링에서 자주 나옵니다.
🧩 prevValues를 펼치는 이유
setValues 안에 두 가지가 겹쳐 있습니다.
setValues((prevValues) => ({
...prevValues,
[name]: value,
}));
먼저 스프레드입니다. 리액트의 state는 통째로 갈아끼우는 방식이라, 바뀐 필드 하나만 넣으면 나머지 둘이 사라집니다. 그래서 이전 값을 전부 펼쳐놓고 그 위에 바뀐 것 하나만 덮어씁니다.
순서도 중요해요. ...prevValues가 먼저 오고 [name]: value가 뒤에 와야 덮어쓰기가 됩니다. 반대로 쓰면 옛 값이 새 값을 덮어버립니다.
그리고 함수 형태로 넘긴 것. setValues(값) 대신 setValues(이전값 => 새값)으로 썼습니다.
이게 필요한 이유는 리액트가 state 갱신을 모아서 처리하기 때문입니다. 짧은 시간에 여러 번 호출되면 바깥에서 읽은 values가 최신이 아닐 수 있어요. 함수 형태로 넘기면 리액트가 갱신 직전의 값을 넣어주니 안전합니다.
한 필드만 바꾸는 흔한 코드인데, 그 안에 리액트의 상태 갱신 규칙이 두 개나 들어 있습니다.
📝 원문에서는 이렇게 씁니다
글에 설명 문장이 거의 없습니다. 코드 두 벌과 주석 몇 줄이 전부예요.
// 여러개로 관리하는 state를
// 하나의 state로 수정 (state도 하나로 줄어들고 handler 함수도 하나로 만들 수 있어서 깔끔한 코드 작성가능)
바뀐 자리에 정확히 한 줄씩 붙어 있습니다.
그리고 handleSubmit 안에 주석 처리된 흔적이 남아 있어요.
const handleSubmit = (e) => {
e.preventDefault();
// console.log({
// title,
// rating,
// content
// });
console.log(values);
};
세 변수를 묶어서 찍던 코드를 지우지 않고 주석으로 남긴 뒤, 아래에 console.log(values)를 새로 적었습니다.
이 두 줄이 리팩터링 결과를 그대로 보여줍니다. 전에는 흩어진 셋을 손으로 묶어야 했는데, 이제는 이미 묶여 있는 걸 그냥 찍으면 됩니다. 폼 데이터를 서버로 보낼 때도 마찬가지고요.
주석을 지우면 코드가 깔끔해지지만, 남겨두면 무엇이 달라졌는지가 보입니다.
큐레이터 노트
"깔끔한 코드"라는 말을 코드로 보여준 게 이 글입니다.
리팩터링을 다룬 글은 흔한데, 대부분 정리된 결과만 보여줍니다. 그러면 왜 그게 나은지는 읽는 사람이 짐작해야 해요. 이 글은 전후를 통째로 올려서 줄어든 양이 눈에 보입니다. state 3줄이 1줄로, 핸들러 3개가 1개로요.
그런데 더 눈여겨볼 건 [name]: value 한 줄입니다. 이 문법을 몰랐다면 합칠 수가 없어요. 문법 하나를 알게 되니까 구조를 바꿀 수 있게 된 겁니다.
리팩터링이 취향의 문제로만 보일 때가 있는데, 실은 아는 문법의 범위가 넓어질 때 가능해지는 일이기도 합니다.
3회차 큐레이션에서 이분의 글을 두고 "바꾸기 전후를 나란히 둔다"고 적었는데, 이번 편이 그 습관을 가장 선명하게 보여줍니다.
💡 세 편을 겹쳐 읽으며
세 글이 다루는 자리가 전혀 다릅니다. 자료구조 시험 노트, C 문법, 리액트 폼이요.
그런데 셋 다 줄이는 이야기를 합니다. 흩어진 여러 편을 한 장으로, 여러 줄의 조건 분기를 몇 줄로, 세 개의 state를 하나로요.
줄이면 관계가 보인다
줄이는 일의 효용이 양이 적어지는 것만은 아닙니다. 셋 다 줄인 뒤에 새로 보이는 것이 있어요.
김영진 님의 총정리는 열다섯 가지 트리를 한 화면에 놓았습니다. 그러니까 "무엇을 빠르게 하려고 만든 트리인가"라는 축이 드러납니다. 진도별로 흩어져 있을 때는 안 보이던 배열이에요.
이주희 님의 values 객체는 세 필드를 한 덩어리로 묶었습니다. 그러니까 이 셋이 함께 움직이는 한 벌이라는 게 코드에 나타납니다. 서버로 보낼 때도 values 하나면 되고요.
전일수 님의 비교표도 같습니다. break와 continue를 각각 설명할 때는 안 보이던 "사용 위치가 다르다"가 표에서는 한 줄로 드러납니다.
흩어져 있으면 각각만 보이고, 모아놓으면 사이가 보입니다.
줄인 값을 어디서 치르나
세 글 모두 줄인 대가를 하나씩 남깁니다.
이주희 님의 방식은 입력칸에 name 속성을 반드시 달아야 합니다. 안 달면 조용히 이상한 프로퍼티가 생기고, 에러가 나지 않아서 바로 알기도 어려워요.
전일수 님의 break는 "가장 가까운 것만" 끝냅니다. 규칙이 단순해서 외우기 쉬운 대신, 바깥까지 나오려면 우회로가 필요합니다.
김영진 님의 총정리는 설명을 덜어냈습니다. 밀도가 높아진 대신, 처음 배우는 사람에게는 읽히지 않는 노트가 됐어요.
줄인다는 건 무언가를 밖으로 옮겨두는 일이라는 게 셋에서 공통으로 보입니다. name 속성으로, 우회로로, 이미 아는 지식으로요.
그래서 무엇을 남길 것인가
세 글이 남긴 것의 성격도 닮았습니다.
김영진 님은 정의를 남기고 설명을 뺐는데, 삽입·삭제 절차만은 통째로 남겼습니다. 손으로 따라 그려야 하는 것이니까요.
이주희 님은 코드를 정리하면서 주석 처리한 옛 코드를 남겼습니다. 지우면 깔끔한데, 두면 변화가 보이니까요.
전일수 님은 사례를 일곱 개로 쪼개 남겼습니다. 정의는 짧아도 되지만 경우의 수는 다 봐야 하니까요.
줄이는 일의 어려움은 빼는 데 있는 게 아니라, 무엇을 남길지 정하는 데 있습니다.
이번 회차에서 가져갈 것
1. 진도 노트와 별개로 총정리 한 장 만들기.
배우는 순서와 다시 찾는 순서는 다릅니다. 학기가 끝날 때 한 장으로 압축한 노트를 따로 만들어두면, 다음에 열 개를 다 열지 않아도 됩니다.
2. 절차가 필요한 것만 절차로 적기.
정의로 충분한 건 한 줄로, 손으로 따라 그려야 하는 건 단계별로. 분량을 균등하게 나누는 것보다 필요한 곳에 몰아주는 편이 다시 볼 때 낫습니다.
3. 중첩 반복문의 break는 안쪽만 끝난다는 걸 기억하기.
바깥까지 나오려면 플래그 변수나 함수 분리가 필요합니다. switch 안에서 continue를 쓰면 switch가 아니라 감싸고 있는 반복문의 다음 회차로 갑니다.
4. 같은 일을 하는 핸들러가 여럿이면 state부터 보기.
핸들러가 셋인 이유는 넣을 곳이 셋이기 때문입니다. state를 객체 하나로 합치면 [name]: value 한 줄로 핸들러도 하나가 됩니다.
5. 리팩터링할 때 옛 코드를 주석으로 한 번은 남겨보기.
지우면 결과만 남고, 남기면 무엇이 달라졌는지가 보입니다. 커밋하기 전에 정리하더라도, 기록으로 옮길 때는 두 벌을 함께 두는 편이 나중에 쓸모 있습니다.
2기 7회차는 2024년 겨울로 들어서던 무렵이었습니다. 한 학기가 마무리되어 가던 시기예요.
시험 노트와 C 교재와 리액트 폼이라는 서로 다른 자리에서, 세 분이 나란히 줄이는 일을 기록했습니다. 학기 끝 무렵이라 그랬을까요. 쌓아온 것을 한 번 정리하는 글이 모였습니다.
좋은 글 남겨주신 김영진 님, 전일수 님, 이주희 님께 감사드립니다. 그리고 2기를 함께 채워주신 모든 멤버분들께도요! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.