전임자가 만들었거나 다른 부서 혹은 다른 개발사에서 전달받은 코드는 섣불리 건드렸다가는 긁어 부스럼이 되기 쉽다. 레거시 코드는 모든 개발자가 넘어야 할 난제로서, 조직 내 요구사항의 변화와 외부환경 변화에 부응하기 위해 새로운 특징을 추가하고 버그를 고치고 소프트웨어 설계를 개선하고 자원 이용률을 최적화해야 한다. 이 책은 소프트웨어를 잘게 나누고 다시 통합해서 테스트를 위한 코드를 추가하는 등 소프트웨어를 변경하는 데 꼭 필요한 내용을 광범위하게 다루는 레거시 코드 재활용 기법에 대한 비급서다.


[ 소개 ]

레거시 시스템을 효율적으로 관리해 성능, 기능성, 신뢰성, 관리능력을 높이자.

저자 마이클 페더스는 이 책에서 테스트 루틴이 없는 거대한 레거시 코드 베이스로 더 효과적인 작업을 하는 전반적인 전략을 알려준다. 이 책은 유명한 오브젝트 멘토(Object Mentor) 세미나용으로 제작된 자료에 기초해, 수백 명의 개발자들과 기술 관리자들을 멘토링하고 테스터들이 레거시 시스템을 제어하는 데 도움을 준 내용을 기술한 책이다.


[ 이 책에서 다루는 내용 ]

■ 특징 추가, 버그 수정, 설계 개선, 성능 최적화 등 소프트웨어 변경 기법
■ 레거시 코드를 테스트 하니스 안에 넣는 방법
■ 새로운 문제 발생으로부터 시스템을 보호해주는 테스트 루틴 작성법
■ 자바, C++, C, C# 언어로 작성된 예제를 통해 어떤 언어나 플랫폼에도 사용 가능
■ 코드에서 변화시켜야 할 부분을 정확히 찾아내는 방법
■ 객체지향으로 작성하지 않은 레거시 시스템을 다루는 기법
■ 구조가 모호한 응용프로그램을 다루는 방법

그밖에 24가지 의존관계 깨기 기법 등 프로그램 구성 요소로 독립적인 작업을 하거나 안전하게 변경하는 경우에 대해 자세히 설명한다.


[ 추천의 글 ]

이 책 서문에서 저자 마이클 페더스는
“…그러자 다음과 같은 일이 일어났다...”
라는 문장으로 자신이 소프트웨어에 대한 열정을 품기 시작한 때를 설명했다.
“…그러자 다음과 같은 일이 일어났다...”
당신은 이러한 감정을 이해할 수 있는가? 당신은 자신의 인생에 있어서 단 한 순간이라도 “…그러자 다음과 같은 일이 일어났다...”라고 말할 수 있었던 때가 있는가? 인생의 방향을 송두리째 바꿔 놓아 결국 당신이 이 책을 집게 됨으로써 내 서문을 읽게 만든 사건이 한 번이라도 있었는가?

초등학교 6학년 때였다. 당시 나는 과학과 우주 그리고 과학기술에 관련된 모든 것에 관심이 있었다. 내 어머니는 제품 카탈로그를 보시고는 플라스틱 껍데기 안에 든 작은 디지컴(IDigi-Comp I)이라는 컴퓨터 한 대를 주문했다. 40년이 흐른 지금 그때의 작은 컴퓨터는 내 책상 위에서 명예로이 한자리를 차지하고 있다. 그 컴퓨터는 내가 소프트웨어에 끊임없이 열정을 갖게 하는 기폭제가 됐다. 나는 사람들이 지닌 문제들을 컴퓨터를 통해 푸는 게 얼마나 즐거운 일인지 처음으로 어렴풋이 깨닫게 됐다. 당시 내 컴퓨터는 플라스틱 S-R 플립플랍(flip-flop) 3개, 플라스틱 AND 게이트(and-gate) 6개로 이루어진 물건이었으나 그것만으로도 충분했다.

하지만 얼마 가지 않아 기쁨은 곧 사라지고 말았다. 소프트웨어 시스템은 결국 엉망진창이 되어 버린다는 사실 때문이었다. 프로그래머들이 처음에 생각해낸 명료한 설계는 결국 시간이 지남에 따라 상한 고기처럼 부패하게 된다. 우리가 작년에 구축한 시스템은 내년에는 함수와 변수로 뒤엉켜 버린 늪으로 변하고 만다.

왜 이런 일들이 일어날까? 왜 시스템은 부패해 가는 걸까? 왜 시스템은 깨끗한(clean) 상태에 머물러 있지 않을까?

