{{위키데이터 속성 추적}}
[[파일:121811469-rotten-apple-on-white-in-top-view.jpg|thumb]]
'''코드 스멜'''({{lang|en|code smell}}←코드 냄새)은 [[컴퓨터 프로그래밍]] 코드에서 더 심오한 문제를 일으킬 가능성이 있는 [[컴퓨터 프로그램|프로그램]] [[소스 코드]]의 특징을 가리킨다.<ref name=":0">{{저널 인용|title = When and Why Your Code Starts to Smell Bad|url = http://www.cs.wm.edu/~denys/pubs/ICSE'15-BadSmells-CRC.pdf|journal = 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering (ICSE)|date = 2015-05-01|pages = 403-414|volume = 1|doi = 10.1109/ICSE.2015.59|first = M.|last = Tufano|first2 = F.|last2 = Palomba|first3 = G.|last3 = Bavota|first4 = R.|last4 = Oliveto|first5 = M.|last5 = Di Penta|first6 = A.|last6 = De Lucia|first7 = D.|last7 = Poshyvanyk}}</ref>

이 용어는 1990년대 말 [[켄트 벡]]과 [[위키위키웹|워즈위키]]에 의해 고안된 것으로 보인다. 《Refactoring: Improving the Design of Existing Code》라는 책에서 특집으로 실리면서 이 용어의 이용이 늘어나게 되었다.<ref>{{서적 인용
 | first = Martin
 | last = Fowler
 | authorlink = Martin Fowler
 | year = 1999
 | title = Refactoring. Improving the Design of Existing Code
 | publisher = Addison-Wesley
 | isbn = 0-201-48567-2
}}
</ref> 또, 코드 스멜은 [[애자일 소프트웨어 개발|애자일 프로그래머]]가 사용하는 용어이기도 하다.<ref name="In Praise Of Small Code">{{웹 인용
|url= http://www.informationweek.com/news/development/architecture-design/231000038
|title= In Praise Of Small Code
|first= Andrew
|last= Binstock
|publisher= Information Week
|date= 2011-06-27
|accessdate= 2011-06-27
|archive-date= 2011-07-02
|archive-url= https://web.archive.org/web/20110702080759/http://www.informationweek.com/news/development/architecture-design/231000038
|url-status= dead
}}</ref>

무엇이 코드 스멜인지 아닌지의 여부를 결정하는 일은 주관적인 것으로 언어와 개발자, 개발 방법에 따라 다양하다. 자동으로 특정한 종류의 코드 스멜을 확인하기 위한 도구들이 있으며, 그 예로는 [[체크스타일]], [[PMD (소프트웨어)|PMD]], [[파인드벅스]] 등을 들 수 있다.

== 일반적인 코드 스멜 ==
응용 프로그램 수준의 스멜:
* 신비로운 이름: 함수, 모듈, 변수, 클래스 이름이 그들이 동작하는 방식이나 그들을 사용하는 방법과 어울리지 않게 작성된 이름 
* [[중복 코드]]: 동일하거나 매우 비슷한 코드가 다른 곳에 있음.
* 억지로 꾸민듯한 복잡성: 단순한 디자인 패턴으로도 충분한 곳에 과도하게 복잡한 패턴을 일부러 사용함
* 산탄총 수술: 간단한 변경이지만 여러 클래스에 동시에 적용해야 할 필요가 있는 변경.
* 제어할 수 없는 부작용: 대개 실행할 때 예외를 일으키는 코딩의 부작용, 단위 테스트로는 문제의 원인을 잡아 낼 수 없음.
* 변수 용도 변경: 변수의 상태가 예측불가능하여 추론하기가 어려워 리팩토링하면 난이도를 증가시키기 충분함.
* 보고 있어도 헷갈리는 부울리언 값: 반대 상황을 쉽게 알 수 있지만, 여전히 맞는지 확인해야하는 상황.

클래스 수준의 스멜:
* 커다란 클래스
* 기능에 대한 욕심
* 부적절한 관계
* 거부된 유산
* 게으른 클래스
* 리터럴의 과도한 사용
* [[순환 복잡도]]
* [[다운캐스팅]]
* 고아 변수 또는 컨스턴트 클래스
* 데이터 덩어리

메서드 수준의 스멜:
* 너무 많은 매개변수
* 긴 메서드
* 과도하게 긴 식별자
* 과도하게 짧은 식별자
* 과도한 데이터의 반환
* 과도한 주석
* 과도하게 긴 줄로된 코드

== 같이 보기 ==
* [[안티패턴]]

== 각주 ==
{{각주}}

== 외부 링크 ==
* {{언어링크|en}} [http://c2.com/cgi/wiki?CodeSmell CodeSmell at c2.com]
* {{언어링크|en}} [http://badcodesmellstaxonomy.mikamantyla.eu/ Taxonomy of code smells] {{웨이백|url=http://badcodesmellstaxonomy.mikamantyla.eu/ |date=20141023074756 }}
* {{언어링크|en}} [http://www.codinghorror.com/blog/2006/05/code-smells.html Overview of many code smells] {{웨이백|url=http://www.codinghorror.com/blog/2006/05/code-smells.html |date=20130118193329 }}
* {{언어링크|en}} [http://martinfowler.com/bliki/CodeSmell.html CodeSmell]
* {{언어링크|en}} Boundy, David, [http://dl.acm.org/citation.cfm?id=156632 Software cancer: the seven early warning signs] or [https://www.academia.edu/2303865/Software_cancer_the_seven_early_warning_signs here], ACM SIGSOFT Software Engineering Notes, Vol. 18 No. 2 (April 1993), Association for Computing Machinery, New York, NY, USA

[[분류:안티패턴]]