Top

레거시 코드 활용 전략 [손대기 두려운 낡은 코드, 안전한 변경과 테스트 기법 (재출간판)]

  • 원서명Working Effectively with Legacy Code (ISBN 9780131177055)
  • 지은이마이클 C. 페더스(Michael C. Feathers)
  • 옮긴이심윤보, 이정문
  • ISBN : 9791161752075
  • 40,000원
  • 2018년 09월 28일 펴냄
  • 페이퍼백 | 540쪽 | 188*235mm
  • 시리즈 : 소프트웨어 테스팅

책 소개

요약

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

추천의 글

유능한 소프트웨어 개발자라면 누구나 요구 사항이 변경될 것을 감안해 설계하고자 한다. 이것은 해결하기 매우 어려운 문제처럼 보인다. 실제로 너무 어렵기 때문에 거의 모든 시스템은 서서히 부패해 결국 망가져버린다. 이 부패는 침투력이 매우 강하며, 이처럼 부패한 프로그램을 가리키는 특별한 이름이 존재한다. 바로 ‘레거시 코드(legacy code)’다.
레거시 코드, 이 단어는 프로그래머의 마음속에 구토를 일으키는 단어다. 마치 끈적이는 거머리와 날카로운 침을 가진 날벌레들로 뒤덮인 덤불 천지의 음산한 늪지대를 걸어가는 것과 같은 이미지를 연상시킨다. 암흑, 점액, 고인 물, 악취라고 불러도 좋다. 우리가 처음 느꼈던 프로그래밍의 강렬한 기쁨도 레거시 코드를 다뤄야 하는 고통에 희석되기 십상이다.
최초에 작성했던 코드가 레거시 코드로 전락하지 않도록 막는 방법을 찾기 위해 수많은 사람들이 노력해왔다. 프로그래머가 시스템의 간결함을 유지하는 데 도움을 줄 수 있는 원칙이나 패턴, 실행 방법 등을 설명하는 책은 이미 많다. 하지만 이 책의 저자 페더스는 지금까지 간과됐던 것에 대한 통찰력을 제시하고 있다. 예방만으로는 충분하지 않다. 최선의 원칙을 숙지하고 최선의 패턴을 사용하며 최선의 실행 방법을 따르는 가장 잘 훈련된 개발 팀조차 때때로 일을 망칠 수 있다. 부패는 계속 쌓여가므로 부패를 방지하는 것만으로는 충분하지 않다. 부패를 되돌릴 수 있어야 하는 것이다.
이것이 바로 이 책의 주제다. 즉, 이 책은 부패를 되돌리는 방법을 다룬다. 복잡하게 얽힌 불명료한 시스템을 단계별로 점진적인 방법을 통해 단순하면서 잘 구조화돼 있고 훌륭하게 설계된 시스템으로 변모시키는 방법을 알려준다.
다만, 지나친 흥분은 가라앉히자. 부패를 되돌리는 것은 쉽지 않으며 단기간에 가능하지도 않다. 이 책에서 제시하는 기술이나 패턴, 도구들은 효과적이지만 그만큼 많은 노력과 시간, 인내, 주의를 요구한다. 이 책은 결코 만병통치약을 제시하지 않는다. 하룻밤 사이에 시스템에 쌓인 모든 부패를 되돌리는 방법은 없다. 대신, 여러분이 앞으로의 개발 업무에서 갖춰야 할 원칙과 개념 및 태도, 그리고 품질이 나빠지고 있는 시스템을 점진적으로 개선하는 데 도움이 되는 방법을 설명할 것이다. / 로버트 C. 마틴

이 책에서 다루는 내용

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

이 책의 구성

