맨위로가기

리팩터링

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

리팩터링은 코드의 가독성, 확장성 및 유지보수성을 향상시키기 위해, 소프트웨어의 외부 동작을 변경하지 않으면서 내부 구조를 개선하는 과정을 의미한다. 코드 스멜을 감지하여 중복 코드 제거, 긴 메서드 분할 등 다양한 기법을 적용하며, 기술 부채를 상환하는 주요 수단으로 활용된다. 리팩터링은 예방적 및 수정적 방식으로 수행되며, 기능 추가 전, 코드 리뷰 시, 버그 수정 시에도 권장된다. 리팩터링은 객체 지향 설계와 밀접하게 관련되어 있으며, 자동화된 도구를 통해 지원된다.

2. 리팩터링의 동기 및 이점

리팩터링은 주로 코드 스멜을 감지하는 것에서 시작된다.[13] 예를 들어 메서드가 너무 길거나 다른 메서드와 코드가 중복되는 경우가 대표적이다. 이런 문제를 발견하면, 기존 기능은 동일하게 유지하면서 코드 구조를 개선하고 "스멜"을 제거하기 위해 리팩터링을 수행한다. 긴 코드는 여러 개의 작은 서브루틴으로 나누고, 중복되는 코드는 하나로 합쳐 공유 함수로 만들 수 있다. 리팩터링을 수행하지 않으면 기술 부채가 쌓일 수 있으며, 반대로 리팩터링은 기술 부채를 상환하는 중요한 방법 중 하나이다.[2]

리팩터링은 다음과 같은 두 가지 주요 이점을 제공한다.

# '''유지보수성 향상''': 소스 코드를 읽기 쉽고 작성자의 의도를 파악하기 쉽게 만들어 버그 수정 작업을 용이하게 한다.[3] 이는 크고 복잡한 루틴을 간결하고 목적이 명확한 여러 메서드로 나누거나, 메서드를 더 적절한 클래스로 이동시키고 오해의 소지가 있는 주석을 제거하는 등의 방식으로 달성할 수 있다.

# '''확장성 증대''': 애플리케이션에 인식 가능한 디자인 패턴을 적용하면 코드의 유연성이 높아져 새로운 기능을 추가하거나 변경 사항에 대응하기 쉬워진다.[1]

성능 엔지니어링 관점에서 리팩터링은 소프트웨어 팽창, 즉 개발 시간 단축을 우선시하는 과정에서 발생할 수 있는 프로그램의 비효율성을 제거하는 데 도움을 줄 수 있다. 또한, 특정 하드웨어(예: 병렬 프로세서) 환경에 맞게 소프트웨어 실행을 최적화하는 데 기여하기도 한다.[4]

과거에는 한번 정상적으로 작동하는 프로그램은 다시 수정해서는 안 된다는 인식이 있었다. 수정을 가하면 예상치 못한 문제가 발생하여 프로젝트 전체에 영향을 미칠 수 있다는 우려 때문이었다. 그러나 프로그램에는 필연적으로 변경이 따르며, 개발 과정에서 요구사항이 계속 변하기 때문에 소프트웨어는 항상 변화에 대응할 수 있는 유연성을 갖추어야 한다. 또한 초기 설계만으로는 완벽할 수 없다는 한계도 존재한다.

이러한 배경 속에서 Smalltalk 프로그래머들을 중심으로 평소에 코드를 꾸준히 정리하여 변경에 유연하게 대처하려는 움직임이 나타났고, 이것이 리팩터링 기법으로 발전했다. 워드 커닝햄, 켄트 벡, 랄프 존슨 등이 이 과정에 기여했다. 리팩터링은 프로그램 전체 구조를 파악하는 데도 효과적이며, 코드가 잘 정리되어 있으면 버그 수정도 용이해진다. 리팩터링은 특히 객체 지향 프로그래밍과 밀접하게 연관되어 있으며, 코드 재사용성을 극대화하는 데 기여한다.

리팩터링이 개발 속도를 저해할 것이라는 우려도 있지만, 실제로는 설계 개선을 통해 기능 추가나 버그 수정이 쉬워져 장기적으로 개발 속도가 안정되거나 오히려 빨라지는 경우가 많다. 물론, 절차를 지키고 충분한 테스트를 통해 위험을 관리하는 것이 중요하다.

2. 1. 리팩터링 시점 및 책임

