Refactoring

Refactory
리팩터리란 공장을 다각적으로 진단하여 전체적인 공장의 경쟁력 수준을 평가해 문제점을 제시하고 이에 대한 해결방안을 찾아 공장의 경쟁력 수준을 높이는 것이다. 구체적으로 공장의 발전 수준을 5단계로 구분하여 공장의 현재 상태를 진단하고 앞으로 공장이 나갈목표 단계를 설정, 계획적이고 체계적으로 공장을 혁신시키는 진단 프로그램이다. 평가항목은 공정개선, 품질경영, 작업개선, 사기 등 모두 10개로 이들 항목에 대한 정밀조사로 공장내 부문별 부조화를 제거하고 다음단계 목표에 나서게 된다. 

출처 - 네이버

소프트웨어 공학에서 리팩토링(refactoring)은 주로 '결과의 변경 없이 코드의 구조를 재조정함'을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다. 버그를 없애거나 새로운 기능을 추가하는 행위는 아니다. 사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다.

마틴 파울러의 저서 《리팩토링》에 다양한 리팩토링 패턴들이 정리되어있다. 그 중 대표적인 것 몇 가지를 들자면, 필드 은닉, 메소드 추출, 타입 일반화, 메소드 이름 변경 등이 있다.

 리팩토링 (refactoring)은 컴퓨터 프로그래밍 에서 프로그램 외부에서 본 동작을 바꾸지 않고 소스 코드 의 내부 구조를 구성한다. 어떤 리팩토링 기법의 총칭으로서 사용된다. 충분히 확립된 기술은 말할 수 없으며, "리팩토링"단어에 정확한 정의가있는 것은 아니다.

목차   [ 숨기기 ]  1 리팩토링 등장 경위와 목적 2 주요 리팩토링 3 리팩토링을 할 타이밍 4 테스트의 중요성 5 리팩토링 과제 6 통합 개발 환경의 리팩토링 기능 7 관련 항목 8 참고 문헌

리팩토링 등장 경위와 목적 [ 편집 ]

리팩토링이 등장하기 전에는 일단 정상적인 작동을하는 프로그램 은 다시 닿으 안된다라고했다. 섣불리 손을 넣어 동작이 바뀌어 버리면, 이에 따라 관련 부분에 수정이 가해 곧 수정 프로젝트 전체에 파급 대처할 수 없게 될지도 모른다. 또한 소프트웨어 테스팅 을 충분히하고 정상적인 동작이 확인 되더라도 해당 프로그램을 조금이라도 변경하면 버그 (결함)이 발견되면 수정이 프로그램을 의심해야한다.

그러나 프로그램에는 반드시 변화가 있고 프로그램은 다만 누더기 투성이가되는 것은 불가피하다. 사양 개발 시작부터 확정되어있는 것은 적고, 개발을하고있는 동안에도 소프트웨어 에 대한 요구는 나날이 계속 변하고 있으며, 소프트웨어는 항상 사양 변경에 대응할 수있는 유연성이 요구된다. 또한 아무리 엄격하게 디자인해서 실제로 작동시키지 않으면 모르는 부분도 많고, 완벽한 설계를 실시하는 것은 불가능하다. 변경이 필요할 때 다시 손을 대지 못할 정도 복잡하게 된 소스 코드 를 수정하는 것은 곤란하고, 프로그래머 도 매우 용기가 요구되는 작업이다.

그래서 Smalltalk 프로그래머 등 사이에 평소부터 프로그램을 정리 사양 변경에도 대응할 수있는 정리 프로그램을 써 나갈 생각이 태어났다. 이 과정은 워드 커닝햄 , 켄트 벡 , 랄프 존슨 ( GoF 의 한 명) 등의 사람들이 큰 역할을했다. 이 기법을 리팩토링이라고있다. 또한 리팩토링은 프로그램의 전모를 파악하기 위해서도 효과적이다.버그를 발견했을 때도 소스 코드가 정리되고 있기 때문에 수정하다. 프로그래머로 평소 수정하는 코드에 다시 손을 넣는 것만 때문에 수정도 적극적으로 될 수있다. 또한 설계자는 설계 오류로 인한 아쉬움을 없앨 수있다. 디자인의 대체도된다고하는 의견도 사전 설계를 매우 단순화하는 역할도 가진다.

