The Winner Takes It All

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

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

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

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

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

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

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

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

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

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

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

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

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

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