리팩터링은 주로 코드 스멜을 발견하면서 시작된다.[13] 예를 들어, 현재 사용 중인 메서드가 너무 길거나, 근처의 다른 메서드와 거의 중복되는 경우가 해당된다. 이러한 문제를 인지하면, 소스 코드를 리팩터링하여 이전과 동일하게 작동하면서도 더 이상 "스멜"이 나지 않는 새로운 형태로 개선할 수 있다. 리팩터링을 수행하지 않으면 기술 부채가 쌓일 수 있으며, 반대로 리팩터링은 기술 부채를 상환하는 중요한 방법 중 하나이다.[2]

리팩터링을 수행하는 시점은 크게 두 가지로 나눌 수 있다.

# '''예방적 리팩터링''': 코드의 원래 개발자가 아직 코드 스멜이 없는 상태에서 코드를 더 견고하게 만들어 미래의 문제를 예방하는 방식이다.[5]

# '''수정적 리팩터링''': 이후 개발자가 코드 스멜이 발생했을 때 이를 수정하기 위해 리팩터링을 수행하는 방식이다.[5]

이 두 가지 방식의 균형을 맞추기 위한 접근법으로 "리팩터링에 대한 공동 책임"이 있다. 이 방식은 리팩터링 작업을 두 단계와 두 역할로 나눈다. 코드의 초기 개발자는 리팩터링을 위한 준비 작업을 하고, 이후 코드 스멜이 나타나면 다른 개발자가 실제 리팩터링을 수행하는 것이다.[5]

하지만 언제나 리팩터링이 좋은 것은 아니다. 예를 들어, 납기가 임박한 상황에서는 리팩터링을 할 여유가 부족할 수 있다. 리팩터링은 미래를 위한 투자이지만, 당장의 급한 요구사항을 우선해야 할 때도 있다.

마틴 파울러의 저서 『리팩터링』에서는 기능 추가와 리팩터링 작업을 명확히 구분할 것을 권장한다(이를 비유적으로 "구현의 모자를 리팩터링의 모자로 바꿔 쓰다"라고 표현한다). 리팩터링만 계속하면 개발이 진행되지 않으며, 어떤 리팩터링이 필요한지는 개발이 어느 정도 진행되어야 파악할 수 있다. 리팩터링을 시작할 적절한 시점으로는 코드에서 "불길한 냄새"(예: 코드 중복, 긴 메서드, 변경 시 여러 클래스에 영향 등)를 감지했을 때를 제안한다. 또한 기능 추가 전, 코드 리뷰 시, 버그 수정 시에도 리팩터링을 수행하는 것이 좋다.

3. 리팩터링의 어려움 및 과제

리팩터링은 기존 소프트웨어 시스템에 대한 깊은 이해를 필요로 한다.[6] 특히 팀의 인수인계 등으로 인해 시스템의 현재 상태나 이전 개발자가 내린 설계 결정에 대한 정보가 부족하거나 부정확할 경우, 리팩터링을 진행하기 어렵다. 이러한 지식을 복구하기 위해 추가적인 노력이 필요할 수 있다.[7]

리팩터링 과정에서 의도치 않게 소프트웨어 아키텍처가 저하될 수 있다. 이는 유지보수 용이성이나 코드 이해도 같은 아키텍처 속성에 부정적인 영향을 미치며, 심한 경우 시스템을 완전히 재개발해야 하는 상황으로 이어질 수도 있다.[8]

코드 리팩터링 작업은 알고리즘 및 코드 실행 순서에 대한 데이터를 제공하는 도구나 기술을 활용하는 소프트웨어 인텔리전스를 통해 위험을 완화하는 데 도움이 될 수 있다.[9] 시스템 구조, 데이터 모델, 구성 요소 간의 의존성 등을 쉽게 파악할 수 있는 정보는 무엇을 어떻게 수정해야 할지 결정하는 데 중요한 역할을 한다.[10]

과거에는 정상 작동하는 프로그램을 수정하는 것을 꺼리는 경향이 있었다. 수정한 부분으로 인해 예기치 못한 문제가 발생하여 프로젝트 전체에 영향을 미칠 수 있다는 우려 때문이었다. 리팩터링 역시 기능하는 코드를 변경하는 작업이므로, 개발 속도가 일시적으로 정체될 수 있다는 걱정이나 기존 기능에 오류를 발생시킬 위험이 있다는 지적이 있다. 하지만 절차를 준수하고 소프트웨어 테스트를 충분히 수행하면 이러한 위험은 상당 부분 줄일 수 있다. 오히려 장기적으로는 설계 개선을 통해 기능 추가나 버그 수정이 용이해져 개발 속도가 향상되는 경우도 많다.