1부, ‘코드 변경의 메커니즘’은 소프트웨어 코드를 변경하는 네 가지 이유와 단위 테스트, 레거시 코드를 변경하는 순서, 봉합 모델 등 소프트웨어 변경 기법에 관해 다룬다.
2부, ‘소프트웨어 변경’은 레거시 코드 작업과 관련된 매우 일반적인 질문을 다루고 있으며, 각 장의 제목은 특정한 문제를 가리킨다. 이 때문에 제목이 다소 길어졌지만, 독자들이 필요한 내용을 쉽게 찾는 데 도움이 될 것이다.
2부의 앞뒤로는 도입부에 해당하는 몇 개의 장들(1부, ‘코드 변경의 메커니즘’)과 레거시 코드를 다룰 때 유용한 리팩토링에 관한 내용(3부, ‘의존 관계 제거 기법’)을 배치했다. 도입부의 장들, 특히 4장, ‘봉합 모델’은 꼭 읽길 바란다. 2부에서 사용되는 기법들의 배경지식과 관련 용어들을 설명하기 때문이다. 문맥상 이해되지 않는 용어가 있다면 부록의 ‘용어 사전’을 참조한다.
3부, ‘의존 관계 제거 기법’에서 소개하는 리팩토링 기법들은 테스트 루틴이 없는 상황에서 테스트 수행을 목표로 한다는 점에서 특별하다. 더 많은 선택지를 갖고 레거시 코드를 다루기 위해서라도 3부의 각 장을 읽어볼 것을 권장한다.

저자/역자 소개

지은이의 말

레거시 코드란 무엇일까? 지금까지 이 단어의 뜻을 정의하지 않고 사용했다. 엄밀히 말하면, 레거시 코드는 다른 누군가로부터 이어받은 코드라고 정의할 수 있다. 회사 차원에서 다른 회사로부터 구입한 코드일 수도 있고, 부서 이동으로 인해 다른 팀원에게 인계된 코드일 수도 있다. 이처럼 레거시 코드는 다른 누군가의 코드를 의미하지만, 프로그래머들에게 이 단어는 그 이상의 의미를 갖고 있다. 레거시 코드라는 단어는 시간의 흐름과 함께 더 많은 의미와 무게를 갖게 된 것이다.
레거시 코드라는 말을 들으면 여러분은 어떤 생각이 드는가? 나와 비슷한 생각이 든다면, 여기저기 얽힌 난해한 구조 때문에 제대로 이해하지 못하면서도 수정해야만 하는 코드가 떠오를 것이다. 겉보기에는 쉬워 보였던 기능을 추가하느라 며칠 밤을 지샌 추억이 떠오를 수도 있고, 더 이상 어떻게 할 수 없는 코드에 질려서 무력감에 빠진 모습이 떠오를 수도 있다. 이런 상황에서 당신의 노력은 무가치한 일처럼 느껴진다. 레거시 코드의 정의는 사실 누가 그 코드를 작성했는가와 무관하다. 코드는 다양한 방법으로 부패하며, 대부분의 경우 다른 팀으로부터 가져온 코드인지 여부와는 무관하다.
소프트웨어 업계에서 레거시 코드란 이해할 수 없고 수정하기도 힘든 코드를 지칭하는 속어처럼 사용될 때가 많다. 하지만 지난 수년간 고객들과 심각한 코드 문제들을 해결하는 공동 작업을 통해 나는 레거시 코드를 다르게 정의하게 됐다.
내게 레거시 코드란, 단순히 테스트 루틴이 없는 코드다. 다만 이 정의는 다소 불완전하다. 코드의 좋고 나쁨이 테스트와 어떤 관계가 있을까? 이 질문에 대한 답은 간단하다. 이것이 바로 이 책 전반에 걸쳐 자세히 설명할 핵심이다.
이 책은 어떤 코드베이스에서도 확신을 갖고 수정 작업을 하는 방법을 설명하는 책이다. 이 책의 각 장은 코드를 이해하고, 테스트 루틴을 사용하며, 리팩토링을 수행하고, 기능을 추가하는 기법들을 설명할 것이다.
고객들은 대규모의 코드베이스 작업에 어려움을 겪고 있었기 때문에 개발 작업을 통제하고 제품을 정상적으로 인도할 수 있는 방법론을 필요로 했다. 하지만 시간이 흐르면서, 고객이 바뀌어도 내가 하는 작업은 매번 비슷하다는 사실을 깨닫게 됐다. 이런 느낌은 어느 금융 회사 개발 팀과 협업하면서 최고조에 달했다. 내가 합류하기 전부터 이 개발 팀은 단위 테스트의 필요성을 인식하고 있었지만, 실제 사용 중이던 테스트 루틴은 데이터베이스에 몇 번이나 접근해서 대규모의 코드를 실행하는 전체 시나리오 테스트였다. 당연히 테스트 루틴을 작성하기가 쉽지 않았고, 실행에 너무 오랜 시간이 걸리기 때문에 이 개발 팀은 테스트 루틴을 자주 실행하지 않고 있었다. 이런 현실을 개선하기 위해 팔을 걷어붙이고 테스트 코드의 크기를 줄이는 작업을 하다가 나는 데자뷰(기시감)를 느끼게 됐다. 지금까지 함께 일했던 모든 팀들과 이런 종류의 작업을 했던 것 같았으며, 이 작업은 코드를 적절히 통제하기 위해 어쩔 수 없이 거쳐야만 하는 단순 반복적이고 지루한 작업이었다. 그래서 나는 이러한 문제를 어떻게 해결했는지 책으로 남김으로써, 비슷한 어려움에 처한 다른 팀들이 코드를 좀 더 편하게 개선할 수 있도록 도울 필요가 있다는 결론을 얻었다.
이 책에 사용된 예제들은 대부분 자바, C++, 혹은 C로 작성됐다. 이 언어들을 선택한 것은 자바는 가장 많이 사용되는 언어이기 때문이고, C++는 레거시 환경에서 특별한 도전 과제를 던지는 언어이기 때문이며, C는 절차형 레거시 코드에서 자주 볼 수 있는 문제들을 배울 수 있게 해주는 언어이기 때문이다. 이를 통해 레거시 코드에서 발생하는 문제점의 대부분을 포괄할 수 있다. 독자가 이 언어들을 사용하지 않더라도 예제는 도움이 될 수 있다. 델파이, 비주얼 베이직, 코볼, 포트란 등의 언어들에서도 활용 가능한 기법들이기 때문이다.
이 책의 기법들이 현업에 도움이 될 뿐 아니라 프로그래밍의 재미를 회복하는 계기도 되길 바란다. 프로그래밍은 매우 보람 있고 즐거운 작업이다. 현업의 일상 업무에서 이런 기분을 느끼지 못하고 있다면, 이 책에서 제공되는 기법들을 통해 재발견하고 팀 전체에 전파하기를 희망한다.