때때로 우리는 고객에게 책임을 돌린다. 고객의 요구사항이 변경됐기 때문이라고도 말한다. 고객의 요구사항이 정확히 반영되고 고객이 반영사항에 만족해 한다면, 설계도 분명히 훌륭할 것이라는 믿음 하나로 우리는 스스로를 위안한다. 요구사항 변경은 고객의 잘못 탓이다.

여기서 중요한 소식을 하나 전하겠다. 요구사항은 반드시 변하게 되어 있다. 요구사항 변경을 수용할 수 없다면 설계가 서투른 탓이다. 변경을 수용하는 설계를 생성해내는 일은 모든 유능한 소프트웨어 개발자에게 있어 영광스러운 일이다.

견고한 설계를 만들어 내는 일은 아주 어려운 문제를 푸는 것처럼 인식된다. 실제로도 이런 작업은 너무나 힘든 탓에 제작된 모든 시스템은 서서히 부패해 결국 망가지는 과정을 겪게 된다. 이 같은 부패는 너무나도 침습력이 강해 우리는 썩은 프로그램에 걸맞은 특별한 이름을 준비했다. 바로 ‘레거시 코드’다.

레거시 코드라는 말은 프로그래머들의 가슴에서 구토를 유발한다. 마치 끈적이는 거머리와 날카로운 침을 가진 날벌레들로 뒤덮인 덤불 천지의 음산한 늪지대를 걸어가는 것과 같은 이미지를 연상시킨다. 또한 암흑, 점액, 고인물, 내장에서 나는 악취를 떠올린다. 프로그래밍에 대한 즐거움은 매우 강렬하지만, 레거시 코드를 다뤄야 하는 고통은 개발자들의 열정을 꺾어 버리고도 남을 만큼 충분히 크다.

누구나 우리가 만들어놓은 코드가 레거시 코드로 전락하지 않도록 방지하는 방법을 다각도로 찾아보려고 노력했다. 그간 많은 저자가 프로그래머들이 시스템을 깨끗하게 유지하는 데 도움을 줄 수 있는 원칙(principles), 패턴(patterns), 실행법(practices)에 대한 책을 다수 저술했다. 하지만 마이클 페더스는 우리들 대다수가 간과한 사항에 대한 통찰력을 갖고 있었다. 예방만으로는 완전할 수 없다. 최고 원칙을 숙지하고 최고 패턴을 사용하며 최선의 실행법을 따르는 가장 잘 훈련된 개발팀에서조차 때때로 작업을 망치는 일이 종종 일어난다. 부패는 계속 쌓여가고 부패를 방지하는 것만으로는 충분하지 않다. 부패를 역전(reverse)시킬 수 있어야만 한다.

이 점이 바로 이 책이 이야기하려는 내용이며 이는 곧 부패를 역전시키는 방법인 셈이다. 이 책은 복잡하게 얽힌 불명료한 시스템을 한 조각씩 단계를 밟아가는 점진적인 방법을 통해 단순하면서 잘 구조화되어 있고 훌륭하게 설계된 시스템으로 변모시키는 방법을 알려준다. 이른바 엔트로피 역전(reversing entropy)에 대한 책이라고 말할 수 있겠다.

여러분이 지나치게 흥분하기 전에 한마디 경고하고 싶다. 부패를 역전시키기는 쉽지 않을 뿐더러 단시간에 수행할 수도 없다. 저자가 이 책에서 제시하는 기법이나 패턴, 도구는 효과적이긴 하지만 여러분의 노력과 시간, 인내, 주의를 요구한다. 이 책은 결코 특효약을 제시하지는 않는다. 하룻밤 사이에 어떻게 시스템에 쌓인 모든 부패를 제거하는지에 대한 방법은 제시되지 않을 것이다. 대신 여러분이 현업에 종사하는 데 있어서 갖춰야 할 원칙과 개념, 그리고 태도에 대해 이야기할 것이다. 결국, 성능이 저하되고 있는 시스템을 서서히 향상되는 시스템으로 반전시키는 데 도움을 줄 것이다.

[ 저자 서문 ]

도대체 레거시 코드의 정체는 무엇일까? 난 여태 이 말을 제대로 정의도 하지 않고 사용해 왔다. 좀더 엄밀히 정의해 보면 레거시 코드는 다른 사람한테서 가져온 코드다. 우리 회사가 다른 회사로부터 코드를 얻어 왔을 수도 있고 원래 팀에 있던 사람들이 다른 프로젝트로 옮겨가서 코드를 얻어 왔을 수도 있다. 이처럼 레거시 코드는 단순히 다른 사람이 작성한 코드를 말하지만 프로그래머 입장에서 말하자면 이 말은 사실 그 이상을 의미한다. 시간이 지날수록 그 의미와 중요성에 대해 생각하게 만드는 용어다.