리팩토링은 객체 지향 디자인과 깊이 관련되어있다. 리팩토링의 대부분은 객체 지향의 성질에 따른 것이며, 객체 지향 코드 재사용 성을 극대화할 수있다. 객체 지향 프로그래밍을 할 수있는 언어라면 프로그래밍 언어 의 종류에 관계없이 리팩토링을 적용할 수있다.

리팩토링을 수행함으로써 개발이 정체되어 버리는 것은 아닌가하는 걱정을하는 경우도 많다. 리팩토링을 수행하는 동안 아무런 기능 추가도 행해지지 않는다. 그러나 대부분의 경우 디자인이 향상하는 것으로 기능 추가 및 버그 수정을하기 쉽고, 개발 속도는 안정뿐만 아니라, 빨리 될 수도있다. 또한 이미 작동하는 코드를 위태롭게한다 없다고하는 의견도 있지만, 절차를 준수 테스트를 많이 사용하면 어느 정도 위험을 줄일 수있다.

주요 리팩토링 [ 편집 ]

메서드 추출

너무 메서드는 재사용성이 낮다. 메서드를 추출, 분할함으로써 재사용성이 높아지고, 호출 메소드의 내용도 읽기 쉽게된다. 처리 중복도 줄어든다.

양방향 연관을 단 방향으로 변경

불필요한 참조 관리를위한 수고를 늘리고 개체 의 삭제를 실패한다. 필요없는 연관 지운다.

클래스 추출

너무 자라 클래스를 분할한다. 클래스를 작게하는 것으로 그 클래스의 역할을 명확하게있다.

switch 문장 을 다형성 으로 교체

switch 문을 다형성로 대체하여 새로운 조건이 추가되어도 분기 부분은 변경할 필요가 없어진다.

멤버 이동

필드 및 메서드가 잘못된 클래스의 경우, 다른 클래스와 불필요한 관련이 늘어난다. 멤버를 이동하여 클래스의 책임을 구성합니다.

상속 을 위임 으로 대체

상속에서는 기본 클래스의 모든 멤버를 하위 클래스로 용서해야한다. 기본 클래스의 부분 기능을 이용하면 상속 대신 위임을 사용한다.

다운 캐스트 를 캡슐 화 한다

다운 캐스팅은 호환되지 않는 형식으로 변환시킬 수 있지만, 그것을 컴파일시 감지 할 수 없다. 일반 유형 ( 템플릿 )이없는 언어는 캡슐화하고 클라이언트 다운 캐스트의 수고를 줄일 수 있도록한다. 컬렉션 클래스 등으로 특히 필요합니다.

생성자를 Factory Method 로 대체

생성자는 해당 클래스의 개체를 반환할 수 밖에 없다. Factory Method의 소개로 유연한 인스턴스 화가 가능하게된다.

인수 개체의 도입

종종 함께 전달되는 여러 값을 개체로 정리한 것이 알기 쉽다.

클래스 메소드 속성의 이름을 변경하려면

클래스 이름과 메서드 이름과 속성 이름은 해당 클래 스나 메소드의 역할을 정확하게 설명합니다 할 필요가있다. 명칭이 잘못된 것이거나, 애매한 것이다 때는 명칭의 변경이 행해진다. 종종 처음에는 제대로였다 명칭도 다른 리팩토링 실행 후 적절한 분실될 수있다. 이 때는 계속 이름 변경 리팩토링을 수행하는 (⇒ 명명 규칙 (프로그래밍) ).

마틴 파울러 같은 사람이 쓴 리팩토링 해설서, "리팩토링 프로그래밍의 체질 개선 기술"(이하 "리팩토링")에서는 70여 가지의 리팩토링을들 수있다.

리팩토링을 할 타이밍 [ 편집 ]

