파이브 라인스 오브 코드

다섯 줄 제한 규칙으로 시작하는 체계적이고 효과적인 리팩터링 수련법

크리스찬 클라우젠 저자(글) · 김성원 번역

위키북스 · 2023년 01월 19일

책 소개

구체적인 규칙에 초점을 맞춰 모든 메서드를 5줄 이하로 줄이는 리팩터링을 가르쳐 준다!

기존 코드를 개선하는 것(리팩터링)은 프로그래머가 맞닥뜨리는 가장 일반적인 작업 중 하나다. 《파이브 라인스 오브 코드》는 코드 스멜과 같은 감각적인 판단에 의존하지 않고, 적용할 수 있는 명확하고 실행 가능한 리팩터링 규칙을 알려준다. 구체적인 원칙을 따르다 보면 리팩터링과 코드 스멜을 익힐 수 있다는 저자의 전문적인 관점에 따라 언제 코드를 리팩터링해야 하는지, 어떤 문제에 어떤 패턴을 적용할지, 재작업이 필요한 코드에는 어떤 특성이 있는지 배우게 된다.
프로그래머가 다루는 모든 코드 베이스에는 찾아서 수정해야 하는 실수와 효율적인지 않은 부분이 있다. 올바른 방법으로 리팩터링하면 코드가 세련되고 읽기 쉽고 유지 관리가 쉬워진다. 이 책에서는 모든 메서드를 5줄 이하로 구현하는 리팩터링에 대한 독창적인 접근 방식을 배운다.
이 책은 모든 기술 수준의 개발자가 읽을 수 있으며, 예제는 자바 및 C#과 동일한 스타일로 읽기 쉬운 타입스크립트를 사용한다.

★ 이 책에서 다루는 내용 ★

◎ 나쁜 코드의 특성
◎ 코드를 이해하지 않고도 안전하게 코드를 개선하는 방법
◎ 최적화와 코드 일반성의 균형 맞추기
◎ 적절한 컴파일러의 활용
◎ 메서드 추출 및 전략 패턴의 도입과 그 밖의 다양한 리팩터링 패턴
◎ 코드 추가를 통해 변경을 가능하게 하는 안정적인 코드 작성
◎ 주석이 필요 없는 코드 작성
◎ 훌륭한 리팩터링을 위한 실제 사례

작가정보

저자(글) 크리스찬 클라우젠

Christian Clausen
크리스찬 클라우젠은 컴퓨터 과학 석사 학위를 보유하고 있다. 그는 프로그래밍 언어, 특히 소프트웨어 품질과 버그 없이 코딩하는 방법을 전공했다. 소프트웨어 품질에 관한 두 개의 동료 리뷰 논문을 공동 집필했으며, 이는 권위 있는 저널과 콘퍼런스에 게재되었다. 그는 파리의 한 연구 그룹에서 코시넬(Coccinelle)이라는 프로젝트의 소프트웨어 엔지니어로 일했으며, 두 대학에서 객체지향 프로그래밍 언어와 함수형 프로그래밍 언어에 대한 입문 및 고급 프로그래밍 주제를 가르쳤다. 크리스찬은 5년 동안 컨설턴트 및 기술 책임자로 일했다.

번역 김성원

대학원에서 정보보안을 전공했으며, 2000년부터 안랩 등 여러 회사에 근무하면서 다양한 언어로 엔터프라이즈용 응용 프로그램의 설계와 개발에 참여해 왔다. 최근에는 음성인식, 영상인식, NLP 기술에 관심을 가지고 있다.
《새로 쓰는 자바 웹 프로그래밍》(영진닷컴, 2002), 《쉽게 풀어 쓴 자바 데이터베이스 프로그래밍》(영진닷컴, 2003)을 집필했고, 《iPhone 게임 개발자 레퍼런스》(영진닷컴, 2010), 《코딩인터뷰 퀘스천》(영진닷컴, 2014), 《Node.js 디자인 패턴 바이블》(영진닷컴, 2021), 《코딩 테스트로 시작하는 파이썬 프로그래밍》(영진닷컴, 2022) 등 평소 궁금해하는 분야와 관련된 번역을 즐긴다

