장바구니 담기 close

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

유지보수 가능한 코딩의 기술 자바편

유지보수 가능한 코딩의 기술 자바편

  • 주스트 뷔서 , 파스칼 반 에크, 롭 반 더 리크, 실번 리갈, 히시 위즌홀즈
  • |
  • 길벗
  • |
  • 2016-12-22 출간
  • |
  • 212페이지
  • |
  • 223*152 mm
  • |
  • ISBN 9791160500783
★★★★★ 평점(10/10) | 리뷰(1)
판매가

18,000원

즉시할인가

16,200

배송비

무료배송

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

수량
+ -
총주문금액
16,200

이 상품은 품절된 상품입니다

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

목차

1장 들어가며
__1.1 유지보수성이란?
____1.1.1 소프트웨어 유지보수의 4대 유형
__1.2 유지보수의 중요성
____1.2.1 유지보수는 비즈니스에 지대한 영향을 끼친다
____1.2.2 유지보수는 다른 품질 특성을 가능하게 한다
__1.3 유지보수 3대 원칙
____1.3.1 원리 1: 보통 단순한 가이드라인을 지키기만 해도 유지보수성은 나아진다
____1.3.2 원리 2: 유지보수성은 나중으로 미룰 문제가 아니라 하나씩 실천하는 자세가 중요하다
____1.3.3 원리 3: 지키지 않으면 다른 가이드라인들보다 결과가 더 안 좋은 가이드라인이 있다
__1.4 유지보수성에 관한 오해
____1.4.1 프로그래밍 언어에 따라 유지보수성이 달라진다
____1.4.2 오해: 유지보수성은 업계마다 다르다
____1.4.3 오해: 유지보수성은 곧 버그가 없는 상태나 마찬가지다
____1.4.4 오해: 유지보수성은 모 아니면 도나 마찬가지다
__1.5 유지보수성 판정
__1.6 유지보수성 가이드라인 미리보기

2장 코드 단위를 짧게 하라
__2.1 필요성
____2.1.1 짧은 단위는 테스트하기 쉽다
____2.1.2 짧은 단위는 분석하기 쉽다
____2.1.3 짧은 단위가 재사용하기 쉽다
__2.2 적용 가이드
____2.2.1 새 단위를 작성할 경우
____2.2.2 단위에 새 기능을 넣어 확장할 경우
____2.2.3 리팩터링 기법으로 가이드라인을 적용
__2.3 일반적인 반대 의견
____2.3.1 단위를 많이 두면 성능이 떨어진다
____2.3.2 코드를 펼치면 더 읽기 어렵다
____2.3.3 가이드라인대로 하면 코드 형식이 무너진다
____2.3.4 도저히 단위를 나눌 수 없다
____2.3.5 단위를 나눈다고 별반 나아질 건 없다
__2.4 참고

3장 코드 단위는 간단하게 짜라
__3.1 필요성
____3.1.1 간단한 단위는 수정하기 쉽다
____3.1.2 간단한 단위는 테스트하기 쉽다
__3.2 적용 가이드
____3.2.1 조건문 체인 다루기
____3.2.2 중첩 다루기
__3.3 일반적인 반대 의견
____3.3.1 높은 복잡도는 불가피하다
____3.3.2 메서드를 나눈다고 복잡도가 줄어들지 않는다
__3.4 참고

4장 코드는 한 번만 작성하라
____4.0.1 복사 유형
__4.1 필요성
____4.1.1 복사한 코드는 분석하기 어렵다
____4.1.2 복사한 코드는 고치기 어렵다
__4.2 적용 가이드
____4.2.1 ‘상위 클래스 추출’ 리팩터링 기법
__4.3 일반적인 반대 의견
____4.3.1 다른 코드베이스의 코드를 복사하는 건 괜찮다
____4.3.2 복사한 뒤 조금씩 고쳐 쓰는 건 어쩔 수 없다
____4.3.3 이 코드는 절대, 절대로 바뀔 일이 없다
____4.3.4 전체 파일 복사는 백업으로 봐야 하지 않나요?
____4.3.5 단위 테스트가 커버해준다
____4.3.6 문자열 리터럴 복사는 어쩔 수 없고 해롭지 않다
__4.4 참고

