코드 냄새

Code smell

컴퓨터 프로그래밍에서 코드 냄새는 더 심각한 [1][2]문제를 나타낼 수 있는 프로그램의 소스 코드에 있는 특성입니다.코드 냄새의 존재와 존재 여부를 판단하는 것은 주관적이며 언어, 개발자 및 개발 방법에 따라 다릅니다.

이 용어는 1990년대 [3]후반 WardsWiki에서 Kent Beck에 의해 널리 알려졌습니다.이 용어의 사용은 1999년 책 Refactoring:에 소개된 이후 증가했습니다. Martin Fowler의 [4]기존 코드 디자인 개선.민첩한 프로그래머들이 [5]사용하는 용어이기도 합니다.

정의.

냄새를 보는 한 가지 방법은 원칙과 품질에 관한 것입니다. "냄새는 기본 설계 원칙을 위반하고 설계 [6]품질에 부정적인 영향을 미치는 코드 내의 특정 구조입니다."코드 냄새는 보통 버그가 아닙니다.기술적으로 정확하지 않고 프로그램의 동작을 방해하지 않습니다.대신, 이들은 개발 속도를 늦추거나 향후 버그나 장애의 위험을 증가시킬 수 있는 설계의 약점을 나타냅니다.악성코드 냄새는 기술적 [1]부채의 원인이 되는 요소의 지표가 될 수 있습니다.로버트 C. 마틴은 코드 냄새 목록을 소프트웨어 장인 정신을 [7]위한 "가치 체계"라고 부릅니다.

코드 냄새에 의해 암시되는 보다 깊은 문제는 종종 코드에 짧은 피드백 사이클이 주어지고, 코드에 작은 제어 단계로 리팩터링이 추가되는 코드 냄새가 있는지 여부를 조사하면 밝혀질 수 있습니다.리팩터링을 수행하는 프로그래머의 관점에서 코드 냄새는 리팩터링 타이밍과 어떤 특정 리팩터링 기술을 사용해야 하는지를 나타내는 휴리스틱스이다.따라서 코드 냄새는 리팩터링의 원동력이 됩니다.

2015년[1] 50만 개의 소스 코드 커밋에 대한 자동 분석과 "코드 냄새"를 나타내는 것으로 확인된 9,164개의 커밋을 수동으로 검사한 결과 다음과 같은 결과가 나왔습니다.

  • "기술 부채"의 결과에 대한 경험적 증거가 존재하지만, 이러한 현상이 발생하는 방법, 시기 또는 이유에 대한 일화적 증거만 존재한다.
  • 코드 품질보다 출시 기간을 우선시하면서 긴급한 유지보수 활동과 기능을 제공해야 한다는 압박이 이러한 냄새의 원인인 경우가 많다는 것이 일반적인 견해입니다.

Checkstyle, PMD, FindBugs, SonarQube 등의 도구는 코드 냄새를 자동으로 식별할 수 있습니다.

공통 코드 냄새

응용 프로그램 수준의 냄새

  • 알 수 없는 이름: 함수, 모듈, 변수 또는 클래스가 작업이나 사용 방법을 전달하지 않는 방식으로 명명되었습니다.
  • 중복 코드: 여러 위치에 동일하거나 매우 유사한 코드가 있습니다.
  • 계획된 복잡성: 단순한 설계 패턴으로 충분할 정도로 복잡한 설계 패턴을 강제로 사용합니다.
  • 산탄총 수술: 동시에 여러 클래스에 적용해야 하는 단일 변경.
  • 제어되지 않은 부작용: 일반적으로 런타임 예외를 발생시키는 코딩의 부작용. 유닛 테스트에서는 문제의 정확한 원인을 파악할 수 없습니다.
  • 가변 돌연변이: 예측 불가능하고 추론하기 어려운 실제 값 상태 때문에 코드를 리팩터링하는 것이 점점 더 어려워질 정도로 매우 다양한 돌연변이입니다.
  • Boolean 블라인드: 반대 값에 대해 단언하기 쉬우며 여전히 유형 검사입니다.