지은이 소개

마이클 C. 페더스(Michael C. Feathers)

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

옮긴이의 말

이 책을 읽고 번역하다 보니, 예전에 한창 소프트웨어를 개발하던 시기가 떠올랐다. 그때는 지식과 도구가 미천해 많은 시간을 들여 테스트하고 디버깅했다. printf문을 써가며 변수 값을 일일이 확인했으며, 작은 개선 사항을 테스트하기 위해 전체 코드를 컴파일하기도 했습니다. 물론 이 과정을 통해 버그는 하나씩 사라져갔지만, 코드는 점점 더 관리하기 어려워졌다. 결국, 마지막에는 작은 요구 사항을 반영하는 데도 많은 시간을 소비해야만 했다.
이 책은 이와 같은 상황에서 사용할 수 있는 여러 가지 기법을 알려준다. 어느 곳에 테스트 루틴을 놓고, 어떤 리팩토링 기법을 사용해야 하는지 알 수 있는 통찰력을 길러줄 것이다. 독자 여러분도 소프트웨어를 개발했던 경험이 있다면 이와 같은 일들을 수없이 겪었을 것이다. 하지만 대부분의 개발자들은 일관된 기준 없이 상황에 따라, 혹은 개개인의 역량에 따라 다르게 처리하면서, 일정에 쫓겨 이를 돌아볼 겨를조차 없을 것이다. 캡슐화, 상속 등과 같은 적절한 코딩을 위한 시간 투자보다는 빠른 기능 구현을 통한 납기준수가 우선시되는 현실 때문이다.
이 책의 조언이 여러분의 작업 환경에 그대로 적용되지는 않을 것이다. 사용하는 언어도 많이 바뀌고, 개발 방법도 많이 변화됐다. 하지만 어느 분야에서든 레거시 코드는 존재하고, 관리하기 어려운 코드임은 분명하다. 또한 이 책의 많은 부분에서 리팩토링과 관련된 내용을 다룬다. 리팩토링에 대한 배경지식이 있다면 좀 더 이해하기 쉽겠지만, 없다면 이 책을 통해 리팩토링의 방식을 어느 정도 체험해볼 수 있을 것이다. 여러분이 작업하는 코드에 일괄적으로 적용하기는 어렵겠지만, 기회가 될 때마다 조금씩 레거시 코드에 반영한다면 시간이 지날수록 안전한 코드로 개선돼 있을 것이다. 즉, 코드는 여러분의 통제하에 놓이게 될 것이고, 필요할 때 새로운 요구 사항을 신속히 반영할 수 있을 것이다.