5장 단위 인터페이스를 작게 하라
__5.1 필요성
____5.1.1 작은 인터페이스가 이해하고 재사용하기 쉽다
____5.1.2 인터페이스가 작아야 메서드를 수정하기 쉽다
__5.2 적용 가이드
__5.3 일반적인 반대 의견
____5.3.1 인터페이스가 큰 파라미터 객체
____5.3.2 큰 인터페이스를 리팩터링한다고 나아질 게 없다
____5.3.3 원래 프레임워크, 라이브러리 인터페이스의 파라미터가 많다
__5.4 참고

6장 관심사를 모듈로 분리하라
__6.1 필요성
____6.1.1 작고 느슨하게 결합된 모듈 덕분에 개발자들이 코드베이스를 나누어 독립적으로 작업할 수 있다
____6.1.2 작고 느슨하게 결합된 모듈 덕분에 코드베이스를 따라가기 쉽다
____6.1.3 작고 느슨하게 결합된 모듈 덕분에 새로 입사한 개발자들의 금기 영역을 없앨 수 있다
__6.2 적용 가이드
____6.2.1 클래스를 나누어 관심사를 분리한다
____6.2.2 특정 구현부는 인터페이스 안에 숨긴다
____6.2.3 커스텀 코드를 서드파티 라이브러리/프레임워크로 대체한다
__6.3 일반적인 반대 의견
____6.3.1 느슨한 결합은 코드 재사용과 상충된다
____6.3.2 자바 인터페이스가 느슨한 결합에 쓰라고 만든 건 아니다
____6.3.3 유틸리티 클래스를 자주 끌어 쓰는 건 어쩔 수 없다
____6.3.4 느슨하게 결합한다고 유지보수성이 나아지지 않는다

7장 아키텍처 컴포넌트를 느슨하게 결합하라
__7.1 필요성
____7.1.1 컴포넌트 의존성이 낮아야 분리해서 유지보수할 수 있다
____7.1.2 컴포넌트 의존성이 낮아야 유지보수 책임을 분담할 수 있다
____7.1.3 컴포넌트 의존성이 낮아야 테스트하기 쉽다
__7.2 적용 가이드
____7.2.1 추상 팩토리 디자인 패턴
__7.3 일반적인 반대 의견
____7.3.1 컴포넌트가 하도 얽혀 있어서 의존성을 바로잡을 길이 없다
____7.3.2 고칠 시간이 없다
____7.3.3 스루풋 자체가 요건이다
__7.4 참고

8장 아키텍처 컴포넌트의 균형을 잡아라
__8.1 필요성
____8.1.1 균형이 잘 잡힌 컴포넌트 덕분에 코드를 찾고 분석하기 쉽다
____8.1.2 균형이 잘 잡힌 컴포넌트 덕분에 유지보수 효과를 분리할 수 있다
____8.1.3 균형이 잘 잡힌 컴포넌트 덕분에 유지보수 책임을 분담할 수 있다
__8.2 적용 가이드
____8.2.1 컴포넌트로 기능을 묶는 기준이 되는 올바른 개념 수준
____8.2.2 시스템 도메인을 명확히 하고 일관되게 적용하라
__8.3 일반적인 반대 의견
____8.3.1 컴포넌트 균형은 좀 안 맞아도 괜찮다
____8.3.2 너무 꼬여 있어서 컴포넌트 균형이 깨진 상태다
__8.4 참고