클래스 레벨의 냄새

  • Large class: 너무 커진 클래스입니다.신 오브젝트 참조.
  • Feature envy: 다른 클래스의 메서드를 과도하게 사용하는 클래스입니다.
  • 부적절한 친밀성: 다른 클래스의 구현 세부 사항에 종속된 클래스입니다.Object orgy를 참조하십시오.
  • 거부된 유산: 파생 클래스에서 기본 클래스의 계약을 준수하지 않도록 기본 클래스의 메서드를 재정의하는 클래스입니다.「리스코프 치환 원리」를 참조해 주세요.
  • 게으른 수업/자유로운 수업: 너무 적은 수업.
  • 과도한 리터럴 사용: 가독성을 향상시키고 프로그래밍 오류를 방지하기 위해 리터럴을 지정된 상수로 코딩해야 합니다.또한 리터럴을 자원 파일/스크립트 또는 가능한 경우 데이터베이스 등의 기타 데이터 스토어로 외부화할 수 있으며, 소프트웨어를 다른 [8]지역에 전개할 예정인 경우 소프트웨어의 현지화를 촉진할 수 있습니다.
  • 사이클로매틱 복잡성: 브랜치 또는 루프가 너무 많다.이것은 기능을 작은 기능으로 분할할 필요가 있거나, 심플화/리팩터링의 가능성이 있는 것을 나타내고 있는 경우가 있습니다.
  • 다운캐스팅: 추상화 모델을 깨는 타입 캐스트입니다.추상화를 리팩터링하거나 [9]삭제해야 할 수 있습니다.
  • Orphan 변수 또는 상수 클래스: 일반적으로 이러한 상수가 다른 멤버 클래스 중 하나에 의해 소유되어야 하는 다른 곳에 속하는 상수 컬렉션이 있는 클래스입니다.
  • 데이터 클램프:프로그램의 다양한 부분에서 변수 그룹이 함께 전달될 때 발생합니다.일반적으로 이는 여러 변수를 공식적으로 단일 개체로 그룹화하고 대신 [10][11]새 개체만 전달하는 것이 더 적절하다는 것을 나타냅니다.

방법 수준의 냄새

  • 파라미터가 너무 많다: 파라미터 목록이 길면 읽기 어렵고 함수의 호출과 테스트가 복잡해진다.이는 함수의 목적이 잘못 인식되어 책임이 보다 [12]깔끔하게 할당되도록 코드를 리팩터링해야 함을 나타낼 수 있습니다.
  • 롱 메서드: 너무 커진 메서드, 기능 또는 프로시저.
  • 식별자가 너무 길다: 특히 명명 규칙을 사용하여 소프트웨어 아키텍처에 암묵적으로 포함되어야 하는 명확성을 제공합니다.
  • 지나치게 짧은 식별자: 함수가 명확하지 않은 한 변수 이름은 함수를 반영해야 합니다.
  • 과도한 데이터 반환: 각 발신자가 필요로 하는 것보다 많은 데이터를 반환하는 기능 또는 방식.
  • 과도한 코멘트: 클래스, 함수 또는 메서드에 관련이 없거나 사소한 코멘트가 있습니다.Atribut setter/getter에 대한 코멘트가 좋은 [citation needed]예입니다.
  • 지나치게 긴 코드 행(또는 God Line):코드가 너무 길어서 읽기, 이해, 디버깅, 리팩터링, 소프트웨어 재사용 가능성조차 식별하기 어렵습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c Tufano, Michele; Palomba, Fabio; Bavota, Gabriele; Oliveto, Rocco; Di Penta, Massimiliano; De Lucia, Andrea; Poshyvanyk, Denys (2015). "When and Why Your Code Starts to Smell Bad" (PDF). 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering. pp. 403–414. CiteSeerX 10.1.1.709.6783. doi:10.1109/ICSE.2015.59. ISBN 978-1-4799-1934-5. S2CID 59100195.
  2. ^ Fowler, Martin. "CodeSmell". martinfowler.com/. Retrieved 19 November 2014.
  3. ^ Beck, Kent. "Code Smells". WikiWikiWeb. Ward Cunningham. Retrieved 8 April 2020.
  4. ^ Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 978-0-201-48567-7.
  5. ^ Binstock, Andrew (2011-06-27). "In Praise Of Small Code". Information Week. Retrieved 2011-06-27.
  6. ^ Suryanarayana, Girish (November 2014). Refactoring for Software Design Smells. Morgan Kaufmann. p. 258. ISBN 978-0128013977.
  7. ^ Martin, Robert C. (2009). "17: Smells and Heuristics". Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. ISBN 978-0-13-235088-4.
  8. ^ "Constants and Magic Numbers". Retrieved 2020-11-03.
  9. ^ Miller, Jeremy. "Downcasting is a code smell". Archived from the original on 16 February 2019. Retrieved 4 December 2014.
  10. ^ Fowler, Martin. "DataClump". Retrieved 2017-02-03.
  11. ^ "Design Patterns and Refactoring". sourcemaking.com. Retrieved 2017-02-04.
  12. ^ "Code Smell 10 - Too Many Arguments".

추가 정보

외부 링크

  • "CodeSmell". martinfowler.com. Retrieved 2022-03-01.
  • Boundy, David, Software cancer: 7가지 조기 경고 신호 또는 여기, ACM SIGSOFT 소프트웨어 엔지니어링 노트, 제18권 제2호(1993년 4월), 미국 뉴욕주 뉴욕시 컴퓨터 기계 협회