The process of restructuring existing computer code without changing its external behavior
외부에서 본 동작은 그대로 유지한 채, 내부 구조를 개선하여 가독성·유지보수성·확장성을 높이는 활동.
적용 시점
- 코드를 이해하기 힘들 때
- 중복된 로직이 들어가 있을 때
- 조건문의 구조가 복잡할 때
- 순환 복잡도가 한계치(MS 10, 자동차 30)를 초과할 때
적용 효과
- 코드 가독성/이해도 향상
- 결함(버그) 발견 용이
- 소프트웨어 설계 개선 (Mediator 패턴 등으로 구조 단순화)
Code Smells
리팩토링이 필요한 코드의 징후:
| 분류 | 징후 |
|---|---|
| 가독성/유지보수 어려움 | Line too long, Class/Method too large, Variable unused |
| 잠재적 리스크 | 순환 복잡도 과다, 변수 미초기화, 불필요한 전역 변수 |
→ 코딩 표준 위반 = 대부분 Code Smells.
Good Code의 특성
Bad Code의 대척점으로 리팩토링이 지향하는 목표:
- 작은 추상화 — 깔끔하고 단정하게 정리된 구조
- 의존성 최소화
- 단순한 제어문 — 명백하고 단순
- 중복 없음
- 단일 기능 — 한 함수는 한 기능만
- 다른 사람도 읽기 쉽고 고치기 쉬운 코드
- 테스트 가능한 코드
- 결함이 적은 코드
Robert C. Martin, Clean Code (2013)이 대표 정리한 원칙. 정량 측정 지표는 소스코드 메트릭 참조.
코드 품질을 측정하는 유일한 척도 = 분당 내지르는 WTF! 횟수
— 가독성·유지보수성이 측정의 본질임을 드러내는 농담.
Broken Window Theory
깨진 유리창 이론: 기존 코드가 Bad Code라면 코딩 시간보다 코드 리딩 시간이 더 오래 걸려 생산성이 급락한다.
- 최초의 깨끗한 코드 → 변경 누적으로 구조 복잡 → 중복 코드 유입 → 이해 곤란
- 작은 무질서를 방치하면 더 큰 무질서가 빠르게 누적됨
- → Code Smells 발견 즉시 리팩토링 원칙
TDD는 이 원칙을 사이클 단계로 흡수 — 테스트 통과 직후를 리팩토링 시점으로 강제한다.
리팩토링 대상
중복 코드 (Duplicated Code)
- 정의: A sequence of source code that occurs more than once.
- 해결: 공통 로직을 별도 메서드(
calcAvg등)로 추출하여 재사용 (Extract Method).
방대한 클래스 (Large Class)
- 정의: A class contains many fields/methods/lines of code
- 해결 예시:
Person클래스가 회사 정보(officeAreaCode,officeNumber)까지 보유 →Company클래스로 분리 (Extract Class, Move Field).
장황한 메서드 (Long Method)
- 메서드가 너무 길어 단일 책임을 위반.
- 해결: Extract Method, Replace Temp with Query 등.
디자인 패턴 활용 — Mediator
- AS-IS: 객체 간 상호작용이 복잡 → 변경 시 관련 클래스 모두 수정 필요
- TO-BE (Mediator): 객체 간 상호작용을 Mediator를 통해 중계 → 변경 시 Mediator만 수정
→ 소프트웨어 설계의 낮은 결합도 원칙 실현.