리팩터링에는 몇 가지 구체적인 과제도 존재한다. 예를 들어, 데이터베이스 스키마를 변경해야 할 경우, 기존 데이터를 새로운 구조로 옮기는 데이터 마이그레이션 작업이 필요하며 이는 시간이 소요될 수 있다. 또한, 클래스 내부뿐만 아니라 외부로 공개된 인터페이스를 변경해야 할 때도 있다. 만약 해당 인터페이스가 널리 사용되고 있다면, 하위 호환성을 위해 기존 인터페이스와 새로운 인터페이스를 함께 유지 관리해야 하는 부담이 생길 수 있다. 때로는 수정해야 할 코드의 상태가 너무 좋지 않아, 리팩터링하는 것보다 새로 작성하는 것이 더 효율적일 수도 있다. 리팩터링은 계속 발전하는 분야이므로 앞으로 또 다른 과제가 나타날 가능성도 있다.

4. 리팩터링 테스트

자동 단위 테스트는 리팩터링을 시작하기 전에 설정되어야 한다. 이는 리팩터링 후에도 각 부분이 원래 의도대로 작동하는지 확인하기 위함이다.[11] 단위 테스트는 리팩터링 작업을 원자적 커밋으로 관리할 때, 특히 규모가 큰 변경에서도 안정성을 보장하는 데 중요한 역할을 한다.[12]

단위 테스트가 마련되면, 리팩터링은 작은 단위의 코드 변경을 수행하고, 변경된 코드가 정확히 작동하는지 테스트하고, 다시 다음 변경을 진행하는 반복적인 과정이 된다. 만약 테스트 과정에서 오류가 발견되면, 마지막에 수행한 작은 변경 사항을 되돌리고 다른 방식으로 접근한다. 이러한 작은 단계들을 반복하며 프로그램을 점진적으로 개선해 나간다. 이러한 반복적인 과정을 효율적으로 수행하려면 테스트 실행 속도가 매우 빨라야 한다. 그렇지 않으면 개발자는 테스트 완료를 기다리는 데 많은 시간을 소모하게 된다. 익스트림 프로그래밍이나 다른 애자일 소프트웨어 개발 방법론에서는 이러한 리팩터링과 테스트 과정을 소프트웨어 개발 주기의 핵심적인 부분으로 여긴다.

리팩터링 과정에서는 프로그램의 겉으로 드러나는 기능이나 동작 방식(외관)을 변경해서는 안 된다. 따라서 테스트의 역할이 매우 중요하다. 코드 수정은 점진적이고 세밀하게 이루어져야 하며, 아주 작은 변경이 있을 때마다 테스트를 실행하여 혹시 발생할 수 있는 문제를 가능한 한 빨리 발견해야 한다. 테스트 없이 한 번에 많은 부분을 리팩터링하면, 프로그램의 동작이 의도치 않게 변경되었을 때 그 원인을 찾아내기 매우 어려워진다. 프로그래머가 테스트를 소홀히 하지 않도록 xUnit이나 JUnit처럼 간편하게 테스트를 실행할 수 있는 자동화 도구의 지원이 중요하다. 테스트를 중시하는 이러한 접근 방식은 애자일 소프트웨어 개발 방법론 중 테스트 주도 개발(TDD)의 핵심 철학과도 일치한다.

5. 리팩터링 기법

리팩터링은 주로 코드 스멜을 발견하는 것에서 시작된다.[13] 예를 들어, 현재 사용 중인 메서드가 너무 길거나 다른 메서드와 거의 중복되는 경우가 있다. 이런 문제를 발견하면, 소스 코드를 리팩터링하여 기존과 동일하게 작동하면서도 더 이상 코드 스멜이 나지 않는 새로운 형태로 개선할 수 있다.

긴 코드는 하나 이상의 작은 서브루틴으로 추출하고, 중복된 코드는 중복을 제거하고 하나의 공유 함수로 대체하는 방식으로 리팩터링을 진행한다. 리팩터링을 하지 않으면 기술 부채가 쌓일 수 있으며, 반대로 리팩터링은 기술 부채를 해결하는 중요한 방법 중 하나이다.[2]

