-------------------------------------------------------------------------------------------
역시 예전글의 재탕. 볼포의 강좌란 활성화를 위해서
-------------------------------------------------------------------------------------------

어떤 개념을 논할 때 중요한 단어에 대한 정의를 내리고 하지 않는 경우가 많다. 이로 인해서, 매우 많은 혼란이 발생할 수 있다. 예를 들어, 2티어와 3티어의 용어 정의를 해두지 않고 3티어를 논하면, 단순 파일 공유도 3티어로 둔갑해 버릴 수 있기 때문이다. 따라서, 정의를 제대로 내려두고 논하지 않으면 토론 자체가 달나라로 가는 경우가 많으므로, 먼저 리팩토링의 정의부터 내려 보자.

마틴 파울러의 리팩토링 서문에 보면 리팩토링에 대해서 다음과 같이 요약하고 있다.

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.

짧은 영어실력이지만, 이를 번역하면 다음과 같다.

"리팩토링이란, 코드의 외부 동작을 변경하지는 않으면서도 내부 구조를 개선해가는 소프트웨어 시스템 변경 작업이다. 리팩토링은 버그 유발을 최소화하면서 코드를 정리하는 체계적 방법이다. 기존에 작성한 코드의 디자인을 향상하는 것이 리팩토링이다." 

마틴 파울러의 리팩토링 책의 모든 예제는 자바 소스로 되어 있다. 그러나,  그 개념은 객체지향인 언어이든 아니든간에, 자바이든 아니든 간에 상당수 적용할 수 있다. 왜냐하면 리팩토링이란 코드의 체계적인 정리 방법이기 때문이다. 리팩토링 책은 널리 알려진 일반적 방법을 제시한 정도로 이해하면 된다. 

각 컴언어에 따라서, 특성에 맞는 별개의 리팩토링 방법이 분명히 존재할 수 있다는 것을 명심해야 한다. 책은 책일 뿐 현실 코딩은 현실에서의 타당성이 있어야 한다. 리팩토링을 할 때는 이유가 있어야 한다. 이전의 "델파이 코드 리팩토링 예제 1" 글에서 코드를 정리하는 과정마다 이유를 설명했듯이 각 단계마다 수정하는 근거가 있어야 한다. 명확한 이유 없이 수정하는 코드는 버그만 양산할 뿐이다..

중요한 사실은 리팩토링은 "그까이꺼 대충 하면 되지"가 아니라, 체계적인 코드 정리 방법이란 것이다. 이 체계성과 일관성이 있는가 없는가가 매우 중요하다. 

체계성과 일관성이 없는 코드는 매우 위험하다. 이는 조만간 소스 전체를 뒤집어 엎어도 문제 해결이 불가능한 상황을 맞닥뜨리기 때문이다. 체계성과 일관성이 있는 코드는 수정도 쉽고 알아보기도 쉽다. 간혹 개발자 게시판을 보면 소스의 가독성에 대해서 전혀 엉뚱하게 이해하는 사람들을 종종 본다. 소스 가독성은 한글로 변수명을 작성한다고 이뤄지는 것도 아니면 주리장창 긴 이름의 함수명을 짓는다고 이뤄지는 것도 아니다.

체계성과 일관성에 매우 중요한 영향을 미치는 명칭 작성에 대해서 잠시 연구해 보자. 

변수나 함수의 이름을 알기 쉽게 작성하는 것도 중요하다. 그러나 더 중요한 것은 그 이름을 어떤 룰로 작성하냐는 것이다. 

예를 들어, "사각형"을 의미하는 어떤 명칭을 지을 때, 각 팀원들간에 RR, Rect, Rectangle, Nemo, Sagak, Sagag 등등 수십 종류의 이름이 나올 수 있다. 잘 훈련된 팀은 어떤 룰에 의해, 이중 한가지가 자동으로 선택이 된다. 일반적으로 로칼 명칭(로칼 변수명)은 이름 작성에서 별로 중요하지 않으나, 전역 명칭(전역함수나 클래스명 등)에 대해서는 반드시 이름 작성에 대한 룰이 있어야 한다.

이름 작성을 할때는 어떤 단어를 사용했는가가 아니라, 어떤 룰에 의해서 그 이름을 도입하게 되었는가 그 결정 과정의 일관성이 더욱 중요하다. 

또, 복잡한 소스에서는 어떤 명칭이 로칼 명칭인지, 클래스 멤버(메서드, 속성 등) 명칭인지, 전역 명칭인지를 직관적으로 구별할 수 있을 필요가 있다. 비록 컴파일러는 각 명칭의 지역성을 혼동하지 않으나, 사람은 혼동할 수 있기 때문에, 직관적으로 어떤 명칭의 지역성을 알 수 있도록 조치할 필요가 있다.

이해하기 쉬운 코드를 만드는데 가장 기여하는 것은 체계성과 일관성이다. 일상의 쉬운 단어로 명칭을 작성하는 것은 매우 미약한 효과만 기여할 뿐이다.