bad smell

리팩토링 공부를 하면서 참고한 서적입니다.

디자인패턴과 리팩토링, 리팩토링(프로그램 가치를 높이는 코드 정리 기술) 한빛 미디어

BAD SMELL

Bad Smell(코드의 나쁜 냄새)의 종류에 대해 알아 보겠습니다.

  • 중복된 코드(Duplicated Code)

    • 기능이나 데이터 코드가 중복된다.
    • Refactoring : 중복을 제거
  • 긴 메소드(Long Method)

    • 메소드의 내부가 너무 긴 경우
    • Refactoring : 메소드를 적정 수준의 크기로 나눠야 한다.
  • 큰 클래스(Large Class)

    • 한 클래스에 너무 많은 속성과 메소드가 존재하는 경우
    • Refactoring : 클래스를 적정 크기로 줄여야 한다.
  • 긴 패러미터 리스트(Long Parameter List)

    • 메소드의 패러미터 개수가 너무 많은 경우
    • Refactoring : 패러미터의 개수를 줄여야 한다.
  • 두 가지 이상의 이유로 수정되는 클래스(Divergent Class)

    • 한 클래스의 메소드가 2가지 이상의 이유로 수정이 되면 그 클래스는 한가지 종류의 책임만을 수행하는 것이 아니다.
    • Refactoring : 클래스가 한 가지 이유만으로 수정되도록 변경해야한다.
  • 여러 클래스를 동시에 수정(Shotgun Surgery)

    • 특정 클래스를 수정하면 그때마다 관련된 여러 클래스들 내에서 자질한 변경을 해야한다.
    • Refactoring : 여러 클래스에 흩어진 유사한 기능을 한 곳에 모이게 해야 한다.
  • 다른 클래스를 지나치게 애용(Feature Envy)

    • 특정 클래스가 메소드를 수행할 때 자신의 속성을 기반으로 처리하기 보다 주로 다른 클래스로부터
      데이터를 얻어와서 기능을 수행한다.
    • Refactoring : 메소드를 그들이 애용하는 데이터가 있는 클래스로 옮긴다.
  • 유사 데이터들의 그룹 중복(Data Clumps)

    • 3개 이상의 데이터들(속성이나 패러미터 리스트)들이 여러곳에 중복되어 나타난다.
    • Refactoring : 해당 데이터들을 독립된 클래스로 정의한다.
  • 기본 데이터 타입 선호(Primitive obsession)

    • 작은 일을 위한 작은 객체를 정의하지 않고, 언어에서 제공하는 기본 데이터 타입만을
      사용하려고 고집한다.
    • Refactoring : 기본 데이터들의 그룹이 의미있는 작업을 수행하면 그들을 별도의 클래스로 만든다.
  • Switch, If 문장(Switch Statements)

    • 지나치게 많은 case를 사용하는 switch 문장은 코드 중복의 신호탄이다.
    • Refactoring : Polymorphism 사용
  • 병렬 상속 계층도(Parallel Inheritance Hierachies)

    • 위의 여러 클래스를 동시에 변경(Shotgun Surgery)하는 것의 특별한 형태로서,
      연관있는 여러 클래스 계층도가 지나치게 많이 생겨 중복을 유발하는 경우.
    • Refactoring : 호출하는 쪽의 계층도는 그대로 유지하고 호출 당하는 쪽을 변경
  • 게으른 클래스(Lazy Class)

    • 특정 클래스가 충분히 일을 하지 않는 경우
    • Refactoring : 제거하거나 다른 클래스에 합병, 만약 하위 클래스가 일을 충분히 하지 않으면
      상속을 없애버린다.
  • 지나친 일반화(Speculative Generality)

    • 지금 당장 필요하지 않은 기능을 위해 일부러 미리 상속관계를 만들어 놓는다.
    • Refactoring : 상속을 없애버린다.
  • 임시 속성(Temporary Field)

    • 클래스의 속성들이 특정 메소드에 의해 특정 순간에 한 두번만 사용되는 임시변수처럼 사용된다.
    • Refactoring : 그들을 사용하는 메소드 내부로 옮긴다.
  • 메시지 체인(Message Chains)

    • 특정 객체를 사용하기 위해 지나치게 많은 클래스들을 거쳐야 한다.
    • Refactoring : 메시지 체인을 거치지 않고 직접 해당 객체를 사용하도록 코드를 변경한다.
  • 미들 맨(Middle Man)

    • 너무 많은 메소드들이 자신의 기능이 단지 다른 객체에게 책임을 위임하는 경우이다.
    • Refactoring : 미들맨 역할을 하는 객체를 제거한다.
  • 부적절한 친밀성(Inappropriate Intimacy)

    • 불필요하게 자신의 정보를 다른 클래스에게 노출하며, 또한 다른 객체에 종속적인 정보를 알아내려하는 것을
      말한다.
    • Refactoring : 다른 클래스가 자신의 래퍼런스를 유지하지 못하도록 하며, 다른 객체의 정보를
      알지 않고 기능을 처리할 수 있도록 변경
  • 미완성된 라이브러리 클래스(Incomplete Library Class)

    • 다른 사람이 만든 라이브러리용 클래스가 자신의 원하는 일을 다 수행하지 못하는 경우이다.
    • Refactoring : 자신이 만드는 클래스와 라이브러리 클래스간에 래핑(Wrapping)클래스를 만들어 연결.
  • 데이터 클래스(Data Class)

    • 특정 클래스가 단순히 속성값을 읽거나 쓰기만 하고 아무일도 하지 않는 경우이다.
    • Refactoring : 만약 다른 클래스의 메소드가 이 클래스의 데이터를 주로 사용한다면, 그 메소드를
      데이터 클래스 안으로 이동시킨다.
  • 유신을 거부함(Refused Bequest)

    • 상위 클래스의 속성과 메소드가 하위 클래스에서 사용되지 않는다.
    • Refactoring : 상위 클래스와 하위 클래스를 합친다.
  • 주석(Comments)

    • 불필요하게 많을 만큼 주석 처리를 하지 않으면 코드를 이해할 수 없기 때문에 주석 처리를 한다.
    • Refactoring : 주석이 없어도 코드를 이해할 수 있도록 소스코드를 변경한다.