The Winner Takes It All

첫 포스팅을 하고 두 달만에 포스팅을 한다는;; 그동안 얼마나 게을렀는가를 스스로 반성.ㅠㅠ 앞으로 두 번의 포스팅에 걸쳐 리팩토링의 정의... 리팩토링을 왜 해야 되고, 리팩토링을 할 때 어려운 점 등을 정리하고; 그 다음부터 실제 기술적인 면을 정리할 생각이다.

리팩토링 - 소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것.

 리팩토링은 소프트웨어의 모든 문제점을 해결할 수 있는 방법은 아니지만, 많은 문제점을 해결할 수 있는 유용한 도구가 될 수 있으며, 다양한 목적으로 사용할 수 있다.

구체적으로 리팩토링을 적용할 수 있는 사례를 살펴보자면~

- 리팩토링은 소프트웨어의 디자인을 개선 시킨다.
앞서 얘기 했듯이 단기적인 목적을 이루기 위해서, 또는 코드 전체의 디자인을 제대로 이해하지 못하는 상태에서 코드를 변경할 때, 결국 그 코드는 원래의 구조를 잃을 것이며, 시간이 흐르면 이 효과는 누적되어, 종국에는 어떻게 이도 저도 건드리지 못하는 몬스터가 되는 경우가 발생한다. 정기적인 리팩토링 작업은 이런 문제를 미연에 방지할 수 있으며, 코드의 디자인을 유지하도록 도와준다. 가장 간단한 리팩토링의 예는 중복된 코드를 제거하는 것!

- 리팩토링은 소프트웨어를 더 이해하기 쉽게 만든다.
굳이 남이 이해하기 쉽도록 이타적인 생각을 할 필요도 없다. 그 대상은 미래의 자신이 될 수도 있다. 아마 누구나 자신이 코딩한 프로그램을 시간이 흘러 다시 봤을 때, 쉽게 이해하지 못하는 경험이 있을 것이다.

- 리팩토링은 버그를 찾도록 도와준다.
당연한 얘기로 이해하기 쉬운 소프트웨어가 버그를 찾기도 쉽다.

- 리팩토링은 프로그램을 빨리 작성하도록 도와준다.
개발 이외에 리팩토링을 해야되는데, 그것이 정말 시간을 단축시켜 주는 것일까? 하지만, 정기적인 리팩토링을 통해 코드의 디자인이 유지되고, 코드의 가독성이 높아진다면, 이후 새로운 기능을 추가하거나 기능을 수정 변경할 때 훨씬 수월하다.

 그럼, 언제 리팩토링을 해야될까?
 사실 날을 잡고, 리팩토링을 하는 것은 개발자에게 너무 많은 부담이 될 수 있다. (정말 부지런한 사람만이 할 수 있을 것 같다.)

- 기능을 추가할 때 리팩토링을 하라.
새로운 기능을 추가하는 경우, 지금의 디자인이 기능 추가가 쉽지 않은 디자인일 수 있다. 그 때 아 예전에 디자인을 할 때 이런 식으로 했었다면, 후회를 하지 말고, 새로이 리팩토링을 하라. 그것이 미래에 똑같은 후회를 방지 할 수 있는 방법이다.

- 버그를 수정할 때 리팩토링을 하라.

- 코드 리뷰를 할 때 리팩토링을 하라.
코드 리뷰는 지식이 개발팀 전체로 확산되는 것을 돕는 좋은 방법이다.

리팩토링을 공부하면서, 정말 나에게 뼈져리게 와닿는 내용이 많다. 시간에 쫓겨서란 변명을 일단 급한대로 코딩을 해오다, 시간이 흘러 기능 추가나 수정이 발생했을 때, 정말 후회한 기억이 지금도 새록 새록 난다. 리팩토링의 가장 큰 적은 귀차니즘이다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

 직장인은 3년차쯤 되면... 슬럼프가 온다고 하는데, 내가 딱 그 모양인 것 같다;
할 일은 많은데, 일도 잘 되지 않고; 일을 하더라도 왠지 모르게 어수선하고, 깔끔하지가 못 하다;

과연 내 문제는 무엇이고, 해결책은 뭘까... 곰곰히 생각해보다 내린 결론은 공부다; 아무리 일이 바쁘지만...
일이 바쁘지 않더라도 마냥 놀다보니 발전이 없다. 늘 하던 짓만 하다보니, 결국 매너리즘에 빠지게 되는 것;

그래서 입사 초기에 했던 것 처럼... 한가지 주제를 잡고, 공부를 해보기로 마음을 먹었다; 그래야 내 스스로도
발전이 있을게 아닌가;

어떤 주제로 공부하는 것이 좋을까... 고민하다; 진즉에 사놓고 읽지 못하고 있던 "리팩토링(Refactoriing) - 나쁜 디자인의 코드를 좋은 디자인으로 바꾸는 방법 / 마틴 파울러 저/ 윤성준, 조재박 역"을 대상으로 삼기로 했다.

1주일에 하루 정도 날짜를 정해, 한 Chapter씩 읽고, 공부를 했다는 의미를 되살리기 위해 블로그에 요약을 적기로 결정했다;

Chapter 1은 간단한 비디오 대여 프로그램의 일부를 가지고, 왜 리팩토링이 필요한가에 대해서 다루고 있다. 저자의 언급대로 간단한 프로그램이고, 재사용성이나 확장성을 염두에 두고 있지 않다면, 리팩토링은 무의미 할 것이다.

하지만 학창 시절에 숙제를 위해 만든 프로그램이 아니라면... 대부분의 경우, 확장 또는 재사용성을 당연히 고려해야 마땅하다. 매우 이상적인 경우라면, 프로그램 디자인 단계에서 완벽한 클래스의 구조를 만들어, 정말 읽기 쉽고, 어디든지 붙이기 쉽게 만들 수도 있지만 현실적으로는 불가능하다.

프로젝트를 진행하다보면 처음 설계된 프로그램 디자인과 별개로 코딩해 나가면서 맞딱드리는 여러 요인에 의해 시스템 본래의 모습과 디자인을 따른 구조는 점점 사라지고, 결국 완벽한 보안을 갖춘 (경쟁사에서 이 코드를 가져가도 해독이 불가능한...) 코드가 된다.

리팩토링은 이러한 관례와 반대로 다소 서투른 디자인을 취해 재작업하여 잘 디자인된 코드를 만드는 과정이라 이해할 수 있다. 각각의 단계는 A 클래스의 멤버 변수를 B 클래스로 옮기거나, 클래스 코드의 일부를 수퍼 클래스나 서브 클래스로 옮기거나 하는 것이다. 이러한 작업들이 모여 근본적으로 디자인을 개선하게 된다.

리팩토링에서 가장 중요한 개념은 내부(코드 및 디자인)를 바꾸면서 외부(기능)을 바꾸지 않는 것이기 때문에, 코드 변경에 문제가 없는지 확인을 위한 강력한 테스트가 필수적이다.

보다 구체적인 리팩토링 테크닉은 다음에 또 정리하기로 하고, 저자가 1장에서 강조한 말이 기억에 남아 여기도 남기고자 한다.

"컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다."

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.