레거시 코드라는 말을 처음 들었을 때 어떤 생각이 들었는가? 당신이 나와 같은 생각을 했다면, 여기저기 얽힌 난해한 구조를 가져 제대로 알 수는 없지만 변경시켜야 하는 코드를 떠올렸을 것이다. 쉬울 것으로 생각했던 특징들을 추가하느라 며칠 밤을 지샌 추억을 떠올릴 수도 있고, 더 이상 어떻게 할 수 없는 코드에 질려 사기가 저하된 당신을 떠올릴 수 있다. 이런 경우 당신의 모든 노력은 무가치해 보인다. 레거시 코드의 정의는 누가 그 코드를 작성했는가와는 무관하다. 코드가 나빠지는 길은 여러 갈래가 있고, 실제로 그 중 대부분은 코드가 다른 팀에서 왔는지 여부와는 무관하다.

업계에서 레거시 코드는 이해할 수 없고 변경시키기 힘든 코드를 지칭하는 용어로 종종 사용된다. 하지만 지난 수년간 여러 팀들과 함께 작업하고 그 팀들이 여러 가지 심각한 코드 문제들을 해결하는 데 도움을 주면서 마침내 난 또 다른 정의에 다다르게 되었다.

내게 있어서 레거시 코드는 테스트 루틴이 없는 단순한 코드일 뿐으로서, 난 이 정의에 대해 유감을 가져왔다. 과연 코드 불량 여부와 테스트 루틴은 어떤 관련이 있을까? 내게 이 질문에 대한 답은 그다지 어렵지 않으며 이 책 전반에 걸쳐 난 이 점에 대해 상술할 것이다.

코드가 얼마나 훌륭하게 작성되어 있는지 여부와는 상관없이 테스트 루틴이 없는 코드는 불량 코드다. 얼마나 멋지게 작성되어 있는가와 객체지향의 사용 여부, 그리고 캡슐화의 정도도 참작 요소가 전혀 되지 못한다. 테스트 루틴이 있으면 코드의 동작을 빠르고 검증 가능하게 변경시킬 수 있다. 하지만 테스트 루틴이 없으면 실제로 우리 코드가 더 나아지는지 더 나빠지는지를 알 수 없게 된다.

지금까지는 심각한 경우를 설명했다. 깨끗한 코드인 경우에는 어떨까? 코드 베이스가 매우 깨끗하고 잘 정의된 구조를 가진다면 충분하지 않겠는가? 아마 실수를 저지르지는 않게 될 것이다. 난 깨끗한 코드를 좋아한다. 내가 아는 대부분의 사람들보다 훨씬 더 좋아할 것이다. 하지만 깨끗한 코드만으로는 충분하지 않다. 팀들은 테스트 루틴 없이 대규모 변경을 가하는 경우에 중대한 도전에 직면하게 될 것이다. 이것은 마치 안전그물망 없이 공중 곡예를 하는 것과 비슷하다. 이 작업은 엄청난 기술과 각 단계에서 어떤 일이 일어날지에 대한 명확한 이해를 필요로 한다. 당신이 변수 몇 개를 변경시켰을 때 어떤 일이 일어날지를 정확히 아는 것은 마치 당신이 공중에서 재주를 넘었을 때 다른 동료가 당신 팔을 잡아줄지 말지를 미리 아는 것과 같다. 당신이 깨끗한 코드를 가지고 일하는 팀의 일원이라면 다른 대부분 프로그래머보다 훨씬 더 좋은 상황에서 일하는 셈이다. 필자는 일하는 동안 모든 코드를 명쾌하게 이해하고 작업하는 팀들을 거의 본 적이 없다. 그들은 마치 통계적 예외사항인 것처럼 보인다. 그리고 당신이 지원 테스트 루틴 없이 작업한다면 코드 변경은 기존 방법에 비해 더 느리게 수행될 것이다.

어떤 팀들은 점점 나아지고 좀더 깨끗한 코드를 작성하기 시작할 수 있다. 하지만 오래된 코드가 깨끗해지는 데는 시간이 오래 걸린다. 그리고 많은 경우에 완전히 깨끗해지기란 거의 불가능하다. 그렇기 때문에 나는 레거시 코드를 테스트 루틴 없는 코드라고 정의할 수 있다. 이것은 현재 사용되는 정의이며 해결책을 지시하기도 한다.

