레거시 코드 활용 전략

★ 요약 ★



시스템 내에 오래된 코드를 다루는 방법을 배울 수 있다. 오래된 코드, 즉 레거시 코드는 그 코드에 익숙한 사람도 없고, 테스트 루틴도 없어 관리하기 어렵다. 저자는 다년간의 현장 경험과 실제 코드를 바탕으로 다양한 기법을 소개한다. 여러 언어뿐만 아니라, 현업에서 사용되는 도구에 대해 현실적인 조언을 해준다. 코드 내 의존 관계 해결, 효과적 테스팅 방법 등 24가지 기법을 통해 시스템의 낡은 코드를 변경, 관리하는 데 있어 많은 통찰력을 줄 것이다.



★ 이 책에서 다루는 내용 ★



■ 기능 추가, 버그 수정, 설계 개선, 성능 최적화 등의 소프트웨어 변경 기법

■ 레거시 코드를 테스트 하네스 안에 넣는 방법

■ 새로운 문제 발생으로부터 시스템을 보호해주는 테스트 루틴 작성법

■ 자바, C++, C, C# 언어로 작성된 예제를 통해 소개하는 어떤 언어나 플랫폼에도 사용 가능한 기법

■ 코드에서 수정해야 할 부분을 정확히 찾아내는 방법

■ 객체 지향적으로 작성되지 않은 레거시 시스템을 다루는 기법

■ 구조가 모호한 애플리케이션을 다루는 방법



★ 이 책의 구성 ★



1부, '코드 변경의 메커니즘'은 소프트웨어 코드를 변경하는 네 가지 이유와 단위 테스트, 레거시 코드를 변경하는 순서, 봉합 모델 등 소프트웨어 변경 기법에 관해 다룬다.

2부, '소프트웨어 변경'은 레거시 코드 작업과 관련된 매우 일반적인 질문을 다루고 있으며, 각 장의 제목은 특정한 문제를 가리킨다. 이 때문에 제목이 다소 길어졌지만, 독자들이 필요한 내용을 쉽게 찾는 데 도움이 될 것이다.

2부의 앞뒤로는 도입부에 해당하는 몇 개의 장들(1부, '코드 변경의 메커니즘')과 레거시 코드를 다룰 때 유용한 리팩토링에 관한 내용(3부, '의존 관계 제거 기법')을 배치했다. 도입부의 장들, 특히 4장, '봉합 모델'은 꼭 읽길 바란다. 2부에서 사용되는 기법들의 배경지식과 관련 용어들을 설명하기 때문이다. 문맥상 이해되지 않는 용어가 있다면 부록의 '용어 사전'을 참조한다.

3부, '의존 관계 제거 기법'에서 소개하는 리팩토링 기법들은 테스트 루틴이 없는 상황에서 테스트 수행을 목표로 한다는 점에서 특별하다. 더 많은 선택지를 갖고 레거시 코드를 다루기 위해서라도 3부의 각 장을 읽어볼 것을 권장한다.



★ 옮긴이의 말 ★



이 책을 읽고 번역하다 보니, 예전에 한창 소프트웨어를 개발하던 시기가 떠올랐다. 그때는 지식과 도구가 미천해 많은 시간을 들여 테스트하고 디버깅했다. printf문을 써가며 변수 값을 일일이 확인했으며, 작은 개선 사항을 테스트하기 위해 전체 코드를 컴파일하기도 했습니다. 물론 이 과정을 통해 버그는 하나씩 사라져갔지만, 코드는 점점 더 관리하기 어려워졌다. 결국, 마지막에는 작은 요구 사항을 반영하는 데도 많은 시간을 소비해야만 했다.

이 책은 이와 같은 상황에서 사용할 수 있는 여러 가지 기법을 알려준다. 어느 곳에 테스트 루틴을 놓고, 어떤 리팩토링 기법을 사용해야 하는지 알 수 있는 통찰력을 길러줄 것이다. 독자 여러분도 소프트웨어를 개발했던 경험이 있다면 이와 같은 일들을 수없이 겪었을 것이다. 하지만 대부분의 개발자들은 일관된 기준 없이 상황에 따라, 혹은 개개인의 역량에 따라 다르게 처리하면서, 일정에 쫓겨 이를 돌아볼 겨를조차 없을 것이다. 캡슐화, 상속 등과 같은 적절한 코딩을 위한 시간 투자보다는 빠른 기능 구현을 통한 납기준수가 우선시되는 현실 때문이다.

