반응형

리팩터링/냄새 (리팩터링할 시점) 14

냄새 14. 성의 없는 요소(Lazy Element)

성의 없는 요소(Lazy Element)는 프로그램에서 사용하지 않는 코드 또는 기능을 가리키는 코드 냄새 중 하나입니다. 이러한 코드는 작성 시 개발자가 과거 또는 현재의 개발자가 아닌 미래의 다른 개발자들을 위해 만드는 것이 좋습니다. 성의없는 요소는 코드의 복잡도를 증가시키고, 유지보수와 확장성을 어렵게 만듭니다. 또한 이러한 코드는 프로그램의 실행 속도를 늦출 수 있습니다. 성의없는 요소를 제거하는 방법 중 하나는, 불필요한 코드를 제거하고 단순하게 유지보수할 수 있는 코드로 수정하는 것입니다. 이러한 작업은 코드 리팩터링 과정에서 수행됩니다. 예를 들어, 사용하지 않는 변수나 함수를 제거하거나, 중복된 코드를 제거하거나, 불필요한 주석을 제거하는 등의 작업이 이에 해당합니다. 또 다른 방법으로는..

냄새 13. 반복문(Loops)

반복문(Loops)을 사용하는 것이 코드 작성의 효율성을 높일 수 있지만, 반복문이 중첩되거나 복잡한 조건문과 함께 사용되는 경우 코드의 복잡성이 증가하고 코드를 이해하기 어려워질 수 있습니다. 반복문의 문제점 중 하나는 다른 로직과 함께 사용되는 경우 유지보수성이 낮아질 수 있다는 것입니다. 예를 들어, 아래의 코드에서 반복문은 사이즈를 계산하고, 각 색상의 평균값을 계산하는 두 가지 다른 로직과 함께 사용됩니다. int size = 0; double redSum = 0.0; double greenSum = 0.0; double blueSum = 0.0; for (int i = 0; i < pixels.size(); ++i) { size++; redSum += pixels[i].red(); greenS..

냄새 12. 반복되는 switch문(Repeated Switches)

반복되는 switch문(Repeated Switches)은 여러 개의 switch 문이 동일한 조건식을 검사하는 경우를 말합니다. 예를 들어, 다음과 같은 코드를 생각해보겠습니다. void processAnimalSound(Animal* animal) { switch (animal->getType()) { case AnimalType::CAT: // process cat sound break; case AnimalType::DOG: // process dog sound break; case AnimalType::COW: // process cow sound break; default: // process default sound break; } } void processAnimalMovement(Anim..

냄새 11. 기본형 집착(Primitive Obsession)

기본형 집착(Primitive Obsession)은 객체 지향 언어에서 자주 나타나는 코드 냄새 중 하나입니다. 기본형 집착은 프로그래머가 객체를 사용하기보다 기본형 데이터 타입(정수, 문자열, 부동 소수점 등)을 사용하여 비즈니스 로직을 구현하도록 유도하는 코드 구조를 의미합니다. 기본형 집착은 코드의 가독성과 유지보수성을 저해하며, 프로그램의 일관성과 안정성을 감소시킬 수 있습니다. 예를 들어, 각 사용자의 나이를 저장하는 경우, 기본적으로 나이를 int 형으로 저장할 수 있습니다. 그러나 이는 유효한 나이 값만이 저장된다는 보장이 없으므로 나이 값이 음수일 수 있거나 매우 큰 값이 될 수 있습니다. 이러한 문제를 해결하기 위해 객체를 사용할 수 있습니다. 나이를 나타내는 Age 클래스를 정의하면 유..

냄새 10. 데이터 뭉치(Data Clumps)

데이터 뭉치(Data Clumps)는 코드에서 같은 데이터 집합이 여러 곳에서 사용되는 경우를 가리키는 냄새입니다. 이러한 데이터 뭉치는 흔히 다음과 같은 형태로 나타납니다. Class Employee { public: Employee(string inName, string inEmployeeAreaCode, string inEmployeeNumber) :_name(inName), _employeeAreaCode(inEmployeeAreaCode), _employeeNumber(inEmployeeNumber) {} string GetEmployeePhoneNumber() { return _employeeAreaCode + "-" + _employeeNumber; } private: string _empl..

냄새 9. 기능 편애(Feature Envy)

기능 편애(Feature Envy)는 어떤 메소드가 자신이 속한 클래스가 아닌 다른 클래스의 메소드나 데이터를 자주 호출할 때 발생하는 코드 냄새(code smell)입니다. 즉, 메소드가 다른 클래스의 기능에 너무 의존적이어서, 해당 메소드가 다른 클래스에 더 적합하게 위치할 수 있는지를 고민해봐야 하는 경우입니다. 기능 편애는 두 개의 클래스 간에 너무 많은 상호작용이 일어나는 것으로 보통 인식됩니다. 이러한 경우 해당 클래스들은 결합도(coupling)가 높아져서 코드의 재사용성, 유지보수성, 확장성이 떨어지게 됩니다. 또한, 한 클래스가 다른 클래스의 많은 기능을 사용하게 되면, 코드 일관성이 떨어지고, 클래스의 책임을 명확하게 분리하지 못하게 됩니다. 기능 편애는 보통 다음과 같은 문제를 유발할..

냄새 8. 산탄총 수술(Shotgun Surgery)

산탄총 수술(Shotgun Surgery)는 하나의 변경으로 여러 개의 클래스를 수정해야 하는 코드 구조를 의미합니다. 즉, 특정한 기능을 추가하거나 수정하기 위해 여러 클래스의 코드를 일일이 수정해야 하는 경우를 말합니다. (산탄총 처럼 넓게 퍼져서 여러군대 수술이 필요한 상황) 이러한 코드 구조는 유지보수성을 나쁘게 하고, 수정 작업이 너무 복잡해지며, 실수할 가능성도 높아집니다. 이를 방지하기 위해서는 관련된 기능들을 하나의 클래스로 추출하거나, 중복 코드를 제거하는 등의 방법을 사용하여 코드 구조를 개선할 필요가 있습니다. 적용 가능한 리팩터링 기법 함수 옮기기 (Move Function) 필드 옮기기 (Move Field) 여러 함수를 클래스로 묶기 (Combine Functions into C..

냄새 7. 뒤엉킨 변경(Divergent Change)

뒤엉킨 변경(Divergent Change)은 하나의 클래스나 모듈이 너무 많은 변화를 겪는 상황을 말합니다. 클래스가 어떤 변경 사항이 있을 때마다 여러 부분에서 수정이 일어나야 한다면, 그 클래스는 뒤엉킨 변경에 빠져 있다고 볼 수 있습니다. 뒤엉킨 변경은 소프트웨어의 유지보수성을 저해하는 요인 중 하나입니다. 한 클래스나 모듈이 변경될 때마다 여러 곳에서 수정이 필요하다면, 그 코드의 수정 작업이 복잡해지고 오류가 발생하기 쉬워집니다. 이는 코드를 이해하기 어렵게 만들어 개발자의 생산성을 저해합니다. 뒤엉킨 변경을 해결하기 위해서는 단일 책임 원칙(Single Responsibility Principle)을 적용하여 각 클래스나 모듈이 하나의 책임을 가지도록 설계해야 합니다. 또한, 추상화를 적극적..

냄새 6. 가변 데이터 (Mutable Data)

가변 데이터(Mutable data)는 값이 변경될 수 있는 데이터를 의미합니다. 이는 데이터가 동시에 여러 곳에서 변경될 가능성이 높아져 코드를 이해하고 유지보수하기 어렵게 만들며, 오류의 가능성도 높아집니다. 이러한 문제를 해결하기 위해서는 불변성(Immutability)을 지향해야 합니다. 즉, 값을 변경하는 대신 새로운 값을 반환하도록 구현하면 됩니다. 이를 통해 코드 유지 보수성이 향상되며, 동시성 이슈 등 다른 문제들을 예방할 수 있습니다. 가변 데이터를 캡슐화하여 객체로 만들고, 값을 사용할 때는 불변 객체를 반환하여 데이터 변경에 대한 책임을 객체 내부에 캡슐화하는 것입니다. 그리고 전역 변수의 사용을 최소화하고, const를 적극 활용하여 불변성을 보장하는 것이 좋습니다. 불변 데이터를 ..

냄새 5. 전역 데이터 (Global Data)

전역 데이터는 프로그램 전체에서 공유되는 데이터를 의미합니다. 전역 변수, 전역 상수, 싱글턴 인스턴스, 레지스트리 항목 등이 포함될 수 있습니다. 전역 데이터는 여러 모듈에서 자유롭게 접근할 수 있기 때문에 모듈 간 결합도가 높아지고, 코드의 복잡도가 증가하며, 디버깅이 어려워질 수 있습니다. - 전역 데이터는 아무곳에서나 변경될 수 있다. - 전역 데이터로 문제가 발생 시 어떤 코드로 인해 값이 바뀐 것인지 알기 어렵다. - 클래스 맴버 변수도 비슷한 문제가 발생 할 수 있다. 또한 전역 데이터가 변경될 경우 해당 데이터를 사용하는 모든 코드를 수정해야 하므로 유지보수성도 저하될 수 있습니다. 전역 데이터를 사용하지 않고 지역 변수나 매개변수로 데이터를 전달하거나 객체지향 설계 원칙 중 하나인 의존성..

반응형