목차
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: 주석 안에 코드를 남기지