목차

• ▣ 1장: 리팩터링 리팩터링하기
  1.1 리팩터링이란 무엇인가?
  1.2 스킬: 무엇을 리팩터링할 것인가?
  __1.2.1 코드 스멜의 예
  __1.2.2 규칙의 예
  1.3 문화: 리팩터링은 언제 할까?
  __1.3.1 레거시 시스템에서의 리팩터링
  __1.3.2 언제 리팩터링을 하지 말아야 할까?
  1.4 도구: (안전한) 리팩터링 방법
  1.5 시작하는 데 필요한 도구
  __1.5.1 프로그래밍 언어: 타입스크립트
  __1.5.2 편집기: 비주얼 스튜디오 코드 1
  __1.5.3 버전 관리: Git
  1.6 핵심 예제: 2D 퍼즐 게임
  __1.6.1 연습만이 살 길이다: 두 번째 코드베이스
  1.7 실제 환경에서 소프트웨어에 대한 주의 사항
  요약
  
  ▣ 2장: 리팩터링 깊게 들여다보기
  2.1 가독성 및 유지보수성 향상
  __2.1.1 코드 개선
  __2.1.2 코드가 하는 일을 바꾸지 않고 유지보수하기
  2.2 속도, 유연성 및 안정성 확보
  __2.2.1 상속보다는 컴포지션 사용
  __2.2.2 수정이 아니라 추가로 코드를 변경
  2.3 리팩터링과 일상 업무
  __2.3.1 학습 방법으로서의 리팩터링
  2.4 소프트웨어 분야에서 ‘도메인’ 정의하기
  요약
  
  ▣ 3장: 긴 코드 조각내기
  3.1 첫 번째 규칙: 왜 다섯 줄인가?
  __3.1.1 규칙: 다섯 줄 제한
  3.2 함수 분해를 위한 리팩터링 패턴 소개
  __3.2.1 리팩터링 패턴: 메서드 추출
  3.3 추상화 수준을 맞추기 위한 함수 분해
  __3.3.1 규칙: 호출 또는 전달, 한 가지만 할 것
  __3.3.2 규칙 적용
  3.4 좋은 함수 이름의 속성
  3.5 너무 많은 일을 하는 함수 분리하기
  __3.5.1 규칙: if 문은 함수의 시작에만 배치
  __3.5.2 규칙 적용
  요약
  
  ▣ 4장: 타입 코드 처리하기
  4.1 간단한 if 문 리팩터링
  __4.1.1 규칙: if 문에서 else를 사용하지 말 것
  __4.1.2 규칙 적용
  __4.1.3 리팩터링 패턴: 클래스로 타입 코드 대체
  __4.1.4 클래스로 코드 이관하기
  __4.1.5 리팩터링 패턴: 클래스로의 코드 이관
  __4.1.6 불필요한 메서드 인라인화
  __4.1.7 리팩터링 패턴: 메서드의 인라인화
  4.2 긴 if 문의 리팩터링
  __4.2.1 일반성 제거
  __4.2.2 리팩터링 패턴: 메서드 전문화
  __4.2.3 switch가 허용되는 유일한 경우
  __4.2.4 규칙: switch를 사용하지 말 것
  __4.2.5 if 제거하기
  4.3 코드 중복 처리
  __4.3.1 인터페이스 대신 추상 클래스를 사용할 수는 없을까?
  __4.3.2 규칙: 인터페이스에서만 상속받을 것
  __4.3.3 클래스에 있는 코드의 중복은 다 무엇일까?
  4.4 복잡한 if 체인 구문 리팩터링
  4.5 필요 없는 코드 제거하기
  __4.5.1 리팩터링 패턴: 삭제 후 컴파일하기
  요약
  
  ▣ 5장: 유사한 코드 융합하기
  5.1 유사한 클래스 통합하기
  __5.1.1 리팩터링 패턴: 유사 클래스 통합
  5.2 단순한 조건 통합하기
  __5.2.1 리팩터링 패턴: if 문 결합
  5.3 복잡한 조건 통합하기
  __5.3.1 조건을 위한 산술 규칙 사용
  __5.3.2 규칙: 순수 조건 사용
  __5.3.3 조건 산술 적용
  5.4 클래스 간의 코드 통합
  __5.4.1 클래스 관계를 묘사하기 위한 UML 클래스 다이어그램 소개
  __5.4.2 리팩터링 패턴: 전략 패턴의 도입
  __5.4.3 규칙: 구현체가 하나뿐인 인터페이스를 만들지 말 것
  __5.4.4 리팩터링 패턴: 구현에서 인터페이스 추출
  5.5 유사 함수 통합하기
  5.6 유사한 코드 통합하기
  요약
  
  ▣ 6장: 데이터 보호
  6.1 getter 없이 캡슐화하기
  __6.1.1 규칙: getter와 setter를 사용하지 말 것
  __6.1.2 규칙 적용하기
  __6.1.3 리팩터링 패턴: getter와 setter 제거하기
  __6.1.4 마지막 getter 삭제
  6.2 간단한 데이터 캡슐화하기
  __6.2.1 규칙: 공통 접사를 사용하지 말 것
  __6.2.2 규칙 적용하기
  __6.2.3 리팩터링 패턴: 데이터 캡슐화
  6.3 복잡한 데이터 캡슐화
  6.4 순서에 존재하는 불변속성 제거하기
  __6.4.1 리팩터링 패턴: 순서 강제화
  6.5 열거형을 제거하는 또 다른 방법
  __6.5.1 비공개 생성자를 통한 열거
  __6.5.2 숫자를 클래스에 다시 매핑하기
  요약
  
  ▣ 7장: 컴파일러와의 협업
  7.1 컴파일러에 대해 알아보기
  __7.1.1 약점: 정지 문제는 컴파일 시 알 수 있는 것을 제한한다
  __7.1.2 장점: 도달성 검증은 메서드의 반환을 보장한다
  __7.1.3 장점: 확정 할당은 초기화되지 않은 변수에 대한 접근을 막는다
  __7.1.4 장점: 접근 제어로 데이터 캡슐화를 지원한다
  __7.1.5 장점: 타입(형) 검사기는 속성을 보증한다
  __7.1.6 약점: null을 역참조하면 애플리케이션이 손상된다
  __7.1.7 약점: 산술 오류는 오버플로나 손상을 일으킨다
  __7.1.8 약점: 아웃-오브-바운드 오류는 애플리케이션을 손상시킨다
  __7.1.9 무한루프는 애플리케이션을 지연시킨다
  __7.1.10 약점: 교착 상태 및 경쟁 상태로 인해 의도하지 않은 동작이 발생한다
  7.2 컴파일러 사용
  __7.2.1 컴파일러 활용
  __7.2.2 컴파일러와 싸우지 말 것
  7.3 컴파일러 신뢰하기
  __7.3.1 컴파일러에게 불변속성 가르치기
  __7.3.2 컴파일러의 경고에 주의를 기울일 것
  7.4 컴파일러만 신뢰할 것
  요약
  
  ▣ 8장: 주석 자제하기
  8.1 오래된 주석 제거
  8.2 주석 처리된 코드 제거
  8.3 불필요한 주석 제거
  8.4 메서드의 이름으로 주석 대신하기
  __8.4.1 계획을 위한 주석 사용
  8.5 불변속성을 문서화한 주석 유지
  __8.5.1 프로세스의 불변속성
  요약
  
  ▣ 9장: 코드 삭제의 미학
  9.1 다음 시대는 코드를 지우는 시대일 것이다
  9.2 복잡성을 제거하기 위한 코드 삭제
  __9.2.1 경험 부족으로 인한 기술적 무지
  __9.2.2 시간 압박으로 인한 기술적 낭비
  __9.2.3 환경에 따른 기술적 부채
  __9.2.4 성장에 따른 기술적 장애물
  9.3 친밀도에 따른 코드 분류
  9.4 레거시 시스템에서의 코드 삭제
  __9.4.1 스트랭글러 무화과나무 패턴
  __9.4.2 코드 개선을 위한 스트랭글러 무화과나무 패턴 사용
  9.5 동결된 프로젝트에서 코드 삭제
  __9.5.1 바람직한 결과를 기본값으로 설정
  __9.5.2 스파이크와 스태빌라이즈(안정화)로 낭비 줄이기
  9.6 버전 관리에서 브랜치 삭제
  __9.6.1 브랜치 제한으로 낭비 최소화
  9.7 코드 문서 삭제
  __9.7.1 지식을 문서화하는 방법을 결정하는 알고리즘
  9.8 테스트 코드 삭제
  __9.8.1 낙관적 테스트 삭제
  __9.8.2 비관적 테스트 삭제
  __9.8.3 불안정 테스트 수정 또는 삭제
  __9.8.4 복잡한 테스트를 제거하기 위한 코드 리팩터링
  __9.8.5 속도를 높이는 테스트 문화
  9.9 설정 코드 삭제
  __9.9.1 설정의 예상 수명으로 범위 지정
  9.10 라이브러리 제거를 위한 코드 삭제
  __9.10.1 외부 라이브러리에 대한 의존도 제한
  9.11 작동 중인 기능에서 코드 삭제
  요약
  
  ▣ 10장: 코드 추가에 대한 두려움 떨쳐내기
  10.1 불확실성 받아들이기: 위험 감수
  10.2 두려움 극복을 위한 스파이크 사용
  10.3 낭비나 위험에 대한 두려움 극복을 위한 사용 시간 비율 지정
  10.4 불완전성에 대한 두려움 극복을 위한 점진적 개선
  10.5 복사 및 붙여넣기가 속도에 미치는 영향
  10.6 확장성을 통한 추가에 의한 변경
  10.7 추가에 의한 변경으로 이전 버전과의 호환성 확보
  10.8 기능 토글(켜기/끄기)로 추가에 의한 변경
  10.9 ‘추상화를 통한 분기’로 추가에 의한 변경
  요약
  
  ▣ 11장: 코드 구조 따르기
  11.1 범위와 출처에 따른 구조 분류
  11.2 행위를 코드화하는 세 가지 방법
  __11.2.1 제어 흐름에 행위 코드화하기
  __11.2.2 데이터 구조에 행위 코드화하기
  __11.2.3 데이터에 행위 코드화하기
  11.3 구조 노출을 위한 코드 추가
  11.4 예측 대신 관찰, 그리고 경험적 기술 사용
  11.5 코드를 이해하지 않고도 안전성을 확보하는 방안
  __11.5.1 테스트를 통한 안전성 확보
  __11.5.2 숙달을 통한 안전성 확보
  __11.5.3 도구의 지원을 통한 안전성 확보
  __11.5.4 공식 인증을 통한 안전성 확보
  __11.5.5 내결함성을 통한 안전성 확보
  11.6 활용되지 않은 구조 이용
  __11.6.1 추출 및 캡슐화에 공백 활용
  __11.6.2 통합에 중복 코드 활용
  __11.6.3 캡슐화로 공통 접사 활용
  __11.6.4 동적 실행으로 런타임 유형 활용
  요약
  
  ▣ 12장: 최적화 및 일반화 회피
  12.1 단순성 추구
  12.2 일반화의 시기와 방법
  __12.2.1 구현의 최소화로 일반화 지양하기
  __12.2.2 안정성이 유사한 것 통합하기
  __12.2.3 불필요한 일반화 제거
  12.3 최적화 시기와 방법
  __12.3.1 최적화 전 리팩터링
  __12.3.2 제약 이론에 따른 최적화
  __12.3.3 측정 지표를 사용한 최적화
  __12.3.4 좋은 알고리즘과 데이터 구조 선택하기
  __12.3.5 캐시 사용하기
  __12.3.6 최적화된 코드 분리하기
  요약
  
  ▣ 13장: 나쁜 코드를 식별 가능하게 만들기
  13.1 나쁜 코드에 대처하는 자세
  13.2 깨끗한 코드와 레거시 코드로 분리
  __13.2.1 깨진 유리창 이론
  13.3 나쁜 코드를 찾는 방법
  __13.3.1 이 책의 규칙: 단순하고 구체적인 코드
  __13.3.2 코드 스멜: 완전하고 추상적인 코드
  __13.3.3 순환 복잡도: 알고리즘(객관적)
  __13.3.4 인지 복잡도: 알고리즘(주관적)
  13.4 코드를 안전하게 나쁜 코드로 보이기 위한 규칙
  13.5 나쁜 코드를 나쁘게 보이기 위한 방법
  __13.5.1 열거형 사용
  __13.5.2 정수형 및 문자열을 타입 코드로 사용
  __13.5.3 코드에 매직 넘버 넣기
  __13.5.4 코드에 주석 넣기
  __13.5.5 코드에 공백 넣기
  __13.5.6 이름을 기준으로 항목을 그룹화하기
  __13.5.7 이름에 컨텍스트 추가하기
  __13.5.8 긴 메서드 만들기
  __13.5.9 메서드에 많은 매개변수 넘기기
  __13.5.10 getter와 setter 사용하기
  요약
  
  ▣ 14장: 마무리
  14.1 이 책의 여정을 돌아보며
  __14.1.1 소개: 동기
  __14.1.2 1부: 구체화하기
  __14.1.3 2부: 지평 넓히기
  14.2 기본 철학 탐구
  __14.2.1 항상 더 작은 단계 찾기
  __14.2.2 기본 구조 찾기
  __14.2.3 협업을 위한 규칙 사용
  __14.2.4 개인보다 팀을 우선시하기
  __14.2.5 완전성보다 단순성 우선하기
  __14.2.6 객체 또는 고차함수 사용하기
  14.3 이후 여정
  __14.3.1 마이크로 아키텍처를 향한 여정
  __14.3.2 매크로 아키텍처를 향한 여정
  __14.3.3 소프트웨어 품질을 향한 여정
  요약
  
  ▣ 부록A: 실습을 위한 도구 설치
  Node.js
  타입스크립트
  비주얼 스튜디오 코드
  Git
  타입스크립트 프로젝트 설정
  타입스크립트 프로젝트 빌드
  레벨 수정 방법

