레거시 코드 활용 전략 (2018)

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장 의존 관계

시스템 내에 오래된 코드를 다루는 방법을 배울 수 있다. 오래된 코드, 즉 레거시 코드는 그 코드에 익숙한 사람도 없고, 테스트 루틴도 없어 관리하기 어렵다. 저자는 다년간의 현장 경험과 실제 코드를 바탕으로 다양한 기법을 소개한다. 여러 언어뿐만 아니라, 현업에서 사용되는 도구에 대해 현실적인 조언을 해준다. 코드 내 의존 관계 해결, 효과적 테스팅 방법 등 24가지 기법을 통해 시스템의 낡은 코드를 변경, 관리하는 데 있어 많은 통찰력을 줄 것이다. ★ 이 책에서 다루는 내용 ★ ■ 기능 추가, 버그 수정, 설계 개선, 성능 최적화 등의 소프트웨어 변경 기법 ■ 레거시 코드를 테스트 하네스 안에 넣는 방법 ■ 새로운 문제 발생으로부터 시스템을 보호해주는 테스트 루틴 작성법 ■ 자바, C++, C, C# 언어로 작성된 예제를 통해 소개하는 어떤 언어나 플랫폼에도 사용 가능한 기법 ■ 코드에서 수정해야 할 부분을 정확히 찾아내는 방법 ■ 객체 지향적으로 작성되지 않은 레거시 시스템을 다루는 기법 ■ 구조가 모호한 애플리케이션을 다루는 방법 ★ 이 책의 구성 ★ 1부, ‘코드 변경의 메커니즘’은 소프트웨어 코드를 변경하는 네 가지 이유와 단위 테스트, 레거시 코드를 변경하는 순서, 봉합 모델 등 소프트웨어 변경 기법에 관해 다룬다. 2부, ‘소프트웨어 변경’은 레거시 코드 작업과 관련된 매우 일반적인 질문을 다루고 있으며, 각 장의 제목은 특정한 문제를 가리킨다. 이 때문에 제목이 다소 길어졌지만, 독자들이 필요한 내용을 쉽게 찾는 데 도움이 될 것이다. 2부의 앞뒤로는 도입부에 해당하는 몇 개의 장들(1부, ‘코드 변경의 메커니즘’)과 레거시 코드를 다룰 때 유용한 리팩토링에 관한 내용(3부, ‘의존 관계 제거 기법’)을 배치했다. 도입부의 장들, 특히 4장, ‘봉합 모델’은 꼭 읽길 바란다. 2부에서 사용되는 기법들의 배경지식과 관련 용어들을 설명하기 때문이다. 문맥상 이해되지 않는 용어가 있다면 부록의 ‘용어 사전’을 참조한다. 3부, ‘의존 관계 제거 기법’에서 소개하는 리팩토링 기법들은 테스트 루틴이 없는 상황에서 테스트 수행을 목표로 한다는 점에서 특별하다. 더 많은 선택지를 갖고 레거시 코드를 다루기 위해서라도 3부의 각 장을 읽어볼 것을 권장한다.

레거시 코드 활용 전략

코멘트

더 많은 코멘트를 보려면 로그인해 주세요!

목차

출판사 제공 책 소개

이 작품이 담긴 컬렉션