336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
마틴 파울러는 그의 저서인 ‘리팩토링’에서 리팩토링을 다음과 같이 정의했습니다.
“리팩토링은 외부의 동작을 바꾸지 않고 내부의 구조를 개선하는 것”
검증의 시각에서 이 정의를 볼 때 우리가 리팩토링을 하며 개선 외에 추구해야 할 또 다른 목표를 알 수 있습니다. 바로 리팩토링을 하더라도 외부의 동작을 바꾸지는 않는 것입니다. 다시 말해 리팩토링을 어떻게 하든 예전의 동작은 그대로 유지되어야 합니다. 지난 글에서 이 부분을 ‘검증’이라 불렀습니다. 검증을 하려 하다 보면 항상 반복적으로 고려하는 요소가 있음을 알게 됩니다. 바로 영향력 검토, 검증방법 결정, 검증시점입니다.
영향력 검토는 내가 수행하는 리팩토링이 어디에 영향을 미치는지 확인하는 단계입니다. 예를 들어 사용자가 남자이면 True를 반환하는 메서드가 있고 이 메서드는 프로젝트 전반에 걸쳐 광범위하게 사용되고 있다고 가정해봅시다. 이때 리팩토링 중 실수로 남자임에도 False가 반환되게 되었습니다. 이때 프로젝트에는 어떤 영향이 미칠까요? 아마 이 메서드를 사용하는 모든 곳의 기능이 정상적으로 동작하지 않을 것입니다. 이것이 바로 해당 메서드가 가지고 있는 영향력이며, 우리는 리팩토링 전에 이 영향력을 반드시 알아내야 합니다. 때로 리팩토링 시 내가 변경하는 곳으로 인해 생기는 영향력에 대해 정확히 파악하기가 어려운 경우가 있습니다. 이런 경우는 정확한 검증을 할 수 없다는 뜻과 동일하기 때문에 영향력을 파악하기 전에는 리팩토링 진행을 멈추는 것이 좋습니다,
그 다음으로는 검증방법을 결정해야 합니다. 특정 부분을 리팩토링 한 후에 이 부분의 동작이 예전과 정확히 동일한지를 실제로 검사하는 단계입니다. 예를 들어봅시다. F를 리팩토링 할 예정입니다. 이 부분은 기능 A와 B에 영향을 미칩니다. 따라서 리팩토링 후 A와 B에 대한 기능을 테스트 인력이 검토하기로 했습니다. 이 예는 영향력 검토를 하고 검증방법을 결정하는 예를 보여줍니다. “A와 B에 대한 기능을 테스트 인력이 검토하기로 했다” 부분이 검증방법을 결정한 것이라 볼 수 있습니다. 예에서처럼 테스트 인력이 검증할 수도 있지만 자동화 된 단위 테스트 등을 이용할 수 있습니다.
마지막으로 검증시점에 대한 고려가 필요합니다. 검증시점은 말 그대로 검증을 수행하는 시점을 뜻합니다. 앞선 내용에서 이미 언급했지만 보다 빠르게 검증하는 것은 비용 면에서 많은 유익을 줍니다. 지난 글에서는 표를 이용하여 개발 중, QA 중, 서비스 중으로 나눠서 설명을 했었는데 이 것은 서비스 흐름 관점의 구분이라 볼 수 있습니다. 좀 더 기술적으로는 컴파일 시점과 실행 시점으로 분류해볼 수 있습니다. 이 경우 컴파일 시점(Compile Time)이 실행 시점 보다 이르며 따라서 문제는 컴파일 시점(Runtime)에 발견되는 것이 좋습니다. 이 점은 컴파일러 검증의 필요성을 나타냅니다. 또한 실행 시점 중에서도 고객에게 서비스를 하고 있는 실행 시점보다는 테스트를 수행하고 있는 실행 시점에 문제가 발견되는 것이 더 좋습니다. 이 점은 단위 테스트와 CI서버 도입의 필요성을 나타냅니다.
위 세 가지 점에 대해 고려한 후에는 리팩토링을 하기 위해 필요한 비용과 리팩토링 후 검증을 하기 위해 필요한 비용, 즉 리팩토링에 대한 투자비용을 생각해볼 수 있습니다. 투자비용을 생각해보는 이유는 리팩토링 또한 일종의 투자이기 때문입니다. 리팩토링은 현재 어떤 노력을 기울여 이후의 유지보수 등의 노력을 적게 들이려는 노력의 일환입니다. 그렇기 때문에 리팩토링에 대한 투자비용을 따져보고 우리가 투자를 할 때 의례 하듯이 이 투자로 인해 얻어질 거라 생각하는 이익보다 투자비용이 크다고 판단한다면 리팩토링을 진행할지에 대해 다시 한번 생각해보는 것이 좋습니다. 또한 투자의 관점에서 리팩토링을 보면 적게 투자해서 많이 얻는 것도 중요합니다. 주식투자에서 이것을 가능하게 가능 것이 저 평가 된 우량주를 발견하는 것이라면, 리팩토링에서는 아래 그림과 같이 영향력과 검증방법에 따른 비용을 줄이고 검증시점을 앞당기는 것이 적게 투자해서 많이 얻는 열쇠라 할 수 있습니다.
“리팩토링은 외부의 동작을 바꾸지 않고 내부의 구조를 개선하는 것”
검증의 시각에서 이 정의를 볼 때 우리가 리팩토링을 하며 개선 외에 추구해야 할 또 다른 목표를 알 수 있습니다. 바로 리팩토링을 하더라도 외부의 동작을 바꾸지는 않는 것입니다. 다시 말해 리팩토링을 어떻게 하든 예전의 동작은 그대로 유지되어야 합니다. 지난 글에서 이 부분을 ‘검증’이라 불렀습니다. 검증을 하려 하다 보면 항상 반복적으로 고려하는 요소가 있음을 알게 됩니다. 바로 영향력 검토, 검증방법 결정, 검증시점입니다.
영향력 검토는 내가 수행하는 리팩토링이 어디에 영향을 미치는지 확인하는 단계입니다. 예를 들어 사용자가 남자이면 True를 반환하는 메서드가 있고 이 메서드는 프로젝트 전반에 걸쳐 광범위하게 사용되고 있다고 가정해봅시다. 이때 리팩토링 중 실수로 남자임에도 False가 반환되게 되었습니다. 이때 프로젝트에는 어떤 영향이 미칠까요? 아마 이 메서드를 사용하는 모든 곳의 기능이 정상적으로 동작하지 않을 것입니다. 이것이 바로 해당 메서드가 가지고 있는 영향력이며, 우리는 리팩토링 전에 이 영향력을 반드시 알아내야 합니다. 때로 리팩토링 시 내가 변경하는 곳으로 인해 생기는 영향력에 대해 정확히 파악하기가 어려운 경우가 있습니다. 이런 경우는 정확한 검증을 할 수 없다는 뜻과 동일하기 때문에 영향력을 파악하기 전에는 리팩토링 진행을 멈추는 것이 좋습니다,
그 다음으로는 검증방법을 결정해야 합니다. 특정 부분을 리팩토링 한 후에 이 부분의 동작이 예전과 정확히 동일한지를 실제로 검사하는 단계입니다. 예를 들어봅시다. F를 리팩토링 할 예정입니다. 이 부분은 기능 A와 B에 영향을 미칩니다. 따라서 리팩토링 후 A와 B에 대한 기능을 테스트 인력이 검토하기로 했습니다. 이 예는 영향력 검토를 하고 검증방법을 결정하는 예를 보여줍니다. “A와 B에 대한 기능을 테스트 인력이 검토하기로 했다” 부분이 검증방법을 결정한 것이라 볼 수 있습니다. 예에서처럼 테스트 인력이 검증할 수도 있지만 자동화 된 단위 테스트 등을 이용할 수 있습니다.
마지막으로 검증시점에 대한 고려가 필요합니다. 검증시점은 말 그대로 검증을 수행하는 시점을 뜻합니다. 앞선 내용에서 이미 언급했지만 보다 빠르게 검증하는 것은 비용 면에서 많은 유익을 줍니다. 지난 글에서는 표를 이용하여 개발 중, QA 중, 서비스 중으로 나눠서 설명을 했었는데 이 것은 서비스 흐름 관점의 구분이라 볼 수 있습니다. 좀 더 기술적으로는 컴파일 시점과 실행 시점으로 분류해볼 수 있습니다. 이 경우 컴파일 시점(Compile Time)이 실행 시점 보다 이르며 따라서 문제는 컴파일 시점(Runtime)에 발견되는 것이 좋습니다. 이 점은 컴파일러 검증의 필요성을 나타냅니다. 또한 실행 시점 중에서도 고객에게 서비스를 하고 있는 실행 시점보다는 테스트를 수행하고 있는 실행 시점에 문제가 발견되는 것이 더 좋습니다. 이 점은 단위 테스트와 CI서버 도입의 필요성을 나타냅니다.
위 세 가지 점에 대해 고려한 후에는 리팩토링을 하기 위해 필요한 비용과 리팩토링 후 검증을 하기 위해 필요한 비용, 즉 리팩토링에 대한 투자비용을 생각해볼 수 있습니다. 투자비용을 생각해보는 이유는 리팩토링 또한 일종의 투자이기 때문입니다. 리팩토링은 현재 어떤 노력을 기울여 이후의 유지보수 등의 노력을 적게 들이려는 노력의 일환입니다. 그렇기 때문에 리팩토링에 대한 투자비용을 따져보고 우리가 투자를 할 때 의례 하듯이 이 투자로 인해 얻어질 거라 생각하는 이익보다 투자비용이 크다고 판단한다면 리팩토링을 진행할지에 대해 다시 한번 생각해보는 것이 좋습니다. 또한 투자의 관점에서 리팩토링을 보면 적게 투자해서 많이 얻는 것도 중요합니다. 주식투자에서 이것을 가능하게 가능 것이 저 평가 된 우량주를 발견하는 것이라면, 리팩토링에서는 아래 그림과 같이 영향력과 검증방법에 따른 비용을 줄이고 검증시점을 앞당기는 것이 적게 투자해서 많이 얻는 열쇠라 할 수 있습니다.
그림#1. 영향력, 검증비용을 감소시키고 검증시점을 앞당기는 것
수정 이력
2010/05/07 : 이 주제가 여러 편에 걸쳐 게시되었기 때문에 내용이 중복되지 않고 읽는이가 부드러운 흐름을 타게하기 위해 내용을 다소 수정합니다.
2010/05/07 : 이 주제가 여러 편에 걸쳐 게시되었기 때문에 내용이 중복되지 않고 읽는이가 부드러운 흐름을 타게하기 위해 내용을 다소 수정합니다.
WRITTEN BY
- 차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!
,