마틴 파울러의 저서[13]와 웹사이트[14] 등에서는 다양한 리팩터링 기법들이 소개되어 있다. 이러한 기법들은 크게 코드의 추상화 수준을 높이거나, 코드를 논리적인 단위로 나누거나, 코드의 이름과 위치를 개선하는 방식으로 분류할 수 있다. (자세한 내용은 '변환' 섹션 참조)

주요 리팩터링 기법은 다음과 같다.


  • '''메서드 추출''': 너무 긴 메서드는 재사용하기 어렵다. 메서드를 더 작은 단위로 추출하고 세분화하면 재사용성이 높아지고, 해당 메서드를 호출하는 코드도 더 읽기 쉬워진다. 처리 과정의 중복도 줄일 수 있다.
  • '''양방향 연관을 단방향으로 변경''': 불필요한 참조 관계는 관리를 어렵게 만들고, 객체가 제대로 소멸되지 못하게 할 수 있다. 필요 없어진 연관 관계는 제거하는 것이 좋다.
  • '''클래스 추출''': 너무 많은 역할을 하는 클래스는 분할한다. 클래스를 작게 만들면 해당 클래스의 책임과 역할이 명확해진다.
  • '''switch 문을 다형성으로 대체''': switch 문 대신 다형성을 사용하면, 새로운 조건이 추가되더라도 기존의 분기 코드를 수정할 필요가 없어진다.
  • '''멤버 이동''': 필드나 메서드가 적합하지 않은 클래스에 있으면, 다른 클래스와의 불필요한 연관성이 늘어난다. 멤버를 적절한 클래스로 이동시켜 클래스의 책임을 명확히 한다.
  • '''상속을 위임으로 대체''': 상속은 부모 클래스의 모든 멤버를 자식 클래스가 물려받게 된다. 부모 클래스의 일부 기능만 필요하다면, 상속 대신 위임을 사용하는 것이 더 적절할 수 있다.
  • '''다운캐스팅을 캡슐화''': 다운캐스팅은 호환되지 않는 타입으로 변환될 위험이 있으며, 이를 컴파일 시점에 발견하기 어렵다. 제네릭(템플릿) 기능이 없는 언어에서는 다운캐스팅 로직을 캡슐화하여 외부 코드에서 직접 다운캐스팅하는 수고를 줄이는 것이 좋다. 특히 컬렉션 클래스 등에서 유용하다.
  • '''생성자를 팩토리 메서드로 대체''': 일반적인 생성자는 해당 클래스의 객체만 반환할 수 있다. 팩토리 메서드를 사용하면 객체 생성 과정을 더 유연하게 제어할 수 있다.
  • '''인자 객체 도입''': 여러 개의 데이터가 항상 함께 전달된다면, 이들을 하나의 객체로 묶어서 전달하는 것이 코드를 이해하기 쉽게 만들 수 있다.


또한, 심볼(클래스명, 함수명, 변수명 등)이 가리키는 대상을 더 명확하게 나타내도록 이름을 변경하는 심볼 이름 변경(리네임)도 중요한 리팩터링 기법이다. 심볼 이름은 대상의 역할을 정확하게 설명해야 한다(참고: 명명 규칙 (프로그래밍)). 프로그램이 변경되면서 처음에는 적절했던 이름이 더 이상 그렇지 않게 될 수 있는데, 이때 리네임을 수행한다. 최근의 많은 개발 환경에서는 여러 파일에 걸쳐 심볼 이름을 한 번에 변경하는 기능을 지원하여(예: VSCode의 F2 키[32]), 리네임 작업이 훨씬 수월해졌다.

많은 통합 개발 환경(IDE)에서는 이러한 기본적인 리팩터링 기법들을 자동화된 기능으로 제공한다. 예를 들어, 프로그래머는 변수 이름을 클릭하고 컨텍스트 메뉴에서 "필드 캡슐화" 리팩터링을 선택할 수 있다. IDE는 필요한 정보를 묻고 코드 변경 사항을 미리 보여준 후, 확인을 받으면 코드 전체에 걸쳐 필요한 변경을 자동으로 수행해 준다.

5. 1. 정적 분석

