장바구니 담기 close

장바구니에 상품을 담았습니다.

장바구니로 계속쇼핑하기
레거시 코드 활용 전략
미리보기

레거시 코드 활용 전략

  • 마이클C.페더스
  • |
  • 에이콘출판
  • |
  • 2018-09-28 출간
  • |
  • 540페이지
  • |
  • 188 X 235 X 26 mm
  • |
  • ISBN 9791161752075
판매가

40,000원

즉시할인가

36,000 원

카드할인

0원(즉시할인 0%)

적립금

2,000원 적립(5%적립)

배송비

무료배송

(제주/도서산간 배송 추가비용:3,000원)

추가혜택

네이버페이 무조건 1%적립+ 추가 1%적립

추가상품
상품선택
독서대 7,900원 독서대 선택안함 0원
수량
+ -
총주문금액
36,000원
장바구니 구매하기

※ 스프링제본 상품은 반품/교환/환불이 불가능하므로 신중하게 선택하여 주시기 바랍니다.

북스크린영상으로 만나보는 한 권의 책 이야기

출판사서평




★ 요약 ★

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

★ 이 책에서 다루는 내용 ★

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

★ 이 책의 구성 ★

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

★ 옮긴이의 말 ★

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


목차


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 메소드로 대체
__서브클래스화와 메소드 재정의
__인스턴스 변수 대체
__템플릿 재정의
__텍스트 재정의

부록. 리팩토링
추천포스트

교환 및 환불안내

도서교환 및 환불
  • ㆍ배송기간은 평일 기준 1~3일 정도 소요됩니다.(스프링 분철은 1일 정도 시간이 더 소요됩니다.)
  • ㆍ상품불량 및 오배송등의 이유로 반품하실 경우, 반품배송비는 무료입니다.
  • ㆍ고객님의 변심에 의한 반품,환불,교환시 택배비는 본인 부담입니다.
  • ㆍ상담원과의 상담없이 교환 및 반품으로 반송된 물품은 책임지지 않습니다.
  • ㆍ이미 발송된 상품의 취소 및 반품, 교환요청시 배송비가 발생할 수 있습니다.
  • ㆍ반품신청시 반송된 상품의 수령후 환불처리됩니다.(카드사 사정에 따라 카드취소는 시일이 3~5일이 소요될 수 있습니다.)
  • ㆍ주문하신 상품의 반품,교환은 상품수령일로 부터 7일이내에 신청하실 수 있습니다.
  • ㆍ상품이 훼손된 경우 반품 및 교환,환불이 불가능합니다.
  • ㆍ반품/교환시 고객님 귀책사유로 인해 수거가 지연될 경우에는 반품이 제한될 수 있습니다.
  • ㆍ스프링제본 상품은 교환 및 환불이 불가능 합니다.
  • ㆍ군부대(사서함) 및 해외배송은 불가능합니다.
  • ㆍ오후 3시 이후 상담원과 통화되지 않은 취소건에 대해서는 고객 반품비용이 발생할 수 있습니다.
반품안내
  • 마이페이지 > 나의상담 > 1 : 1 문의하기 게시판 또는 고객센터 1800-7327
교환/반품주소
  • 경기도 파주시 문발로 211 1층 / (주)북채널 / 전화 : 1800-7327
  • 택배안내 : CJ대한통운(1588-1255)
  • 고객님 변심으로 인한 교환 또는 반품시 왕복 배송비 5,000원을 부담하셔야 하며, 제품 불량 또는 오 배송시에는 전액을 당사에서부담 합니다.