추가 적립 안내

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

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

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

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의 유지보수성 판정법

컴퓨터가 이해할 수 있는 코드는 바보라도 짤 수 있다.
유능한 프로그래머는 인간이 이해할 수 있는 코드를 짠다. _마틴 파울러

악취 퍼레이드의 하이라이트는 중복 코드다. _켄트 벡, 마틴 파울러

소프트웨어 디자인을 구축하는 방법은 두 가지다. 아주 단순하게 만들어 확실하게 결함이 없게 하는 것과 아주 복잡하게 만들어서 눈에 띄는 결함이 보이지 않게 하는 것이다. _C.A.R. 호어

스스로 프로라고 자부한다면 클린 코드는 필수다. _로버트 C. 마틴