첫째, 리팩토링의 목적은 소프트웨어를 보다 이해하기 쉽고, 수정하기 쉽도록 만드는 것이다.
이것과 대조되는 좋은 예가 퍼포먼스 최적화이다. 리팩토링과 마찬가지로 퍼포먼스 최적화도 보통 동작을 바꾸지는 않는다 (속도는 빼고). 단지 내부 구조를 바꿀 뿐이다. 그러나 그 목적이 다르다. 퍼포먼스 최적화는 종종 코드를 이해하기 더 어렵게 만들지만, 필요한 퍼포먼스를 얻기 위해서는 그렇게 해야 한다.
둘째, 리팩토링은 겉으로 보이는 소프트웨어의 기능을 변경하지 않는다는 것이다. 리팩토링 후에도 소프트웨어는 여전히 동일한 기능만을 가지고 있다.
만일 리팩토링을 하다 while 루프의 실행이 늘어 났다고 하자. 시간이 오래걸리는 while 루프는 퍼포먼스를 나쁘게 한다. 많은 프로그래머는 이와 같은 단순한 이유로 이런 리팩토링을 하지 않으려 할지도 모른다. 그러나 단지 그럴지도 모른다는 말에 주목하라. 프로파일(profile)을 보기 전에는 계산을 위해 루프가 얼마나 많은 시간을 소모할 지, 또는 그 루프가 시스템의 전체 퍼포먼스에 영향을 줄 만큼 자주 호출될 지에 대해 알 수 없다. 이 while 리팩토링에 대해 걱정할 필요 없다. 만약 최적화를 하고 있다면 이 부분에 대해 걱정을 해야겠지만, 그렇지 않으면 이와 같이 리팩토링을 함으로써 최적화를 하기가 더 유리해 질 것이고, 최적화를 효과적으로 하기 위한 더 많은 옵션을 가지게 될 것이다.
출처 : Refactoring - 마틴 파울러
이것과 대조되는 좋은 예가 퍼포먼스 최적화이다. 리팩토링과 마찬가지로 퍼포먼스 최적화도 보통 동작을 바꾸지는 않는다 (속도는 빼고). 단지 내부 구조를 바꿀 뿐이다. 그러나 그 목적이 다르다. 퍼포먼스 최적화는 종종 코드를 이해하기 더 어렵게 만들지만, 필요한 퍼포먼스를 얻기 위해서는 그렇게 해야 한다.
둘째, 리팩토링은 겉으로 보이는 소프트웨어의 기능을 변경하지 않는다는 것이다. 리팩토링 후에도 소프트웨어는 여전히 동일한 기능만을 가지고 있다.
만일 리팩토링을 하다 while 루프의 실행이 늘어 났다고 하자. 시간이 오래걸리는 while 루프는 퍼포먼스를 나쁘게 한다. 많은 프로그래머는 이와 같은 단순한 이유로 이런 리팩토링을 하지 않으려 할지도 모른다. 그러나 단지 그럴지도 모른다는 말에 주목하라. 프로파일(profile)을 보기 전에는 계산을 위해 루프가 얼마나 많은 시간을 소모할 지, 또는 그 루프가 시스템의 전체 퍼포먼스에 영향을 줄 만큼 자주 호출될 지에 대해 알 수 없다. 이 while 리팩토링에 대해 걱정할 필요 없다. 만약 최적화를 하고 있다면 이 부분에 대해 걱정을 해야겠지만, 그렇지 않으면 이와 같이 리팩토링을 함으로써 최적화를 하기가 더 유리해 질 것이고, 최적화를 효과적으로 하기 위한 더 많은 옵션을 가지게 될 것이다.
출처 : Refactoring - 마틴 파울러
Rss Feed