언제든지 뭐든지 리팩토링을하면된다는 것은 아니다. 납기가 빠듯한 다가온 경우에 리팩토링을하고있을 여유는없고, 리팩토링은 장래에 대비하여 실시하는 것으로 인해 그 리팩토링이 결실을 맺을 가능성은 적다. 또한 리팩토링이라고해도 역시 프로그래밍이기 때문에, 항상 오류를 위험은 지울 수 없다.

"리팩토링"에서는 기능을 추가하는 것과 리팩토링 때 명확하게 구별하는 것을 권장하고있다 (이 일을 비유하며 " 구현 모자를 리팩토링 모자 쓰고 다시 "이라한다). 리팩토링 만있어 개발은 진행하지 않으며, 어떤 리팩토링을해야할지 어느 정도 개발이 진행 않으면 모른다. 리팩토링을 시작하는 타이밍으로 코드 " 불길한 냄새 "를 느끼기 시작하면, 제안하고있다. 이것은 유사한 코드 중복과 너무 긴 메소드, 하나의 변경 때마다 여러 클래스가 영향을받는 등의 증상이 발견된 경우를 가리킨다. 또한 기능 추가 전 코드 검토 시 버그 수정 시에도 리팩토링을 권장하고있다.

테스트의 중요성 [ 편집 ]

프로그램의 모양을 변경해야하기 때문에 리팩토링에 대해서는 테스트 가 매우 중요하다. 수정 단계적이고 조금씩하고 약간의 변경 때마다 테스트를 실시하는 것으로 동작의 이상을 재빨리 감지한다. 테스트없이 한 번에 리팩토링하면 프로그램의 동작이 어느새 바뀌어 버리고도 원인이 부위를 알 수 어려워진다. 프로그래머 테스트를 빼먹지하지 않기 때문에 간단하게 테스트를 수행할 수있는 도구 ( xUnit / JUnit 등)도 필요하다. 또한 테스트를 중요시하는 것은 민첩한 소프트웨어 개발 의 일부 개발 방법 ( 익스 트림 프로그래밍 등)의 " 테스트 우선 "나" 테스트 주도 개발 "의 개념 과도 일치한다.

리팩토링의 과제 [ 편집 ]

리팩토링도 일부 문제가 존재한다. 예를 들어 데이터베이스 에서 변경하는 경우 데이터 마이 그 레이션을 할 필요가있다. 중간 계층을 사이에 두는 것으로 영향을 완화 수 있지만, 역시 시간이 걸리는 것은 부정할 수 없다. 또한 리팩토링은 종래와 같이 캡슐화된 클래스뿐만 아니라 인터페이스 도 변경할 수있다. 그것은 널리 공개된 인터페이 스인 경우 새 인터페이스와 이전 인터페이스를 모두 관리해야한다. 또한 수정하는 코드가 너무 심한 상태의 경우 새로 고쳐 쓴 것이 빠른 경우도있다. 아직 개발 기술을 위해 앞으로 여러 가지 문제가 발견될 가능성은있다.

통합 개발 환경의 리팩토링 기능 [ 편집 ]

최근 통합 개발 환경 에는 리팩토링 기능이있는 것이 많다. 리팩토링은 수정되는 메서드 또는 클래스가 어떤 클래스에서 이용되고 있는지 조사할 필요가 발생한다. 이것을 단순한 텍스트 편집기 에서 알아보자하면 꽤 귀찮은 작업이 될 위, 간과을 가능성도 높다.

관련 항목 [ 편집 ]

• 민첩한 소프트웨어 개발 - 익스 트림 프로그래밍 과 같은 몇 가지 개발 방법에서는 개발의 습관 중 하나는 리팩토링을 들고있다.
• xUnit / JUnit - 테스트 를위한 프레임 워크. JUnit은 Java 프로그램의 테스트 프레임 워크이다.
• Eclipse - 통합 개발 환경 . 수많은 리팩토링 기능이있다.
• 소프트웨어 유지 보수
• 코드 냄새

참고 문헌 [ 편집 ]

• 마틴 파울러 외 "리팩토링 : 프로그래밍의 체질 개선 기술"피어슨 에듀케이션, 2000 년 ISBN 4894712288