음하하하

  [리팩토링]이라는 이름의 이 책은 컴퓨터 공학에서 아주 유명한 책이면서 저자인 마틴 파울러를 유명하게 만든 책이기도 하다. 그리고 켄트 백과 같은 사람들도 이 책의 집필에 참여하였다. 이 책은 객체지향 프로그래밍에서 코드의 유지보수를 위한 교과서와 같은 책이다. 이 책의 초판이 나온 지 10년이 훨씬 넘었지만, 객체지향 프로그래밍에 있어서 놓치면 안되는 것들을 아직까지 많이 알려주고 있다.

  이 책은 리팩토링에 대한 개론을 언급하는 것으로 시작한다. 저자는 리팩토링을 수행하면 코드 관리뿐만 아니라, 프로그램의 성능도 향상시킬 수 있다고 주장한다. 그 뒤에, 수 십가지의 리팩토링 기법을 소개한다. 평소에 당연하다고 생각했던 사항부터, 전혀 알지 못한 내용까지 책에서 발견할 수 있었다. 책의 마지막에는 작은 리팩토링 사항들을 조합하여 여러 단계의 큰 리팩토링을 실시하는 예를 소개하는 것으로 이 책을 마친다.

  리팩토링에 관한 기법은 웹 상에서 쉽게 찾아서 볼 수 있고, 지금은 이보다 더 많은 리팩토링 방법들이 많이 있기 때문에 블로그에 따로 기록하지는 않았다. 하지만 아래 링크에 리팩토링에 대한 개론을 남겨놓았다.

http://goscala.tistory.com/category/%EC%BB%B4%ED%93%A8%ED%84%B0%EA%B3%B5%ED%95%99/Refactoring

  리팩토링 개론에서 가장 흥미롭게 본 부분은, 상급자와의 의견이 맞지 않아 리팩토링을 하지 말라는 지침(예를 들어 마감 일정이 얼마 남지 않아 시간이 모자라서...)을 받았을 때 상급자 몰래 리팩토링을 실시하는 것이 나중에 프로그램의 질을 위해서 더 좋다는 내용을 주장한다. 실제로 프로젝트를 완성했을 때 유지보수를 하는 것은 관리자가 하는 것이 아니라, 실무자가 수행을 해야한다. 유지보수 관점에서 힘든 사항들이 처음에는 드러나지 않기 때문에, 나중을 위해서 리팩토링을 수시로 수행하는 것이 맞다고 생각한다. 하지만, 이런 것들을 생각하는 관리자가 몇이나 있을까 싶다. 당장의 눈 앞의 성과만을 위해서 예외 처리나 유닛~필드 테스트까지 수행을 생각하는 것을 꺼려하는 관리자가 많다. 그 이유가 너무 많지만, 일단 본인들이 프로그래밍에 대한 경험이 별로 없이 관리자의 위치로 올라간 탓이 크다. 사내에서 프로그래밍 경험이 풍부한 관리자가 언제쯤 나타날지가 궁금하다. 아마도 지금 재직하고 있는 부서에서는 그럴 가능성이 아주 낮다. 정치를 잘하는 사람보다는 기술적으로 실력이 뛰어난 관리자를 찾아 떠나야할 시점이다.