정적 프로그램 분석은 유효하지만 기준에 미달하는 프로그램의 문제를 감지하는 분석 방법이다. 덜 엄격한 인터프리터 언어에서 수행될 때는 "린팅"이라고도 불린다. 정적 분석과 관련된 주요 개념은 다음과 같다.

  • 프로그램 의존성 그래프: 데이터 및 제어 의존성을 명시적으로 표현한다.[15]
  • 시스템 의존성 그래프: 프로그램 의존성 그래프 간의 프로시저 호출을 표현한다.[16]
  • 사이클로매틱 복잡도 분석
  • 소프트웨어 인텔리전스: 기존 애플리케이션 내의 의존성을 파악하기 위해 초기 상태를 역설계하는 방식이다.

5. 2. 변환

프로그램의 구문 표현을 수정하는 것을 변환이라고 한다. 일부 수정은 프로그램의 유연성이나 견고성을 향상시키는 방식으로 프로그램의 의미 또는 구조를 변경한다. 이러한 수정에는 문제 도메인 및 의도된 논리에 대한 지식이 필요하므로 자동화하는 것은 불가능하다. 프로그램을 읽고 수정하기는 더 쉽게 만들지만 프로그램의 기본 논리를 변경하지 않는 수정 사항도 있으며, 이러한 변환은 자동화할 수 있다.

  • 더 많은 추상화를 허용하는 기술
  • 필드 캡슐화: 게터(getter) 및 세터(setter) 메서드를 사용하여 필드에 접근하도록 코드를 강제한다.
  • 유형 일반화: 더 많은 코드 공유를 허용하기 위해 보다 일반적인 유형을 생성한다.
  • 유형 검사 코드를 상태/전략 패턴으로 대체한다.[17]
  • 조건문을 다형성으로 대체한다.[18]
  • 코드를 더 논리적인 조각으로 나누는 기술
  • 컴포넌트화: 명확하고 잘 정의되고 사용하기 쉬운 인터페이스를 제공하는 재사용 가능한 의미 단위로 코드를 분해한다.
  • 클래스 추출: 기존 클래스의 일부 코드를 새 클래스로 이동한다.
  • 메서드 추출: 더 큰 메서드의 일부를 새 메서드로 바꾼다. 코드를 더 작은 조각으로 나누면 이해하기가 더 쉬워진다. 이것은 또한 함수에도 적용된다.
  • 코드의 이름과 위치를 개선하는 기술
  • 메서드 이동 또는 필드 이동: 더 적절한 클래스 또는 소스 파일로 이동한다.
  • 메서드 이름 바꾸기 또는 필드 이름 바꾸기: 이름을 목적을 더 잘 드러내는 새 이름으로 변경한다.
  • 끌어올리기: 객체 지향 프로그래밍 (OOP)에서 수퍼클래스로 이동한다.
  • 밀어내기: OOP에서 서브클래스로 이동한다.[14]
  • 자동 클론 감지: 중복된 코드를 자동으로 찾아내는 기술이다.[19]

6. 하드웨어 리팩터링

원래 소프트웨어 코드에만 사용되던 "리팩터링"이라는 용어는 최근 몇 년 동안 하드웨어 기술 언어(HDL)로 작성된 코드에도 적용되고 있다. "하드웨어 리팩터링"은 하드웨어 기술 언어로 작성된 코드를 개선하는 작업을 간략하게 표현하는 용어로 사용된다. 하지만 대부분의 하드웨어 엔지니어들은 하드웨어 기술 언어를 프로그래밍 언어와는 다르다고 생각하기 때문에,[20] 하드웨어 리팩터링은 전통적인 코드 리팩터링과는 별개의 분야로 여겨진다.

Zeng과 Huss는 아날로그 하드웨어 기술 언어(VHDL-AMS) 코드의 자동 리팩터링 방법을 제안했다.[21] 이 접근 방식에서 리팩터링은 하드웨어 설계의 시뮬레이션된 동작을 그대로 보존하면서 코드를 개선하는 것을 목표로 한다. 이렇게 개선된 코드는 표준 합성 도구로 처리될 수 있지만, 원본 코드는 그렇지 못하다는 장점이 있다. 디지털 하드웨어 기술 언어의 리팩터링은 시놉시스(Synopsys)의 펠로우인 마이크 키팅(Mike Keating)에 의해 연구되었는데, 이는 주로 수동 리팩터링 방식이다.[22][23] 그의 목표는 복잡한 시스템을 더 쉽게 이해할 수 있도록 만들어 설계자의 생산성을 향상시키는 것이다.

