리팩토링 / 마틴 파울러 - (3) Chapter 02. 리팩토링 개론

두번째 챕터는 본격적으로 리팩토링에 대한 개념을 잡는 시간이다.

리팩토링은 단순히 코드 정리 작업을 의미하지 않는다.

리팩토링의 핵심은 소프트웨어를 더 이해하기 쉽게, 수정하기 쉽게 만드는 것이므로 코드 정리 작업보다는 좀 더 광범위한 개념이 될 것이다.

또한 기능을 개선하기 위한 작업이 아니므로 리팩토링 전후의 소프트웨어 기능은 변하지 않는다.

따라서 리팩토링은 '성능 최적화'와 상반되는 개념이라고 할 수 있다. 

왜냐하면 성능 최적화를 수행할 경우, 필요한 성능을 얻기 위해 어쩔 수 없이 코드가 더 복잡해질 수 있기 때문이다. 

리팩토링을 하는 이유와 효과에 대해서는 저자가 언급한 랄프 존슨의 비유로 축약한다.

"....이러한 최초 단계의 리팩토링은 '우선 창 밖이 보이게 뿌연 유리창부터 닦는 일'과 같다고 했다."

캬 기가 맥히고 코가 맥히는 비유가 아닐 수 없다.

그렇다면 언제 리팩토링을 하면 좋을까? 저자는 일상적으로 틈틈이 리팩토링을 하라고 권하면서도,

친절하게 어떤 상황에서 리팩토링이 꼭 필요한지 쏙쏙 찝어준다.

돈 로버츠는 같은 작업을 세번째 반복하게 됐을 때 리팩토링을 실시하라고 가르쳐줬다고 한다.

그밖에는 기능을 추가할 때, 버그를 수정할 때, 코드를 검수할 때 리팩토링을 하라고 한다.

저자가 책에서 주구장창 이야기 하듯이, 리팩토링을 실시하고 나면 코드가 더 이해하기 쉬워지기 때문이겠다.

반면 코드를 처음부터 새로 작성해야 하는 경우나, 납기가 임박한 경우에는 굳이 리팩토링을 하지 말라고 권한다.

물론 저자는 리팩토링을 하면 안되는 상황을 언급하면서도 이 외의 상황에서는 늘 리팩토링을 하라고 한다. 

이런 리팩토링 성애자 같으니....리팩토링 안티였다가 빠가 된 사람이라 그런지 엄청나게 강조한다.

아래 문장은 읽으면서 정말 가슴에 쑥쑥 박혔는데

"언제나 시간에 쫓긴다면 그건 리팩토링해야 한다는 신호다."

리팩토링을 하지 않음으로써 오히려 더 자원이 낭비된다는 귀중한 교훈이 아니겠는가!

이로써 더더욱 열심히 리팩토링을 실천하는 개발자가 되겠다고 저자도 모르는 사이에 저자와 약속한다.

두번째 챕터에서 제일 흥미로웠던건 사실 저자가 주구장창 설명하는 리팩토링의 개념과 장점 등등이 아니라

'인다이렉션' 개념이었다. 사실 학원 출신 개발자답게 '인다이렉션'이라는 용어를 여기에서 처음 접했다. 

뭔가 싶어서 한글로 검색해보고, 영어로 검색해봐도 내 마음에 쏙 저장되는 정의를 찾을 수 없다.

뭘 좀 아는 외국인들의 글을 봐도 '제대로 알면 참 좋은데...어떻게 설명해야 할지...ㅎ' 하면서 못 알아먹을 말만 잔뜩 늘어놓는 모습이 주로 보인다.

"컴퓨터 과학에선 모든 문제의 해결책이 인다이렉션 계층을 하나 더 만드는 것이라고 가르친다" - 드니스 드브룰러

이렇게까지 말하는 사람이 있는데도 불구하고, 명확한 정의가 구글 검색결과 1페이지에 없다는 사실에 참으로 가슴이 미어진다.

리팩토링을 적용하면 프로그램에 생각 외로 많은 인다이렉션이 들어가게 된다는데....

책에서 저자가 말해주는 인다이렉션의 개념을 정리하자면 아래와 같다.

인다이렉션 (Indirection) 은

 - 한 객체가 다른 객체에 작업을 위임하고, 그 객체가 또 다른 객체에 작업을 위임하는 식으로 코드를 짜는 것으로 추정된다.

 - 하나의 로직을 여러 곳에서 공유할 수 있게 해준다.

 - 의도와 구현부를 따로 보여줌으로써 주요 정보를 좀 더 분명하게 드러내는 코드를 만들 수 있게 한다.

 - 하위 클래스를 만들고, 변하는 경우에 참조하게 하는 식으로 수정 부분을 분리할 수 있게 한다.

 - 조건문을 코드화하여 보다 명료하고 유연한 코드를 만들 수 있게 한다.

엥? 이거 어디서 많이 보던 정의 아니냐??

아래 링크에서 나와 비슷한 생각을 한 질문자를 만날 수 있었다.

https://softwareengineering.stackexchange.com/questions/111756/what-is-the-difference-between-layer-of-abstraction-and-level-of-indirection

이 중에서 제일 내 맘에 드는 답변을 정리하자면 아래와 같다. (또 영문을 해석하긴 싫으니 원본은 숨겨놓겠다.)

추상화 (Abstraction)

      - 단순화 작업과 관련

 - 객체의 세부적인 사항을 보다 간단하고 쉽게 활용할 수 있도록 숨겨준다.

인다이렉션 (Indirection)

     - 위치와 관련

     - 객체의 위치를 분명하게 만듦

     - 예를 들어 어떤 웹 리소스의 URI를 알 경우, 그 리소스에 직접 접근하지 않고 

       서버, 어플리케이션, 라우터 등등을 통해서 접근하기 때문에 그 웹 리소스의 정확한 위치값을 알 필요가 없다.

- 인다이렉션은 그 위치가 추상화된 경우라면 추상화의 한 종류로 여겨질 수도 있다.

24down voteaccepted +50

Abstraction deals with simplification, indirection deals with location. Abstraction is a mechanism that "hides" complicated details of a object in terms of simpler, easier to manipulate terms. In programming, a good example is the difference in details between machine code and the various tools for creating applications that are ultimately based on machine code. Consider creating a Windows Form application with the Visual Studio IDE. The IDE lets you think of the application in terms of easy-to-manipulate items in a What-You-See-Is-What-You-Get manner. The position of a screen widget is abstracted out to a visual location in a frame which you can change by dragging the widget around. Internally, the IDE manipulates the widget using another layer of abstraction such as a high level language (such as C#). C# itself is not manipulated using machine code, it is manipulated using a "Common Runtime Environment" which itself is an abstraction of a computer and operating system. Indirection refers to making the location of an item transparent. If you know a web resource's URI, you can access the resource without knowing its precise location. You do not access the resource directly, instead you access through a channel that passes your request through a series of servers, applications and routers. Indirection may be considered to be a special type of abstraction where the location is abstracted.

흠?? 어째 정리하고 나니 더 헷갈리는 것 같은 느낌적인 느낌느낌...

굳이 개념을 후려쳐서 비유하자면 A부장님이 B부장님이랑 직접 마주보고 얘기하면 될 것을 

A부장님이 나한테 'B 부장한테 가서 이거 어떻게 할 지 물어보고 오너라~' 하고 시켜서 B 부장님의 의사를 내가 묻고 온다면

내가 바로 인다이렉션 계층이 되는 게 아닐까???

이 부분은 나중에 기회가 되면 다시 정리해야겠다.