난 지금까지 테스트 루틴에 대해 이야기해 왔으나 이 책은 테스트에 대해 얘기하지는 않을 것이다. 이 책은 어떤 코드 베이스에서도 확신을 가지고 변경을 가할 수 있는 방법을 다룬다. 여러 장에 걸쳐서 코드를 이해하고 코드를 테스트 루틴 하에 두며 코드를 리팩토링하고 특징을 추가하는 기법을 설명할 것이다.

여러분이 이 책을 읽어가는 데 있어서 유의해야 할 점 중 하나는 이 책이 훌륭한 코드에 대해 설명하는 책은 아니라는 사실이다. 나는 고객과의 비밀유지 협정을 맺고 일하기 때문에 이 책에서 사용한 예제들은 모두 책에 넣기 위해 특별히 새로 만들었다. 하지만 대부분 예제에서 나는 현업에서 보아 왔던 정신을 코드에 그대로 유지하려고 애썼다. 모든 예제들이 상황에 맞는 대표적인 것들인지는 장담할 수 없다. 분명히 이것들보다 훨씬 훌륭한 코드가 많을 것이고, 반대로 내가 사용한 예제보다 훨씬 못한 코드들도 있을 것이다. 고객 비밀유지 사항에 대한 고려 이외에도, 내용이 너무 지루해 눈물이 날 지경에 이르거나 세부내용의 늪에 빠져 허우적거리지 않도록 내용을 채우는 데 애썼지만 실제로는 그렇게 저술할 수밖에 없었다. 결과적으로 몇 개의 예제들은 상대적으로 간결해졌다. 그 중 몇 개를 들여다 보면 “아니야, 이 친구는 내가 작업하는 메소드들이 여기에 있는 것들보다 훨씬 더 거대하고 훨씬 더 고약하다는 걸 이해하지 못하고 있군”이라는 생각이 들 수도 있다. 하지만 예제가 단순해 보이더라도 제발 제시하는 충고를 액면 그대로 받아들이고 그 충고가 어떻게 적용되는지를 살펴보라.

여기에 제시하는 기법들은 내가 꽤 큰 코드 조각들에 테스트해 왔던 것들로, 책 포맷의 제약으로 인해 예제를 작게 만들었을 뿐이다. 특히 여러분이 다음과 같이 코드 조각 내에서 생략 기호(…)를 보게 되면 “500줄에 이르는 코드가 더 있겠구나”라고 생각하면 된다.

m_pDispather->register(listener);
…
m_nMargins++;

이 책이 훌륭한 코드에 대한 책이 아니듯이 훌륭한 설계에 대한 책은 더더욱 아니다. 훌륭한 설계는 우리 모두가 추구하는 목표이긴 하지만, 레거시 코드에서는 몇 단계를 거치면 다다르게 되는 것이다. 몇개 장에서는 기존 코드 베이스에 새로운 코드를 추가하는 법과 훌륭한 설계 기법을 염두에 두고 코드를 추가하는 방법을 설명했다. 여러분은 레거시 코드 베이스 안에 있는 우수한 코드 부분에서 시작해 그 부분을 확대해 나가는 식으로 작업을 시작할 수 있다. 하지만 변경을 가하는 데 필요한 단계들을 밟다 보면 약간의 코드가 더 보기 흉하게 될 수도 있는데 그렇다고 놀라지는 말자. 이러한 작업은 외과 수술과 같다. 여러 곳을 절개해야만 하고 내장 사이를 관통해야 하며 미학적인 판단은 유보해야 할지도 모른다. 이 환자의 주요 기관과 내장은 이전보다 나아질 수 있을까? 물론이다. 환자의 긴급한 문제에 대해서는 잊어버리고 절개부위를 봉합한 후에 환자에게 잘 먹고 꾸준한 운동을 하라고 말한다. 물론 이렇게 할 수도 있으나 우리에게 진정 필요한 것은 환자를 있는 그대로 보고 그가 가진 문제를 고쳐 좀더 건강한 상태가 되도록 이끄는 것이다. 다시는 국가대표 육상선수가 되지는 못하겠지만 ‘최상의 상태’가 ‘더 나빠지지’는 않게 할 수 있다. 코드 베이스는 더 건강하고 작업하기 쉽게 변경될 수 있다. 환자가 더 낫다고 느낀다면, 그 때가 바로 환자가 좀더 건강한 라이프 스타일을 약속할 수 있도록 도와줄 만한 적기인 것이다. 이것이 바로 우리가 레거시 코드를 가지고 달성하려는 바이다. 우리는 편안함을 느끼는 지점에까지 다다르려고 노력한다. 그 지점에 이를 때까지 열심히 노력하고 또한 코드 변경이 용이해지도록 노력한다. 팀 내에 이러한 정신을 계속 주입한다면 설계는 향상될 것이다.

