노트

코드 냄새

Code Smell

설계#refactoring · 연결된 개념 16개

쉽게 말하면

코드 냄새는 냉장고를 열었을 때 나는 이상한 냄새 같은 거예요. 아직 상한 건 아닐 수도 있지만 '한번 들여다봐야겠다'는 신호라서, 언제 고칠지 감을 서로 말로 나눌 수 있게 해 줘요.

비유가 깨지는 곳 냄새가 난다고 늘 버려야 하는 건 아니에요. 냄새는 정해진 공식이 아니라 리팩터링을 시작할 신호이고, 긴 함수엔 함수 추출처럼 냄새마다 먼저 볼 기법이 따로 있어요.

당장 버그는 아니지만 이해나 변경 비용을 높이는 구조적 신호. 리팩터링을 언제 시작하고 멈출지에 정확한 공식은 없어서, 냄새라는 어휘로 직관을 공유한다.

다섯 갈래

냄새를 다섯 갈래로 묶은 것은 Refactoring.Guru의 분류다. 『리팩터링 2판』 3장은 24가지 냄새를 묶지 않고 나열한다.

  • 비대해진 것(Bloaters): 긴 함수(Long Function), 거대한 클래스(Large Class), 기본형 집착, 긴 매개변수 목록(Long Parameter List), 늘 함께 다니는 데이터 뭉치(Data Clumps) → 매개변수 객체 만들기
  • 객체지향 오용(Object-Orientation Abusers): 반복되는 switch(Repeated Switches, 조건부 로직을 다형성으로 바꾸기), 특정 상황에만 값이 차는 임시 필드(Temporary Field), 물려받고도 안 쓰는 상속 포기(Refused Bequest, 상속보다 위임), 역할은 같은데 인터페이스가 다른 대안 클래스
  • 변경 방해꾼(Change Preventers): 산탄총 수술과 뒤엉킨 변경, 한쪽 계층을 늘리면 다른 계층도 늘려야 하는 평행 상속 계층(Parallel Inheritance Hierarchies)
  • 없어도 되는 것(Dispensables): 중복 코드(Duplicated Code), 죽은 코드 제거, 하는 일이 거의 없는 요소, 데이터만 있고 행동은 밖에 있는 데이터 클래스(Data Class), 추측성 일반화, 코드를 대신 설명하는 장황한 주석
  • 결합 유발자(Couplers): 기능 편애, 서로 속사정을 너무 아는 클래스, 메시지 체인(Message Chains)과 중개자(Middle Man, 디미터 법칙)

냄새에서 기법으로

냄새먼저 볼 기법
긴 함수함수 추출, 임시 변수를 질의 함수로
긴 매개변수 목록매개변수 객체, 객체 통째로 넘기기, 플래그 인수 제거
전역·가변 데이터변수 캡슐화, 세터 제거, 질의와 변경 분리
중복 코드함수 추출, 문장 슬라이드, 메서드 올리기
주석함수 추출, 이름 바꾸기, 어서션

주석을 달고 싶어지면 먼저 주석이 필요 없는 코드로 바꿀 수 있는지 본다. 심플 디자인 관점에서는 냄새 대부분이 "중복"이나 "구성요소가 많음"의 다른 얼굴이다(구성요소 줄이기). 테스트 코드의 냄새는 테스트 냄새에 따로 정리했다.

출처: 『리팩터링 2판』 마틴 파울러 (원서 Refactoring, 2nd Edition) · Refactoring.Guru: Code Smells · Martin Fowler: Code Smell

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • 언어적 안티패턴

    이름, 타입, 주석이 말하는 것과 코드가 실제로 하는 일이 어긋나는 것. 읽는 사람을 잘못된 추측으로 이끈다.

  • 청킹과 코드 읽기

    여러 정보를 의미 있는 덩어리 하나로 묶어 기억하는 것. 아는 것이 많을수록 코드를 큰 덩어리로 읽는다.

  • 디자인 패턴

    반복해서 나타나는 설계 문제에 대한 검증된 해결 구조와 그 이름. 복사해 쓰는 완성 코드가 아니라 객체들이 협력하는 방식을 설명하는 어휘다. 1994년 이른바 GoF(Gang of Four, 네 명의 저자)의 책 『Design Patterns: Elements of Reusable Object-Oriented Software』가 23개 패턴을 정리하며 널리 퍼졌다.

  • 집단 코드 소유

    코드의 주인을 개인으로 두지 않고 팀 전체가 코드베이스 전체를 소유해, 누구나 필요한 곳을 고칠 수 있게 하는 XP 실천법.

  • 변경하기 쉬운 프런트엔드 코드

    Frontend Fundamentals는 "좋은 프런트엔드 코드 = 변경하기 쉬운 코드"라는 관점에서 가독성(Readability)·예측 가능성(Predictability)·응집도(Cohesion)·결합도(Coupling) 네 기준과 구체적인 기법을 정리한 공개 가이드다. 네 기준은 서로 부딪치기도 해서 상황에 맞게 무엇을 우선할지 고르는 것이 핵심이다.

보기 옵션