7. 리팩터링의 역사

"리팩터링"이라는 용어가 공식적으로 문헌에 처음 등장한 것은 1990년 9월 윌리엄 옵다이크와 랄프 존슨이 발표한 논문이다.[24][33] 물론 컴퓨터 코드를 개선하는 작업 자체는 이전부터 비공식적으로 이루어져 왔지만, 리팩터링에 대한 주요 학술 연구는 1990년대 초에 본격화되었다. 윌리엄 그리스월드의 1991년 박사 학위 논문은 함수형 프로그래밍과 절차적 프로그래밍에서의 리팩터링을 다룬 초기 연구 중 하나이며,[25][34] 이듬해인 1992년에는 윌리엄 옵다이크가 객체 지향 프로그래밍에서의 리팩터링에 대한 박사 학위 논문을 발표했다.[26][27][35][36] 이러한 연구들은 리팩터링을 수행하는 구체적인 방법들과 각 방법을 언제 적용해야 하는지에 대한 지침을 제시했다. 리팩터링의 기반이 되는 이론이나 기법 중 일부는 오랫동안 프로그램 변환 시스템 분야에서 연구되어 온 것들이기도 하다.

한편, "팩토링(factoring)" 또는 "팩토링 아웃(factoring out)"이라는 용어는 적어도 1980년대 초부터 포스 프로그래밍 커뮤니티에서 비슷한 의미로 사용되었다. 레오 브로디는 그의 저서 ''씽킹 포스''(1984)의 한 장을 할애하여 이 개념을 설명하기도 했다.[28] 이는 익스트림 프로그래밍에서 말하는 'Extract Method' 기법과 유사하게, 큰 함수를 더 작고 관리하기 쉬운 여러 개의 함수로 나누는 작업을 의미한다.

리팩터링이라는 개념이 주목받기 전에는, 일단 정상적으로 작동하는 프로그램은 가급적 다시 수정하지 않는 것이 일반적인 관행이었다. 코드를 잘못 수정하면 예상치 못한 문제가 발생하여 연쇄적인 수정 작업으로 이어질 수 있고, 결국 프로젝트 전체에 영향을 미칠 수 있다는 우려 때문이었다. 또한, 충분한 소프트웨어 테스트를 거쳐 안정성이 확인된 프로그램을 조금이라도 변경하면, 이후 버그가 발생했을 때 변경된 부분이 원인으로 지목될 가능성이 높았다.

하지만 현실적으로 프로그램 개발 과정에서 요구사항 변경은 불가피하며, 시간이 지남에 따라 코드는 점점 복잡해지고 유지보수가 어려워지는 경향이 있다. 초기 설계가 완벽하기 어렵고, 개발 중에도 새로운 요구사항이 계속 추가되기 때문에 소프트웨어는 변화에 유연하게 대응할 수 있어야 한다. 이러한 배경 속에서, Smalltalk 프로그래머들을 중심으로 코드를 지속적으로 정리하고 개선하여 변경에 쉽게 대응할 수 있도록 하자는 움직임이 나타났다. 워드 커닝햄, 켄트 벡, 랄프 존슨 등은 이러한 리팩터링 기법을 발전시키는 데 중요한 역할을 했다.

마틴 파울러가 저술한 ''리팩터링: 기존 코드의 설계 개선''은 리팩터링 분야의 대표적인 참고 서적으로 꼽힌다.

리팩터링은 특히 객체 지향 설계와 밀접한 관련이 있다. 많은 리팩터링 기법들이 객체 지향의 특성을 활용하며, 코드의 재사용성을 높이는 데 기여한다. 객체 지향 프로그래밍을 지원하는 언어라면 종류에 상관없이 리팩터링을 적용할 수 있다.

리팩터링을 수행하면 당장의 기능 개발이 늦어지는 것이 아니냐는 우려도 있다. 실제로 리팩터링 작업 자체는 새로운 기능을 추가하는 것은 아니다. 그러나 장기적으로는 코드 구조 개선을 통해 기능 추가나 버그 수정이 용이해져 개발 속도가 안정되거나 오히려 빨라지는 경우가 많다. 또한, 이미 작동 중인 코드를 변경하는 것에 대한 위험 부담도 있지만, 정해진 절차를 따르고 충분한 테스트를 병행한다면 위험을 상당 부분 줄일 수 있다. 리팩터링은 복잡한 소스 코드를 이해하고 수정하는 데 도움을 주며, 개발자가 코드 개선에 보다 적극적으로 참여하도록 유도하는 효과도 있다. 일부에서는 리팩터링이 설계의 부족한 부분을 보완하고, 초기 설계를 간소화하는 역할도 할 수 있다고 본다.