여기에 소개하는 기법들은 동료들이나 고객들과 일하면서 발견하고 그들에게서 배운 것이다. 오랜 기간 고객들과 일하면서 규칙 없이 짜여진 코드 베이스들에 대한 제어를 만드는 과정에서 나온 것이다. 나는 우연하게 이러한 레거시 코드에 대해 주목하기 시작했다. 처음으로 오브젝트 멘토(Object Mentor)와 관련된 일을 했을 때, 나는 많은 중요한 문제를 가진 팀들이 고품질 코드를 정기적으로 인도하는 단계에 이를 때까지 그들의 기술과 상호작용하는 법을 개발하면서 많은 경험을 쌓았다. 우리는 종종 팀들이 각자의 작업을 제어하고 서로 잘 협력하며 인도하는 데 도움을 주고자 익스트림 프로그래밍(XP, Extreme Programming) 방법론을 사용했다. 난 종종 XP는 훌륭한 소프트웨어를 2주마다 릴리스해야 하는 임무를 가진 잘 훈련된 팀을 만드는 데 사용되기보다는 소프트웨어를 개발하는 데 사용할 수 있는 방법이라고 느낀다.

하지만 처음부터 문제가 하나 있었다. 초창기 XP 프로젝트의 상당수는 ‘그린필드(Greenfield)’ 프로젝트들이었다. 내가 만나는 고객들은 엄청나게 거대한 코드 베이스들을 가지고 있었고 그들은 문제에 직면해 있었다. 그들은 자신들의 작업을 제어하고 제품을 인도하게 해주는 방법을 필요로 했다. 시간이 지나면서 내 자신이 고객들과 동일한 일을 반복하고 있음을 깨달았다. 결국 이런 인식은 그 당시 함께 일하던 금융기업 팀과의 작업에 어떤 영향을 주었다. 내가 오기 전까지만 해도 그들은 단위테스트는 훌륭하다고 생각해 왔다. 하지만 그들이 가지고 있던 테스트 루틴은 데이터베이스에 여러 번 접근해 큰 덩어리의 코드를 돌리는 작업을 하면서 시나리오 전체를 실행하고 있었다. 테스트 루틴들은 작성하기 힘들었고 그 팀은 실행하는 데 너무 긴 시간이 걸린다고 생각해서 테스트 루틴을 자주 돌리지는 않고 있었다. 의존관계를 깨기 위해 그들과 같이 앉아 작은 코드 덩어리를 테스트 하에 두자 갑자기 데자뷰(déjà vu), 즉 기시감(旣視感)을 느끼게 되었다. 마치 이 같은 작업을 지금까지 만났던 모든 팀들과 해온 듯한 묘한 기분을 느꼈는데, 이는 그 어떤 사람도 원치 않는 그런 감정이었다. 그것은 코드를 제어해야 할 때 필요한 중노동에 가까운 작업이다. 그래서 나는 이러한 문제들을 어떻게 해결했는지 책으로 남겨 어려움에 처한 팀들이 코드를 더 쉽게 활용하도록 돕기로 결심했다.

이 책에 사용된 예제들은 자바, C++, C 등 다양한 프로그래밍 언어로 작성됐다. 먼저 자바는 가장 많이 사용되는 언어이다. C++ 는 레거시 환경에서 맞닥뜨릴 수 있는 여러 가지 도전과제들을 보여준다. 또한 C 언어는 절차형 레거시 코드에서 나타나는 여러 가지 문제를 강조하는 데 도움을 준다. 많은 언어 중 위에 언급한 언어들은 레거시 코드에서 발생할 수 있는 여러 가지 관심범위를 포함한다. 당신이 사용하는 언어가 예제에 사용되지 않았다고 해도 예제를 한번 보길 바란다. 예제에서 사용한 여러 가지 기법들은 델파이(Delphi), 비주얼 베이직(Visual Basic), 코볼(COBOL), 포트란(FORTRAN)과 같은 다른 언어들에도 활용할 수 있다.

