목차 일부

1장 들어가며 = 27
  1.1 유지보수성이란? = 28
    1.1.1 소프트웨어 유지보수의 4대 유형 = 29
  1.2 유지보수의 중요성 = 30
    1.2.1 유지보수는 비즈니스에 지대한 영향을 끼친다 = 30
    1.2.2 유지보수는 다른 품질 특성을 가능하게 한다 = 31
  1.3 유지보수 3대 원칙 = 32
    1....

더보기

목차 전체

1장 들어가며 = 27
  1.1 유지보수성이란? = 28
    1.1.1 소프트웨어 유지보수의 4대 유형 = 29
  1.2 유지보수의 중요성 = 30
    1.2.1 유지보수는 비즈니스에 지대한 영향을 끼친다 = 30
    1.2.2 유지보수는 다른 품질 특성을 가능하게 한다 = 31
  1.3 유지보수 3대 원칙 = 32
    1.3.1 원리 1 : 보통 단순한 가이드라인을 지키기만 해도 유지보수성은 나아진다 = 33
    1.3.2 원리 2 : 유지보수성은 나중으로 미룰 문제가 아니라 하나씩 실천하는 자세가 중요하다 = 33
    1.3.3 원리 3 : 지키지 않으면 다른 가이드라인들보다 결과가 더 안 좋은 가이드라인이 있다 = 34
  1.4 유지보수성에 관한 오해 = 34
    1.4.1 프로그래밍 언어에 따라 유지보수성이 달라진다 = 35
    1.4.2 오해 : 유지보수성은 업계마다 다르다 = 35
    1.4.3 오해 : 유지보수성은 곧 버그가 없는 상태나 마찬가지다 = 36
    1.4.4 오해 : 유지보수성은 모 아니면 도나 마찬가지다 = 36
  1.5 유지보수성 판정 = 37
  1.6 유지보수성 가이드라인 미리보기 = 39
2장 코드 단위를 짧게 하라 = 41
  2.1 필요성 = 44
    2.1.1 짧은 단위는 테스트하기 쉽다 = 44
    2.1.2 짧은 단위는 분석하기 쉽다 = 45
    2.1.3 짧은 단위가 재사용하기 쉽다 = 45
  2.2 적용 가이드 = 46
    2.2.1 새 단위를 작성할 경우 = 46
    2.2.2 단위에 새 기능을 넣어 확장할 경우 = 48
    2.2.3 리팩터링 기법으로 가이드라인을 적용 = 49
      2.2.3.1 리팩터링 기법 : 메서드 추출 = 49
      2.2.3.2 리팩터링 기법 : 메서드를 메서드 객체로 대체 = 51
  2.3 일반적인 반대 의견 = 55
    2.3.1 단위를 많이 두면 성능이 떨어진다 = 55
    2.3.2 코드를 펼치면 더 읽기 어렵다 = 56
    2.3.3 가이드라인대로 하면 코드 형식이 무너진다 = 56
    2.3.4 도저히 단위를 나눌 수 없다 = 57
    2.3.5 단위를 나눈다고 별반 나아질 건 없다 = 59
  2.4 참고 = 60
3장 코드 단위는 간단하게 짜라 = 63
  3.1 필요성 = 70
    3.1.1 간단한 단위는 수정하기 쉽다 = 70
    3.1.2 간단한 단위는 테스트하기 쉽다 = 71
  3.2 적용 가이드 = 71
    3.2.1 조건문 체인 다루기 = 72
    3.2.2 중첩 다루기 = 74
  3.3 일반적인 반대 의견 = 77
    3.3.1 높은 복잡도는 불가피하다 = 77
    3.3.2 메서드를 나눈다고 복잡도가 줄어들지 않는다 = 78
  3.4 참고 = 78