이 책의 조언이 여러분의 작업 환경에 그대로 적용되지는 않을 것이다. 사용하는 언어도 많이 바뀌고, 개발 방법도 많이 변화됐다. 하지만 어느 분야에서든 레거시 코드는 존재하고, 관리하기 어려운 코드임은 분명하다. 또한 이 책의 많은 부분에서 리팩토링과 관련된 내용을 다룬다. 리팩토링에 대한 배경지식이 있다면 좀 더 이해하기 쉽겠지만, 없다면 이 책을 통해 리팩토링의 방식을 어느 정도 체험해볼 수 있을 것이다. 여러분이 작업하는 코드에 일괄적으로 적용하기는 어렵겠지만, 기회가 될 때마다 조금씩 레거시 코드에 반영한다면 시간이 지날수록 안전한 코드로 개선돼 있을 것이다. 즉, 코드는 여러분의 통제하에 놓이게 될 것이고, 필요할 때 새로운 요구 사항을 신속히 반영할 수 있을 것이다.

추천의 글

지은이 소개

지은이의 말

감사의 글

옮긴이 소개

옮긴이의 말

들어가며



1부. 코드 변경의 메커니즘

1장. 소프트웨어 변경

2장. 피드백 활용

3장. 감지와 분리

4장. 봉합 모델

5장. 도구



2부. 소프트웨어 변경

6장. 고칠 것은 많고 시간은 없고

7장. 코드 하나 바꾸는 데 왜 이리 오래 걸리지?

8장. 어떻게 기능을 추가할까?

9장. 뚝딱! 테스트 하네스에 클래스 제대로 넣기

10장. 테스트 하네스에서 이 메소드를 실행할 수 없다

11장. 코드를 변경해야 한다

12장. 클래스 의존 관계, 반드시 없애야 할까?

13장. 변경해야 하는데, 어떤 테스트를 작성해야 할지 모르겠다

14장. 나를 미치게 하는 라이브러리 의존 관계

15장. 애플리케이션에 API 호출이 너무 많다

16장. 변경이 가능할 만큼 코드를 이해하지 못하는 경우

17장. 내 애플리케이션은 뼈대가 약하다

18장. 테스트 코드가 방해를 한다

19장. 내 프로젝트는 객체 지향이 아니다

20장. 이 클래스는 너무 비대해서 더 이상 확장하고 싶지 않다

21장. 반복되는 동일한 수정, 그만할 수는 없을까?

22장. '괴물 메소드'를 변경해야 하는데 테스트 코드를 작성하지 못하겠다

23장. 기존 동작을 건드리지 않았음을 어떻게 확인할 수 있을까?

24장. 어찌해야 할지 모르겠다. 나아질 것 같지 않아



3부 의존 관계 제거 기법

25장 의존 관계 제거 기법



부록. 리팩토링

용어 사전

찾아보기

마이클 C. 페더스 멘토링, 능력 개발, 지식 전달, 소프트웨어 개발 관리 등 서비스 제공 분야의 글로벌 리더 업체인 오브젝트 멘토에 근무하고 있다. 테스트 주도 개발, 리팩토링, 객체 지향 설계, 자바, C#, C++, 익스트림 프로그래밍에 대한 트레이닝과 멘토링 등의 컨설팅을 다수 수행했으며, JUnit 테스트 프레임워크의 C++ 버전인 CppUnit과 통합 테스트 프레임워크 FIT의 C++ 버전인 FitCpp의 개발자이기도 하다. ACM과 IEEE 회원이다. OOPSLA 콘퍼런스(객체 지향 기법에 관한 국제 콘퍼런스)에서 코드 페스티벌 의장을 세 차례 맡았다.