리팩터링은 버전 관리 시스템(예: CVS, SVN)에 기록된 복잡한 변경 이력을 이해하기 쉽게 재구성하는 데에도 활용될 수 있다.[29]

8. 자동화된 코드 리팩터링 도구

많은 소프트웨어 텍스트 편집기 및 통합 개발 환경(IDE)은 자동화된 리팩터링 기능을 지원한다. 주요 도구 목록은 다음과 같다.

참조

[1] 서적 Refactoring to Patterns Addison Wesley
[2] 서적 Refactoring for Software Design Smells Morgan Kaufmann 2014-11
[3] 서적 Clean Code Prentice Hall
[4] 간행물 There's plenty of room at the Top: What will drive computer performance after Moore's law?
[5] 간행물 Language Support for Refactorability Decay Prevention 2022
[6] 간행물 A Framework for the Assessment and Training of Software Refactoring Competences 2019
[7] 간행물 Revisiting Turnover-Induced Knowledge Loss in Software Projects 2017-11
[8] 간행물 Design erosion: problems and causes 2002-03
[9] 간행물 Software intelligence: the future of mining software engineering data 2010-11
[10] 간행물 Experimentally assessing the combination of multiple visualization strategies for software evolution analysis 2017
[11] 서적 Refactoring : improving the design of existing code https://archive.org/[...] Addison-Wesley 1999
[12] 서적 Java Power Tools https://books.google[...] "O'Reilly Media, Inc." 2018-07-26
[13] 서적 Refactoring. Improving the Design of Existing Code https://archive.org/[...] Addison-Wesley
[14] 웹사이트 Refactoring techniques in Fowler's refactoring Website http://refactoring.c[...]
[15] 간행물 The program dependence graph and its use in optimization ACM 1987-07
[16] 간행물 Slicing objects using system dependence graphs IEEE 2008-11
[17] 웹사이트 Replace type-checking code with State/Strategy http://refactoring.c[...]
[18] 웹사이트 Replace conditional with polymorphism http://refactoring.c[...]
[19] 간행물 An evaluation of clone detection techniques for crosscutting concerns IEEE 2004
[20] 문서 Hardware description languages#HDL and programming languages
[21] 문서 Kaiping Zeng, Sorin A. Huss, "Architecture refinements by code refactoring of behavioral VHDL-AMS models". ISCAS 2006
[22] 웹사이트 M. Keating :"Complexity, Abstraction, and the Challenges of Designing Complex Systems", in DAC'08 tutorial http://www.dac.com/e[...]
[23] 서적 M. Keating, P. Bricaud: Reuse Methodology Manual for System-on-a-Chip Designs Kluwer Academic Publishers
[24] 간행물 Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems ACM 1990-09
[25] 간행물 Program Restructuring as an Aid to Software Maintenance http://cseweb.ucsd.e[...] University of Washington 2011-12-24
[26] 간행물 Refactoring Object-Oriented Frameworks http://dl.acm.org/ci[...] University of Illinois at Urbana-Champaign 2008-02-12
[27] 웹사이트 Martin Fowler, "MF Bliki: EtymologyOfRefactoring" http://martinfowler.[...]
[28] 서적 Thinking Forth http://thinking-fort[...] Fig Leaf Press, Forth Interest 2020-05-03
[29] 뉴스 What is code refactoring? https://duecode.io/b[...]
[30] 웹사이트 What's new in Xcode 9 https://developer.ap[...]
[31] 웹사이트 Overview {{!}} Qt Creator Documentation https://doc.qt.io/qt[...]
[32] 웹사이트 Visual Studio Code - USER GUIDE - Refactoring - Rename Symbol https://code.visuals[...]
[33] 문서 Opdyke , Johnson
[34] 문서 Griswold
[35] 문서 Opdyke
[36] 서적
[37] 웹사이트 What's new in Xcode 9 https://developer.ap[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com