기본정보

ISBN	9791158393915
발행(출시)일자	2023년 01월 19일
쪽수	392쪽
크기	190 * 242 * 20 mm / 887 g
총권수	1권
시리즈명	위키북스 IT Leaders 시리즈
원서(번역서)명/저자명	Five Lines of Code/Christian Clausen

Klover 리뷰 (12)

[ih****]

책 내용은 정말 좋습니다 다만 번역이 너무 파파고 번역투라서 집중이 잘 안되네요

[qa******]

좋은 코드를 작성하는데 도움이됩니다

[ba******]

막상 5줄로 목표를 정하고 나면 또 그에 맞춰서 되네요.

[yy*****]

책 자체는 정말 훌륭하고 예제가 타입스크립트로 작성되었지만 자바 개발자가 읽기에도 전혀 문제가 없습니다.
스터디 아니었으면 번역 때문에 완독 못했을 책.

[le********]

이 책을 추천하지 않습니다
번역이 불편하게 되어있어서 읽으면서 몇 번이나 화가 치밀어 올랐습니다
꾹 참고 계속 읽고 있는데 와 너무 화가 나네요
책 리뷰도 한번도 올린 적이 없는데 해도해도 너무해서 올립니다
번역 좀 제대로 좀 해주세요 예제도 잘 되어있고 좋은 책인데 진짜 번역이 망치네

[hs****]

도움이 많이 되었습니다

[br********]

내용이 좋습니다.

[ch***]

좋아요. 리펙토링을 공부하는 데 많은 도움이 될 것 같습니다.

[ch***]

리펙토링을 학습하는데 많은 도움이 될 것 같습니다.