클린 코드 실전 강의 교재¶
15장 — JUnit 들여다보기¶
대상: Java/Spring 백엔드 입문~중급 수강생 형식: 실제 오픈소스 코드 정련 워크스루 전제 환경: Java 17+
0. 이 장을 시작하기 전에¶
0.1 학습 목표¶
- 이미 좋은 코드 (JUnit) 도 더 깨끗하게 만들 수 있음을 본다.
- 이름·메서드 추출·중복 제거 의 작은 단계 누적 효과.
- 보이스카우트 규칙의 실천.
0.2 사례 — JUnit ComparisonCompactor¶
두 문자열의 차이를 압축해 보여주는 클래스 (예: expected:<...123...> but was:<...456...>).
이미 잘 작성된 코드 — 짧고 명확. 그래도 정련의 여지가 있음을 보여줌.
0.3 현업에서 왜 중요한가¶
- "이만하면 됐다" 의 함정. 항상 더 깔끔하게 가능.
- 보이스카우트 규칙 = 매 PR에서 작은 개선.
15.1 워크스루 — 단계별 정련¶
책에서 다루는 변환들 (요약)¶
- 이름 명확화 —
f,g같은 한 글자 변수 → 의도 드러나는 이름 - 메서드 추출 — 한 가지 일 하는 작은 함수로
- 중복 제거 — 반복되는 조건·계산 통합
- enum 도입 — boolean 플래그를 의미 있는 상수로
- 이름·매개변수 정련 — 메서드 시그니처 다듬기
매 단계마다¶
- 모든 JUnit 테스트 통과 확인
- 한 PR = 한 의도
15.2 결론¶
책의 단언¶
"좋은 코드는 더 좋게 만들 수 있다. 항상."
JUnit 만든 거장들 (Beck·Gamma) 도 정련의 여지를 남김 — 보이스카우트 규칙은 누구에게나.
핵심 교훈¶
- 이미 좋은 코드 도 정련 가능.
- 이름 + 메서드 추출 = 가장 가성비 큰 정련.
- 보이스카우트 규칙은 거장의 코드에도 적용.
- 매 단계 테스트 통과 = 안전망.
함정 / 주의¶
- "더 좋게" 가 끝없으면 멈춤이 필요. 의도가 명료해진 시점에서 stop.
- 보이스카우트 규칙도 PR 분리 — 정련을 새 기능과 섞지 마라 (두 모자).
체크리스트¶
- PR마다 손댄 파일에서 작은 개선 하나라도 했는가
- 정련을 새 기능 PR과 섞지 않았는가
- 한 글자 변수가 함수 본문 길이만큼 살아있는가
- boolean 플래그가 의미 있는 enum 이 될 수 있는가
퀴즈¶
Q1. "이미 좋은 코드도 더 좋게" 의 의미?
A. 완벽한 코드는 없음. 더 명확한 이름, 더 작은 함수, 더 좋은 추상화는 항상 가능. 보이스카우트 규칙 — 매번 조금씩 더 깨끗하게.
Q2. 정련과 새 기능 추가를 섞으면 안 되는 이유?
A. 두 모자 (2장) 위배. 리뷰 부담 폭증·실패 시 어느 변경이 원인인지 추적 어려움. 분리된 PR이 안전.
Q3. JUnit 정련 사례가 보여주는 가장 큰 메시지?
A. 거장의 코드도 완벽 X. 누구든, 어떤 코드든 정련의 여지가 있고, 작은 정련의 누적이 큰 차이를 만든다.
다음 장 예고 — 16장: SerialDate 리팩터링¶
악취 많은 실제 오픈소스 클래스를 통째로 리팩터링. 17장 휴리스틱 카탈로그가 적용되는 살아있는 사례.