이 책에 있는 기법들이 많은 도움이 되고 또한 당신이 프로그래밍에 재미를 느끼는 데 좋은 계기가 되길 바란다. 프로그래밍은 매우 보람 있고 즐거운 작업이다. 일상에서 아직까지 이런 기분을 느끼지 못했다면 부디 이 책에서 제공한 기법들에서 보람과 즐거움을 찾게 되길 바란다.


[ 저자 소개 ]

마이클 C. 페더스
오브젝트 멘토 사에서 근무하고 있으며, 소프트웨어 개발에 필요한 멘토링, 기술 개발, 지식 이전, 리더십 서비스 등을 공급하는 세계적인 리더이자 기여자 중 한 사람이다. 현재 테스트 주도 개발(TDD), 리팩토링, 객체지향 설계, 자바, C#, C++, 익스트림 프로그래밍(XP)에 대한 세계적인 트레이닝과 멘토링을 맡고 있다. 또한 JUnit 테스트 프레임워크의 C++ 포트인 CppUint과 통합 테스트 프레임워크 FIT의 C++ 포트인 FitCpp의 원저자로서, ACM과 IEEE 학회의 회원이며 3개의 OOPSLA 컨퍼런스에서 CodeFest의 회장을 역임했다.


[ 옮긴이의 말 ]

최근에 코드 개선과 유지보수 편의를 위한 많은 혁신적인 프로그래밍 언어들과 개발 기법들이 새롭게 만들어져 소개되고 있습니다. 이런 훌륭한 도구들을 사용해 작업하는 데도 아직 많은 개발자들은 기존에 있던 레거시 코드를 변경하고 유지보수하는 일에 많은 시간과 비용을 쏟으며 개선하는 일이 “어렵다”고 호소하고 있습니다. 이 책에서도 집중적으로 다루는 내용이지만, 대부분 기존 소프트웨어는 레거시 코드에서 매우 중요한 개념인 감지(sensing), 분리(separation), 봉합(seams) 같은 개념들을 염두에 두지 않고 작성되었기 때문에 변경하고 유지보수하는 일이 큰 골칫덩어리로 남아 있습니다.

이 책은 조직 내 요구사항의 변화와 외부환경 변화에 부응하기 위해 새로운 특징을 추가하고 버그를 고치고 소프트웨어 설계를 개선하고 자원 이용률을 최적화할 목적으로, 소프트웨어를 잘게 나누고 다시 통합해서 테스트를 위한 코드를 추가하는 등 소프트웨어를 변경하는 데 관련된 내용을 광범위하게 다루고 있습니다. 특히 소프트웨어를 효과적으로 고치는 데 필요한 다양한 기법을 C++, 자바, 루비 코드 예제로 설명하고 있어서 독자가 관련 기법을 쉽게 익힐 수 있도록 도와주고 있습니다. 부디 이 책을 통해 독자 여러분들이 좀더 많이 배우며 생각함으로써 발전하고, 그로 인해 생산성이 높아져 우수한 소프트웨어를 개발할 수 있게 되기를 바랍니다.


[ 옮긴이 소개 ]

이우영
미국 아리조나대학교에서 Computer Engineering 학사, 미국 남가주대학교에서 Electrical Engineering 석사 학위를 받았으며 현재 KT IT기획실에서 데이터 거버넌스 업무를 수행하고 있다. IT, 로봇, 교육에 관심이 있다.

고재한
충남대학교에서 컴퓨터과학 학사, 미국 남가주대학교에서 컴퓨터과학 석사학위를 받았으며 현재 미국 뉴욕주립대에서 컴퓨터과학 박사학위 과정을 밟고 있다. 국민체육진흥공단, 삼성전자, 한국생산기술연구원에 근무했고 국내외 컨퍼런스와 학술지에 10여편의 논문을 게재했다.

목차

• 1부 워밍업: 코드 변경 원리를 이해하라
  
• | 1장 | 소프트웨어 변경 ● 29
  • 소프트웨어를 수정하는 네 가지 이유 ● 29
  • 위험한 변경 ● 35
    
• | 2장 | 효과적인 피드백 활용 ● 37
  • 단위테스트란? ● 40
  • 상위단계 테스트 ● 44
  • 테스트 덮개 ● 44
  • 레거시 코드 변경 알고리즘 ● 48
    
• | 3장 | 감지와 분리 ● 51
  • 협력자 속이기 ● 53
    
• | 4장 | 봉합 모델 ● 61
  • 엄청난 양의 텍스트 ● 61
  • 봉합 ● 62
  • 봉합의 종류 ● 66
    
