Antigravity Agent
53 lines
3.9 KiB
Markdown
53 lines
3.9 KiB
Markdown
---
|
|
id: P-REINFORCE-WIKI-DEV-CODE-SMELLS
|
|
title: "코드 악취 식별과 리팩토링 징후 (Code Smells)"
|
|
category: Unified
|
|
status: verified
|
|
canonical_id: ""
|
|
aliases: ["Code Smells", "코드 악취", "코드 스멜", "리팩토링 징후", "설계 결함"]
|
|
duplicate_of: ""
|
|
source_trust_level: A
|
|
confidence_score: 1.0
|
|
tags: ["Clean_Code", "Refactoring", "Code_Quality", "Design_Smells", "Maintenance"]
|
|
raw_sources: ["Datacollector_Export_2026-05-02"]
|
|
last_reinforced: 2026-05-02
|
|
github_commit: ""
|
|
---
|
|
|
|
# [[코드 악취 식별과 리팩토링 징후 (Code Smells)]]
|
|
|
|
## 1. 개요
|
|
코드 악취(Code Smells)는 프로그램 소스 코드 내에 존재하는 심각한 문제는 아니지만, 더 깊은 구조적 결함이나 향후 문제를 야기할 수 있는 잠재적인 징후들을 의미한다. 켄트 벡(Kent Beck)과 마틴 파울러(Martin Fowler)에 의해 대중화된 이 개념은, '직관적으로 무언가 잘못되었다'는 느낌을 주는 코드 패턴들을 분류하고 이에 대응하는 구체적인 리팩토링 기법을 연결해준다.
|
|
|
|
## 2. 주요 코드 악취 분류
|
|
- **비대화 (Bloaters)**: 클래스나 메서드가 시간이 지남에 따라 너무 커져서 관리하기 힘든 상태.
|
|
- *예: 긴 메서드(Long Method), 거대 클래스(Large Class), 데이터 뭉치(Data Clumps).*
|
|
- **객체 지향 남용 (Object-Orientation Abusers)**: 객체 지향의 원칙을 잘못 적용한 경우.
|
|
- *예: 복잡한 switch 문, 거부된 유산(상속받은 기능을 전혀 사용 안 함).*
|
|
- **변경 방해 요소 (Change Preventers)**: 한 곳을 수정하면 연관된 수많은 곳을 같이 고쳐야 하는 구조.
|
|
- *예: 산탄총 수술(Shotgun Surgery), 분기되는 수정(Divergent Change).*
|
|
- **불필요한 요소 (Dispensables)**: 존재 가치가 없거나 삭제해도 무방한 코드.
|
|
- *예: 중복 코드, 죽은 코드(Dead Code), 무의미한 주석.*
|
|
- **잘못된 결합 (Couplers)**: 클래스 간의 과도한 의존성.
|
|
- *예: 기능 편애(다른 클래스의 데이터를 과도하게 사용), 메시지 체인.*
|
|
|
|
## 3. 엔지니어링 가치
|
|
- **리팩토링의 이정표**: 코드를 언제, 어디서부터 고쳐야 할지 모를 때 코드 악취는 가장 명확한 우선순위와 리팩토링의 타겟을 제공함.
|
|
- **기술 부채 조기 탐지**: 심각한 버그나 아키텍처 붕괴로 이어지기 전에 문제의 징후를 발견하여 유지보수 비용을 획기적으로 낮춤.
|
|
- **공통의 설계 언어**: 팀 내에서 "이 메서드는 산탄총 수술 스멜이 나네요"와 같은 용어를 사용하여 코드 리뷰 시 설계 결함에 대해 구체적이고 전문적인 의사소통 가능.
|
|
|
|
## 4. 트레이드오프 및 주의사항
|
|
- **주관적 판단의 영역**: 무엇이 '악취'인지는 팀의 숙련도나 프로젝트의 맥락에 따라 달라질 수 있음. 기계적인 룰 적용보다는 팀 내 합의된 품질 기준이 중요함.
|
|
- **성급한 수정의 위험**: 단순히 악취가 난다고 해서 즉시 고치는 것이 항상 최선은 아님. 기능 구현이 급하거나 영향 범위가 너무 넓은 경우 전략적인 '기술 부채'로 남겨두는 판단도 필요.
|
|
- **도구의 한계**: 정적 분석 도구가 많은 악취를 잡아낼 수 있지만, '기능 편애'나 '잘못된 상속' 같은 논리적 스멜은 개발자의 통찰력 있는 코드 리뷰를 통해서만 발견 가능.
|
|
|
|
## 5. 지식 연결 (Related)
|
|
- [[Refactoring]]: 코드 악취를 제거하기 위한 구체적인 기술적 해법.
|
|
- [[Technical_Debt]]: 코드 악취를 방치했을 때 축적되는 결과물.
|
|
- [[Clean_Code]]: 코드 악취가 없는 상태의 지향점.
|
|
|
|
## 🧪 검증 상태 (Validation)
|
|
- **정보 상태**: 검증 완료 (Verified)
|
|
- **출처 신뢰도**: A
|
|
- **검토 이유**: 소프트웨어의 노후화를 방지하고 지속 가능한 구조를 유지하기 위해 설계상의 허점을 포착하는 핵심 렌즈인 '코드 악취' 체계 정립.
|