코드 스멜
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
코드 스멜은 소프트웨어의 설계상 약점을 나타내는 용어이다. 이는 버그와는 달리 프로그램의 작동을 직접적으로 방해하지 않지만, 개발 속도를 늦추거나 향후 버그 발생 위험을 증가시킬 수 있다. 코드 스멜은 리팩토링의 필요성과 방법을 알려주며, 가독성, 수정 용이성, 재사용성, 테스트 가능성, 신뢰성 등을 저해하는 요인으로 작용한다. 일반적인 예시로는 신비로운 이름, 중복 코드, 억지로 꾸민듯한 복잡성 등이 있으며, 코드 스멜을 자동으로 식별하는 도구들이 존재한다. 코드 스멜은 애플리케이션, 클래스, 메서드 등 다양한 수준에서 발견될 수 있으며, 기술 부채와 연관되어 소프트웨어 개발에 영향을 미친다.
더 읽어볼만한 페이지
| 코드 스멜 | |
|---|---|
| 코드 스멜 | |
| 코드 스멜 (영어) | Code Smell |
| 코드 스멜 (일본어) | コードの臭い (Kōdo no nioi) |
| 정의 | 코드의 더 심오한 문제점을 암시하는 소스 코드의 특징 |
| 특징 | |
| 설명 | 코드 스멜은 반드시 오류는 아니지만, 디자인 결함으로 이어질 가능성이 높음 코드를 리팩토링해야 함을 나타내는 지표 |
| 영향 | 소프트웨어 유지보수 및 진화를 방해 품질 저하 생산성 감소 |
| 코드 스멜의 종류 | |
| 블로브 (Blob) | 거대한 클래스나 메서드로, 응집도가 낮고 유지보수가 어려움 |
| 분기 지옥 (Divergent Change) | 하나의 클래스가 여러 종류의 변경에 의해 자주 수정되는 경우 |
| 데이터 클래스 (Data Class) | 데이터만 저장하고 행동이 없는 클래스 |
| 기능 질투 (Feature Envy) | 메서드가 자신이 속한 클래스보다 다른 클래스의 데이터에 더 많이 접근하는 경우 |
| 긴 클래스 (Long Class) | 너무 많은 책임을 지는 클래스 |
| 긴 메서드 (Long Method) | 너무 긴 코드를 가진 메서드, 가독성과 유지보수성이 떨어짐 |
| 메시지 체인 (Message Chains) | 객체가 다른 객체에게 요청을 연쇄적으로 전달하는 경우 |
| 중간자 (Middle Man) | 다른 클래스에 작업을 위임하는 역할만 하는 클래스 |
| 평행 상속 계층 (Parallel Inheritance Hierarchies) | 하나의 클래스를 변경할 때마다 다른 상속 계층의 클래스도 변경해야 하는 경우 |
| 샷건 수술 (Shotgun Surgery) | 하나의 변경을 위해 여러 클래스를 수정해야 하는 경우 |
| 산탄총 수술 (Shotgun Surgery) | 작은 변경 사항이 많은 클래스에 걸쳐 퍼져 있는 경우 |
| 스파게티 코드 (Spaghetti Code) | 구조가 복잡하고 얽혀 있어 이해하기 어려운 코드 |
| 임시 필드 (Temporary Field) | 특정 상황에서만 사용되는 필드 |
| 거부된 유산 (Refused Bequest) | 하위 클래스가 상위 클래스의 메서드나 데이터를 사용하지 않는 경우 |
| 게으른 클래스 (Lazy Class) | 별로 하는 일이 없는 클래스 |
| 추측적 일반성 (Speculative Generality) | 필요하지 않은 일반화를 미리 적용한 경우 |
| 과도한 친밀함 (Intimacy) | 클래스 간에 지나치게 많은 정보를 공유하는 경우 |
| 형편없는 주석 (Comments) | 코드를 설명하기보다 불필요하거나 부정확한 정보를 제공하는 주석 |
| 중복 코드 (Duplicated Code) | 코드의 여러 부분에서 동일하거나 유사한 코드가 반복되는 경우 |
| 매직 넘버 (Magic Number) | 코드 내에 직접 포함된 이해하기 어려운 숫자 |
| 넓은 클래스 (Large Class) | 필드와 메서드가 너무 많은 클래스 |
| 기본 데이터에 대한 집착 (Primitive Obsession) | 작은 데이터 덩어리를 조합하여 만들지 않고 기본 데이터형을 고집하는 방식 |
| 불필요한 복잡성 (Needless Complexity) | 불필요하게 복잡한 코드 구조 |
| 해결 방법 | |
| 설명 | 코드 스멜은 리팩토링을 통해 해결 가능 |
2. 코드 스멜의 정의 및 특징
코드 스멜은 일반적으로 버그는 아니며, 프로그램의 작동을 직접적으로 방해하지 않는다.[1] 코드 스멜은 개발 속도를 늦추거나 향후 버그 또는 오류의 위험을 증가시킬 수 있는 설계상의 약점을 나타내며, 기술 부채에 기여하는 요인의 지표가 될 수 있다.[1] 로버트 C. 마틴은 코드 스멜 목록을 소프트웨어 장인 정신을 위한 "가치 시스템"이라고 부른다.[7]
코드 스멜은 코드의 다양한 수준에서 발견될 수 있다.
코드 스멜은 리팩토링을 해야 하는 시점과 어떤 리팩토링 기법을 사용해야 하는지에 대한 단서를 제공한다.[3] 코드의 가독성, 수정 용이성, 기능 변경 지원, 재사용성, 테스트 가능성, 신뢰성 등은 코드 스멜을 식별하는 데 사용될 수 있는 요소이다.[8]
2015년 연구[1]에 따르면, "기술 부채"의 결과에 대한 실증적 증거는 있지만, 이것이 "어떻게", "언제", "왜" 발생하는지에 대한 일화적인 증거만 존재한다. 일반적인 통념은 시급한 유지 관리 활동과 코드 품질보다 시장 출시 시간을 우선시하면서 기능을 제공하려는 압력이 종종 이러한 스멜의 원인이라는 것이다.
코드 스멜의 예로는 신비로운 이름, 중복 코드, 억지로 꾸민듯한 복잡성, 산탄총 수술, 제어할 수 없는 부작용 등이 있다.[6]
Checkstyle, PMD, FindBugs, SonarQube와 같은 도구는 코드 스멜을 자동으로 식별할 수 있다.
3. 코드 스멜의 종류
일반적인 코드 스멜 (애플리케이션 수준)신비로운 이름은 함수, 모듈, 변수, 클래스 등의 이름이 그 동작 방식이나 사용 방법과 어울리지 않게 작성된 경우를 말한다. 중복 코드는 동일하거나 매우 비슷한 코드가 여러 곳에 존재하는 것을 의미한다. 억지로 꾸민듯한 복잡성은 단순한 디자인 패턴으로도 충분한 곳에 과도하게 복잡한 패턴을 일부러 사용하는 경우이다. 산탄총 수술은 간단한 변경임에도 불구하고 여러 클래스를 동시에 수정해야 하는 경우를 가리킨다.
제어할 수 없는 부작용은 대개 실행할 때 예외를 발생시키는 코딩의 부작용을 말하며, 단위 테스트로는 문제의 원인을 찾기 어렵다. 변수 용도 변경은 변수의 상태를 예측하기 어렵게 만들어 리팩토링 난이도를 높인다. 보고 있어도 헷갈리는 부울리언 값은 반대 상황을 쉽게 알 수 있지만, 여전히 맞는지 확인해야 하는 상황을 의미한다.
클래스 수준의 스멜클래스가 너무 많은 기능을 수행하여 비대해지는 경우를 ''커다란 클래스''(God object영어 참조)라고 한다. 다른 클래스의 메서드를 과도하게 사용하는 ''기능에 대한 욕심''이나, 다른 클래스의 구현 세부 사항에 의존하는 ''부적절한 관계''도 클래스 수준의 스멜에 해당한다.
''상속 거부''는 기본 클래스의 규약이 존중되지 않는 형태로 메서드를 오버라이드하는 경우를 말하며, 리스코프 치환 원칙 위반과 관련된다. 수행하는 일이 너무 적은 ''게으른 클래스'' 또한 코드 스멜로 간주된다.
메서드 수준의 스멜메서드, 함수, 프로시저가 너무 길어지는 경우가 발생하면 너무 긴 메서드라고 한다. 거대한 클래스는 너무 커진 클래스를 의미하며 신 객체를 참조하는 경우도 있다.
3. 1. 일반적인 코드 스멜 (애플리케이션 수준)
신비로운 이름은 함수, 모듈, 변수, 클래스 등의 이름이 그 동작 방식이나 사용 방법과 어울리지 않게 작성된 경우를 말한다. 중복 코드는 동일하거나 매우 비슷한 코드가 여러 곳에 존재하는 것을 의미한다. 억지로 꾸민듯한 복잡성은 단순한 디자인 패턴으로도 충분한 곳에 과도하게 복잡한 패턴을 일부러 사용하는 경우이다. 산탄총 수술은 간단한 변경임에도 불구하고 여러 클래스를 동시에 수정해야 하는 경우를 가리킨다.
제어할 수 없는 부작용은 대개 실행할 때 예외를 발생시키는 코딩의 부작용을 말하며, 단위 테스트로는 문제의 원인을 찾기 어렵다. 변수 용도 변경은 변수의 상태를 예측하기 어렵게 만들어 리팩토링 난이도를 높인다. 보고 있어도 헷갈리는 부울리언 값은 반대 상황을 쉽게 알 수 있지만, 여전히 맞는지 확인해야 하는 상황을 의미한다.
3. 2. 클래스 수준의 스멜
클래스가 너무 많은 기능을 수행하여 비대해지는 경우를 ''커다란 클래스''(God object영어 참조)라고 한다. 다른 클래스의 메서드를 과도하게 사용하는 ''기능에 대한 욕심''이나, 다른 클래스의 구현 세부 사항에 의존하는 ''부적절한 관계''도 클래스 수준의 스멜에 해당한다.
''상속 거부''는 기본 클래스의 규약이 존중되지 않는 형태로 메서드를 오버라이드하는 경우를 말하며, 리스코프 치환 원칙 위반과 관련된다. 수행하는 일이 너무 적은 ''게으른 클래스'' 또한 코드 스멜로 간주된다.
3. 3. 메서드 수준의 스멜
메서드, 함수, 프로시저가 너무 길어지는 경우가 발생하면 너무 긴 메서드라고 한다. 거대한 클래스는 너무 커진 클래스를 의미하며 신 객체를 참조하는 경우도 있다.
4. 코드 스멜 탐지 도구
5. 코드 스멜과 기술 부채
6. 코드 스멜에 대한 관점
7. 한국의 관점
참조
[1]
서적
2015 IEEE/ACM 37th IEEE International Conference on Software Engineering
[2]
웹사이트
CodeSmell
http://martinfowler.[...]
2014-11-19
[3]
웹사이트
Code Smells
https://wiki.c2.com/[...]
Ward Cunningham
2020-04-08
[4]
서적
Refactoring. Improving the Design of Existing Code
https://archive.org/[...]
Addison-Wesley
[5]
웹사이트
In Praise Of Small Code
http://www.informati[...]
Information Week
2011-06-27
[6]
서적
Refactoring for Software Design Smells
Morgan Kaufmann
2014-11
[7]
서적
Clean Code: A Handbook of Agile Software Craftsmanship
Prentice Hall
[8]
서적
Refactoring for Software Design Smells : Managing Technical Debt
Morgan Kaufmann
2015
[9]
서적
Refactoring. Improving the Design of Existing Code
Addison-Wesley
[10]
서적
リファクタリング―プログラムの体質改善テクニック
ピアソン・エデュケーション
[11]
간행물
When and Why Your Code Starts to Smell Bad
http://www.cs.wm.edu[...]
2015-05-01
[12]
서적
Refactoring. Improving the Design of Existing Code
https://archive.org/[...]
Addison-Wesley
[13]
웹인용
In Praise Of Small Code
http://www.informati[...]
Information Week
2011-06-27
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com