9장 코드베이스를 작게 하라
__9.1 필요성
____9.1.1 대규모 코드베이스 구축을 목표로 시작한 프로젝트는 실패할 가능성이 높다
____9.1.2 대규모 코드베이스는 유지보수하기 힘들다
____9.1.3 대규모 시스템은 결함 밀도가 높다
__9.2 적용 가이드
____9.2.1 기능적 조치
____9.2.2 기술적 조치
__9.3 일반적인 반대 의견
____9.3.1 코드베이스 크기를 줄이면 생산성이 떨어지는 것으로 나타난다
____9.3.2 프로그래밍 언어 때문에 코드베이스 크기를 줄일 수가 없다
____9.3.3 시스템이 복잡해서 어쩔 수 없이 코드 복사를 하고 있다
____9.3.4 플랫폼 아키텍처 상 코드베이스를 분리할 수 없다
____9.3.5 코드베이스를 나누면 코드가 중복된다
____9.3.6 결합도가 너무 높아 코드베이스를 나누는 건 불가능하다

10장 테스트를 자동화하라
__10.1 필요성
____10.1.1 테스트를 자동화하면 반복 테스트가 가능하다
____10.1.2 테스트를 자동화하면 효율적으로 개발할 수 있다
____10.1.3 테스트를 자동화하면 예측 가능한 코드를 만든다
____10.1.4 테스트할 코드를 문서화한다
____10.1.5 테스트를 작성하면 더 나은 코드를 짤 수 있다
__10.2 적용 가이드
____10.2.1 제이유닛 테스트 길들이기
____10.2.2 단위 테스트를 올바르게 작성하기 위한 일반 원칙
____10.2.3 테스트가 충분한지 여부를 판단하기 위한 커버리지 측정
__10.3 일반적인 반대 의견
____10.3.1 그래도 수동 테스트는 필요하다
____10.3.2 단위 테스트를 작성하지 못하게 한다
____10.3.3 커버리지가 낮은 상태에서 단위 테스트에 투자할 이유가 있을까?
__10.4 기타

11장 클린 코드를 작성하라
__11.1 흔적을 남기지 말라
__11.2 적용 가이드
____11.2.1 규칙 1: 단위 수준의 코드 악취를 남기지 말라
____11.2.2 규칙 2: 나쁜 주석을 남기지 말라
____11.2.3 규칙 3: 주석 안에 코드를 남기지 말라
____11.2.4 규칙 4: 죽은 코드를 남기지 말라
____11.2.5 규칙 5: 긴 식별자 이름을 남기지 말라
____11.2.6 규칙 6: 매직 상수를 남기지 말라 193
____11.2.7 규칙 7: 제대로 처리 안 한 예외를 남기지 말라
__11.3 일반적인 반대 의견
____11.3.1 주석은 곧 문서화다
____11.3.2 예외 처리를 하면 코드가 늘어난다
____11.3.3 코딩 가이드라인이 이것뿐인가?

12장 다음 단계
__12.1 가이드라인을 실천하라
__12.2 고수준(컴포넌트) 가이드라인보다 저수준(단위) 가이드라인이 우선한다
__12.3 커밋 하나하나가 중요함을 기억하라
__12.4 개발 프로세스에 관한 베스트 프랙티스는 다음 책에서

부록 A SIG의 유지보수성 판정법  

도서소개

누가 코드를 이따위로 짠 거야? 나 일 못 해! 

 

다른 사람의 코드를 작업하다가 좌절한 경험이 있는가? 서비스가 성장하면 혼자 작업하던 코드도 여러 명이 작업해야 하고, 코드 규모가 커질수록 쉽게 고칠 수 없는 코드로 변하고 만다. 새로운 기능을 개발하는 시간보다 기존 코드를 읽고 수정하는 시간이 더 오래 걸리고, 코드 수정 비용이 급격하게 증가하게 된다. 프로젝트 마감? 마감은 늘어나라고 있는 거 아닌가? 

 

이 책에서는 소프트웨어 개선 그룹(SIG)의 컨설턴트들이 자바로 작성된 JPacman 오픈 소스를 예로 들어 유지보수 가능한 소프트웨어를 만드는 10가지 원칙을 설명한다. 특정 기술에만 해당하는 지표나 변별력이 없는 지표는 제외했다. 팀에서 지키면 최소한 읽을 수 있고, 유지보수가 가능한 코드를 작성할 수 있는, 현실적인 지침을 제시한다. 개발팀의 서가에 이 책은 반드시 꽂혀 있어야 한다.



 

교환 및 환불안내

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