4장 코드는 한 번만 작성하라 = 81
    4.0.1 복사 유형 = 84
  4.1 필요성 = 86
    4.1.1 복사한 코드는 분석하기 어렵다 = 86
    4.1.2 복사한 코드는 고치기 어렵다 = 87
  4.2 적용 가이드 = 87
    4.2.1 ''상위 클래스 추출'' 리팩터링 기법 = 90
  4.3 일반적인 반대 의견 = 93
    4.3.1 다른 코드베이스의 코드를 복사하는 건 괜찮다 = 93
    4.3.2 복사한 뒤 조금씩 고쳐 쓰는 건 어쩔 수 없다 = 94
    4.3.3 이 코드는 절대, 절대로 바뀔 일이 없다 = 95
    4.3.4 전체 파일 복사는 백업으로 봐야 하지 않나요? = 95
    4.3.5 단위 테스트가 커버해준다 = 96
    4.3.6 문자열 리터럴 복사는 어쩔 수 없고 해롭지 않다 = 96
  4.4 참고 = 97
5장 단위 인터페이스를 작게 하라 = 99
  5.1 필요성 = 103
    5.1.1 작은 인터페이스가 이해하고 재사용하기 쉽다 = 103
    5.1.2 인터페이스가 작아야 메서드를 수정하기 쉽다 = 103
  5.2 적용 가이드 = 104
  5.3 일반적인 반대 의견 = 110
    5.3.1 인터페이스가 큰 파라미터 객체 = 110
    5.3.2 큰 인터페이스를 리팩터링한다고 나아질 게 없다 = 110
    5.3.3 원래 프레임워크, 라이브러리 인터페이스의 파라미터가 많다 = 111
  5.4 참고 = 112
6장 관심사를 모듈로 분리하라 = 113
  6.1 필요성 = 119
    6.1.1 작고 느슨하게 결합된 모듈 덕분에 개발자들이 코드베이스를 나누어 독립적으로 작업할 수 있다 = 119
    6.1.2 작고 느슨하게 결합된 모듈 덕분에 코드베이스를 따라가기 쉽다 = 119
    6.1.3 작고 느슨하게 결합된 모듈 덕분에 새로 입사한 개발자들의 금기 영역을 없앨 수 있다 = 120
  6.2 적용 가이드 = 120
    6.2.1 클래스를 나누어 관심사를 분리한다 = 121
    6.2.2 특정 구현부는 인터페이스 안에 숨긴다 = 122
    6.2.3 커스텀 코드를 서드파티 라이브러리／프레임워크로 대체한다 = 125
  6.3 일반적인 반대 의견 = 125
    6.3.1 느슨한 결합은 코드 재사용과 상충된다 = 125
    6.3.2 자바 인터페이스가 느슨한 결합에 쓰라고 만든 건 아니다 = 126
    6.3.3 유틸리티 클래스를 자주 끌어 쓰는 건 어쩔 수 없다 = 126
    6.3.4 느슨하게 결합한다고 유지보수성이 나아지지 않는다 = 127
7장 아키텍처 컴포넌트를 느슨하게 결합하라 = 129
  7.1 필요성 = 131
    7.1.1 컴포넌트 의존성이 낮아야 분리해서 유지보수할 수 있다 = 134
    7.1.2 컴포넌트 의존성이 낮아야 유지보수 책임을 분담할 수 있다 = 134
    7.1.3 컴포넌트 의존성이 낮아야 테스트하기 쉽다 = 135
  7.2 적용 가이드 = 135
    7.2.1 추상 팩토리 디자인 패턴 = 136
  7.3 일반적인 반대 의견 = 139
    7.3.1 컴포넌트가 하도 얽혀 있어서 의존성을 바로잡을 길이 없다 = 139
    7.3.2 고칠 시간이 없다 = 139
    7.3.3 스루풋 자체가 요건이다 = 140
  7.4 참고 = 141
8장 아키텍처 컴포넌트의 균형을 잡아라 = 143
  8.1 필요성 = 144
    8.1.1 균형이 잘 잡힌 컴포넌트 덕분에 코드를 찾고 분석하기 쉽 다 = 145
    8.1.2 균형이 잘 잡힌 컴포넌트 덕분에 유지보수 효과를 분리할 수 있다 = 146
    8.1.3 균형이 잘 잡힌 컴포넌트 덕분에 유지보수 책임을 분담할 수 있다 = 147
  8.2 적용 가이드 = 147
    8.2.1 컴포넌트로 기능을 묶는 기준이 되는 올바른 개념 수준 = 148
    8.2.2 시스템 도메인을 명확히 하고 일관되게 적용하라 = 148
  8.3 일반적인 반대 의견 = 149
    8.3.1 컴포넌트 균형은 좀 안 맞아도 괜찮다 = 149
    8.3.2 너무 꼬여 있어서 컴포넌트 균형이 깨진 상태다 = 150
  8.4 참고 = 150