옮긴이 소개

심윤보

성균관대학교와 서울대학교에서 컴퓨터공학을 전공했다. 휴대폰 소프트웨어를 개발했으며, 현재는 IT 기획 및 신기술 도입 업무를 수행하고 있다. 인공지능을 비롯한 4차 산업혁명 기술 전반에 대해 관심이 많다.

이정문

컴퓨터공학을 전공했으며 다수의 원서를 번역했다. 번역서로는 에이콘출판사에서 펴낸 『비기닝 ANSI C++』(2008), 『데이터 과학으로 접근하는 정보보안』(2016), 『파이썬 플레이그라운드』(2016) 등이 있다.

목차

목차
  • 1부. 코드 변경의 메커니즘
  • 1장. 소프트웨어 변경
    • 소프트웨어 코드를 변경하는 네 가지 이유
      • 기능 추가와 버그 수정
      • 설계 개선
      • 최적화
      • 네 가지 이유의 종합
    • 위험한 변경

  • 2장. 피드백 활용
    • 단위 테스트란?
    • 상위 수준의 테스트
    • 테스트를 통한 코드 보호
      • 레거시 코드를 변경하는 순서
      • 변경 지점을 식별한다
      • 테스트 루틴을 작성할 위치를 찾는다
      • 의존 관계를 제거한다
      • 테스트 루틴을 작성한다
      • 변경 및 리팩토링을 수행한다
      • 이후의 내용

  • 3장. 감지와 분리
    • 협업 클래스 위장하기
      • 가짜 객체
      • 가짜 객체의 양면성
      • 가짜 객체의 핵심
      • 모조 객체

  • 4장. 봉합 모델
    • 엄청난 양의 테스트
    • 봉합
    • 봉합의 종류
      • 전처리 봉합
      • 링크 봉합
      • 객체 봉합

  • 5장. 도구
    • 리팩토링 자동화 도구
    • 모조 객체
    • 단위 테스트 하네스
      • JUnit
      • CppUnitLite
      • NUnit
      • 기타 xUnit 프레임워크
    • 일반적인 테스트 하네스
      • FIT
      • 피트니스

  • 2부. 소프트웨어 변경
  • 6장. 고칠 것은 많고 시간은 없고
    • 발아 메소드
      • 장점과 단점
    • 발아 클래스
      • 장점과 단점
    • 포장 메소드
      • 장점과 단점
    • 포장 클래스
    • 요약

  • 7장. 코드 하나 바꾸는 데 왜 이리 오래 걸리지?
    • 코드 이해하기
    • 지연 시간
    • 의존 관계 제거
      • 빌드 의존 관계
    • 요약

  • 8장. 어떻게 기능을 추가할까?
    • 테스트 주도 개발
      • 실패 테스트 케이스 작성
      • 컴파일
      • 테스트 통과시키기
      • 중복 제거
      • 실패 테스트 케이스 작성
      • 컴파일
      • 테스트 통과시키기
      • 중복 제거
      • 테스트 실패 케이스 작성
      • 컴파일
      • 테스트 통과시키기
      • 중복 제거
    • 차이에 의한 프로그래밍
    • 요약

  • 9장. 뚝딱! 테스트 하네스에 클래스 제대로 넣기
    • 성가신 매개변수
    • 숨겨진 의존 관계
    • 복잡한 생성자
    • 까다로운 전역 의존 관계
    • 공포스러운 인클루드 의존 관계
    • 양파껍질 매개변수
    • 별명을 갖는 매개변수

  • 10장. 테스트 하네스에서 이 메소드를 실행할 수 없다
    • 숨어있는 메소드
    • 언어의 편리한 기능
    • 탐지 불가능한 부작용

  • 11장. 코드를 변경해야 한다
    • 영향 추론
    • 전방 추론
    • 영향 전파
    • 영향 추론을 위한 도구
    • 영향 분석을 통한 학습
    • 영향 스케치의 단순화

  • 12장. 클래스 의존 관계, 반드시 없애야 할까?
    • 교차 지점
      • 간단한 경우
      • 상위 수준의 교차 지점
    • 조임 지점을 이용한 설계 판단
    • 조임 지점의 함정

  • 13장. 변경해야 하는데, 어떤 테스트를 작성해야 할지 모르겠다
    • 문서화 테스트
    • 클래스 문서화
    • 정해진 목표가 있는 테스트
    • 문서화 테스트를 작성하기 위한 경험칙

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

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

  • 16장. 변경이 가능할 만큼 코드를 이해하지 못하는 경우
    • 노트/스케치
    • 표시 나열
      • 책임 분리
      • 메소드 구조의 이해
      • 메소드 추출
      • 변경 영향의 이해
    • 스크래치 리팩토링
    • 미사용 코드 삭제

  • 17장. 내 애플리케이션은 뼈대가 약하다
    • 시스템의 스토리텔링
    • 네이키드 CRC
    • 대화 음미

  • 18장. 테스트 코드가 방해를 한다
    • 클래스 명명 규칙
    • 테스트 코드의 배치

  • 19장. 내 프로젝트는 객체 지향이 아니다
    • 간단한 경우
    • 어려운 경우
    • 새로운 동작의 추가
    • 객체 지향의 장점 이용
    • 모든 것이 객체 지향적이다

  • 20장. 이 클래스는 너무 비대해서 더 이상 확장하고 싶지 않다
    • 책임 파악
    • 그 밖의 기법들
    • 더 나아가기
      • 전략
      • 전술
    • 클래스 추출을 마친 후

  • 21장. 반복되는 동일한 수정, 그만할 수는 없을까?
    • 첫 번째 단계

  • 22장. ‘괴물 메소드’를 변경해야 하는데 테스트 코드를 작성하지 못하겠다
    • 괴물 메소드의 다양한 종류
      • 불릿 메소드
      • 혼잡 메소드
    • 리팩토링 자동화 도구를 사용해 괴물 메소드 공략하기
    • 수동 리팩토링에 도전
      • 감지 변수 도입
      • 아는 부분 추출하기
      • 의존 관계 이삭줍기
      • 메소드 객체 추출
    • 전략
      • 뼈대 메소드
      • 처리 시퀀스 발견
      • 우선 현재 클래스 내에서 추출
      • 작은 조각 추출
      • 추출을 다시 할 각오

  • 23장. 기존 동작을 건드리지 않았음을 어떻게 확인할 수 있을까?
    • 초집중 모드에서 편집하기
    • 단일 목적 편집
    • 서명 유지
    • 컴파일러 의존
      • 짝 프로그래밍

  • 24장. 어찌해야 할지 모르겠다. 나아질 것 같지 않아
    • 3부 의존 관계 제거 기법
    • 25장 의존 관계 제거 기법
    • 매개변수 적응
    • 메소드 객체 추출
    • 정의 완성
    • 전역 참조 캡슐화
    • 정적 메소드 드러내기
    • 호출 추출과 재정의
    • 팩토리 메소드 추출과 재정의
    • get 메소드 추출과 재정의
    • 구현체 추출
    • 더 복잡한 예제
    • 인터페이스 추출
    • 인스턴스 위임 도입
    • 정적 set 메소드 도입
    • 연결 대체
    • 생성자 매개변수화
    • 메소드 매개변수화
    • 매개변수 원시화
    • 특징 끌어올리기
    • 의존 관계 밀어 내리기
    • 함수를 함수 포인터로 대체
    • 전역 참조를 get 메소드로 대체
    • 서브클래스화와 메소드 재정의
    • 인스턴스 변수 대체
    • 템플릿 재정의
    • 텍스트 재정의

  • 부록. 리팩토링


도서 오류 신고

도서 오류 신고

에이콘출판사에 관심을 가져 주셔서 고맙습니다. 도서의 오탈자 정보를 알려주시면 다음 개정판 인쇄 시 반영하겠습니다.

오탈자 정보는 다음과 같이 입력해 주시면 됩니다.

(예시) p.100 아래에서 3행 : '몇일'동안 -> 며칠동안