• | 5장 | 레거시 코드를 위한 도구 ● 83
  • 자동화된 리팩토링 도구 ● 83
  • 모조 객체 ● 86
  • 단위테스트 하니스 ● 86
  • 일반적인 테스트 하니스 ● 93
    
• 2부 본격적인 소프트웨어 변경: 코드 이렇게 고치자
  
• | 6장 | 고칠 건 많고 시간은 없고 ● 97
  • 발아 메소드 ● 100
  • 발아 클래스 ● 104
  • 포장 메소드 ● 109
  • 포장 클래스 ● 114
  • 요약 ● 120
    
• | 7장 | 코드 하나 바꾸는 데 왜 이리 오래 걸리지? ● 121
  • 상황 이해 ● 121
  • 시차 ● 122
  • 의존관계 깨기 ● 124
  • 요약 ● 130
    
• | 8장 | 특징, 어떻게 추가할까? ● 131
  • 테스트 주도 개발 ● 132
  • 비교를 통한 프로그래밍 ● 140
  • 요약 ● 152
    
• | 9장 | 뚝딱! 테스트 하니스에 클래스 제대로 넣기 ● 153
  • 성가신 매개변수의 경우 ● 153
  • 숨은 의존관계인 경우 ● 162
  • 생성 블랍인 경우 ● 165
  • 성가신 전역 의존관계인 경우 ● 168
  • 끔찍한 인클루드 의존관계인 경우 ● 179
  • 양파 매개변수인 경우 ● 184
  • 별칭 붙은 매개변수인 경우 ● 187
    
• | 10장 | 테스트 하니스에서 실행할 수 없는 메소드 ● 191
  • 숨은 메소드인 경우 ● 192
  • 도움이 되는 언어 특징인 경우 ● 196
  • 탐지 불가능한 부작용인 경우 ● 200
    
• | 11장 | 코드 변경 과정에서 꼭 테스트해야 할 메소드 ● 209
  • 효과에 대한 추론 ● 210
  • 전방 추론 ● 216
  • 효과 전파 ● 222
  • 효과 추론을 위한 도구 ● 225
  • 효과 분석을 통한 학습 ● 227
  • 효과 스케치 단순화 ● 228
    
• | 12장 | 클래스 의존관계, 반드시 없애야 할까? ● 233
  • 차단 지점 기법 ● 234
  • 조임 지점을 이용한 설계 판단 ● 242
  • 조임 지점 함정 ● 244
    
• | 13장 | 변경에 필요한 테스트는 뭐가 있을까? ● 245
  • 특성화 테스트 ● 246
  • 클래스 특성화 ● 250
  • 목표 테스트 ● 252
  • 특성화 테스트 작성을 위한 휴리스틱 ● 258
    
• | 14장 | 우릴 미치게 하는 라이브러리 의존관계 ● 259
  
• | 15장 | 응용프로그램이 모두 API 호출로 이뤄졌다면? ● 261
  
• | 16장 | 코드를 잘 고치기엔 내가 모르는 2% ● 273
  • 노트/스케치 ● 274
  • 표식 나열 ● 275
  • 스크래치 리팩토링 ● 277
  • 미사용 코드 삭제 ● 278
    
• | 17장 | 뼈대가 약한 내 응용프로그램 ● 279
  • 시스템 스토리 말하기 ● 281
  • 벌거숭이 CRC ● 286
  • 대화 심사 ● 289
    
• | 18장 | 발목 잡는 테스트 코드 ● 291
  • 클래스 명명 관행 ● 291
  • 테스트 위치 ● 293
    
• | 19장 | 객체지향이 아니라서 위험하다고? 그럼 이렇게 고쳐 봐 ● 295
  • 쉬운 경우 ● 296
  • 어려운 경우 ● 297
  • 새로운 동작 추가 ● 302
  • 객체지향의 장점 이용 ● 305
  • 모두 객체지향적이다 ● 310
    
• | 20장 | 내 프로젝트 군살 빼기 ● 313
  • 책임 찾기 ● 318
  • 다른 기법 ● 334
  • 더 나아가기 ● 334
  • 클래스 추출을 마친 후 ● 338
    
• | 21장 | 동일 코드의 반복 수정, 그만할 수는 없을까? ● 339
  • 첫 번째 단계 ● 343
    
• | 22장 | ‘괴물 메소드’와의 혈투, 승부수는 적절한 테스트 루틴 ● 363
  • 여러 가지 괴물 메소드 ● 364
  • 자동화된 리팩토링 지원으로 괴물 메소드 공략 ● 369
  • 수동 리팩토링 도전 ● 372
  • 전략 ● 381
    