9장 코드베이스를 작게 하라 = 153
  9.1 필요성 = 154
    9.1.1 대규모 코드베이스 구축을 목표로 시작한 프로젝트는 실패할 가능성이 높다 = 155
    9.1.2 대규모 코드베이스는 유지보수하기 힘들다 = 156
    9.1.3 대규모 시스템은 결함 밀도가 높다 = 156
  9.2 적용 가이드 = 157
    9.2.1 기능적 조치 = 158
    9.2.2 기술적 조치 = 158
  9.3 일반적인 반대 의견 = 161
    9.3.1 코드베이스 크기를 줄이면 생산성이 떨어지는 것으로 나타난다 = 161
    9.3.2 프로그래밍 언어 때문에 코드베이스 크기를 줄일 수가 없다 = 162
    9.3.3 시스템이 복잡해서 어쩔 수 없이 코드 복사를 하고 있다 = 162
    9.3.4 플랫폼 아키텍처 상 코드베이스를 분리할 수 없다 = 163
    9.3.5 코드베이스를 나누면 코드가 중복된다 = 163
    9.3.6 결합도가 너무 높아 코드베이스를 나누는 건 불가능하다 = 164
10장 테스트를 자동화하라 = 165
  10.1 필요성 = 168
    10.1.1 테스트를 자동화하면 반복 테스트가 가능하다 = 168
    10.1.2 테스트를 자동화하면 효율적으로 개발할 수 있다 = 168
    10.1.3 테스트를 자동화하면 예측 가능한 코드를 만든다 = 169
    10.1.4 테스트할 코드를 문서화한다 = 169
    10.1.5 테스트를 작성하면 더 나은 코드를 짤 수 있다 = 170
  10.2 적용 가이드 = 170
    10.2.1 제이유닛 테스트 길들이기 = 172
    10.2.2 단위 테스트를 올바르게 작성하기 위한 일반 원칙 = 175
    10.2.3 테스트가 충분한지 여부를 판단하기 위한 커버리지 측정 = 180
  10.3 일반적인 반대 의견 = 182
    10.3.1 그래도 수동 테스트는 필요하다 = 182
    10.3.2 단위 테스트를 작성하지 못하게 한다 = 183
    10.3.3 커버리지가 낮은 상태에서 단위 테스트에 투자할 이유가 있을까? = 183
  10.4 기타 = 184
11장 클린 코드를 작성하라 = 185
  11.1 흔적을 남기지 말라 = 186
  11.2 적용 가이드 = 186
    11.2.1 규칙 1 : 단위 수준의 코드 악취를 남기지 말라 = 187
    11.2.2 규칙 2 : 나쁜 주석을 남기지 말라 = 188
    11.2.3 규칙 3 : 주석 안에 코드를 남기지 말라 = 190
    11.2.4 규칙 4 : 죽은 코드를 남기지 말라 = 191
      11.2.4.1 닿을 수 없는 메서드 코드 = 191
      11.2.4.2 사용하지 않는 프라이빗 메서드 = 192
      11.2.4.3 주석 안에 있는 코드 = 192
    11.2.5 규칙 5 : 긴 식별자 이름을 남기지 말라 = 192
    11.2.6 규칙 6 : 매직 상수를 남기지 말라 = 193
    11.2.7 규칙 7 : 제대로 처리 안 한 예외를 남기지 말라 = 194
  11.3 일반적인 반대 의견 = 195
    11.3.1 주석은 곧 문서화다 = 195
    11.3.2 예외 처리를 하면 코드가 늘어난다 = 196
    11.3.3 코딩 가이드라인이 이것뿐인가? = 196
12장 다음 단계 = 197
  12.1 가이드라인을 실천하라 = 198
  12.2 고수준(컴포넌트) 가이드라인보다 저수준(단위) 가이드라인이 우선한다 = 198
  12.3 커밋 하나하나가 중요함을 기억하라 = 199
  12.4 개발 프로세스에 관한 베스트 프랙티스는 다음 책에서 = 200
부록 A : SIG의 유지보수성 판정법 = 201
찾아보기 = 205

더보기 닫기