• | 23장 | 위반사항을 점검하는 몇 가지 기법 ● 385
  • 하이퍼웨어 편집 ● 386
  • 단일 목적 편집 ● 387
  • 서명 보전 ● 389
  • 컴파일러 의존 ● 392
    
• | 24장 | 무너진 코드의 하늘, 솟아날 구멍이 있을까? ● 397
  
• 3부 반드시 넘어야 할 산: 코드 변경의 난맥, 의존관계를 극복하라
  
• | 25장 | 의존관계를 깨는 기법 ● 403
  • 매개변수 적응 ● 404
  • 메소드 객체 탈출 ● 408
  • 정의 완료 ● 416
  • 전역 참조 캡슐화 ● 418
  • 정적 메소드 드러내기 ● 426
  • 호출 추출과 오버라이드 ● 430
  • 팩토리 메소드 추출과 오버라이드 ● 432
  • 게터 추출과 오버라이드 ● 435
  • 구현체 추출 ● 439
  • 인터페이스 추출 ● 445
  • 인스턴스 위임자 도입 ● 453
  • 정적 세터 도입 ● 456
  • 연결 대체 ● 463
  • 생성자 매개변수화 ● 464
  • 메소드 매개변수화 ● 469
  • 매개변수 원시화 ● 471
  • 특징 끌어올리기 ● 474
  • 의존관계 밀어내리기 ● 479
  • 함수를 함수포인터로 대체 ● 483
  • 전역 참조를 게터로 대체 ● 487
  • 메소드 하위클래스화와 오버라이드 ● 490
  • 인스턴스 변수 대체 ● 493
  • 템플릿 재정의 ● 498
  • 텍스트 재정의 ● 502
    
• | 부록 | 리팩토링 ● 504

정오표

[ p64 박스 아래로 3행 ]
RostReceiveError는 → PostReceiveError는

[ p77 첫 번째 문장 ]
이 코드에서는 ~ 사용했다. → 이 코드에서는 buildMartSheet 메소드에서 cell을 생성한 후 사용했다.

[ p128 아래에서 5행 ]
AddOpprotunityFormHandler → AddOpportunityFormHandler

[ p132 '테스트 주도 개발' 절 3행 ]
부분을 푸는 데 도움이 되는 한 방법을 구상한다. 그리고 그 방법에 대한 → 부분을 푸는 데 도움이 되는 한 메소드를 구상한다. 그리고 그 메소드에 대한

[ p132 '테스트 주도 개발' 절 4행 ]
기존에 그런 방법이 없고 → 아직 메소드가 만들어지지는 않았으나

[ p155 박스 아래로 1행 ]
이 테스트는 구조테스트이다. 구조테스트는 → 이 테스트는 생성자 테스트이다. 생성자 테스트는

[ p155 박스 아래로 7행 ]
디폴트 구조 → 기본 생성자(default constructor)

[ p156 아래에서 2행 ]
제공하는 방법을 살펴보자 → 제공하는 메소드를 살펴보자

[ p157 1~3행 ]
그것은 ~ 집합처럼 보인다. → 여기서 RGHConnection은, RFDIReportFor나 ACTIOReportFor 등 비즈니스 중심 메소드뿐만 아니라 connect, disconnect, retry 메소드 등 연결을 구성하는 기전을 다루는 메소드들의 집합을 가지고 있는 것처럼 보인다.

[ p157 3행 ]
CreditValidator에 새로운 방법을 → CreditValidator에 새로운 메소드를

[ p157 4행 ]
RFIDReporterFor → RFDIReportFor

[ p157 12행 ]
가짜 클래스를 만듬으로써 → 가짜 클래스를 만듦으로써

[ p159 박스 안 2행 ]
테스트 코드는 생산 코드의 표준처럼 → 테스트 코드는 제작 코드(production code)의 표준처럼

[ p167 아래에서 5행 ]
하지만 제작 코드에서 파기 방법은 사용하지 말아야 한다. 다른 자원을 관리하는 것을 파기하는 객체가 있다면 → 하지만 제작 코드에서 계승 메소드는 사용하지 말아야 한다. 다른 자원을 관리하는 것을 계승하는 객체가 있다면

[ p168 1행 ]
이제 우리는 파기 방법을 → 이제 우리는 계승 메소드를

[ p392 아래에서 2행 ]
카달로그 → 카탈로그

[ p442 아래에서 3행 ]
생성 코드 구현체임을 알린다. → 제작 코드 구현체임을 알린다.

2015-05-21

p155 17행
클래스에는 하나의 구조만 → 클래스에는 하나의 생성자만