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

▣ 작가 소개

주스트 뷔서
SIG 연구소장으로 소프트웨어를 평가하고 마스터하기 위해 SIG가 구축한 방법 및 도구의 기반 기술을 담당한다.

파스칼 반 에크
SIG 소프트웨어 품질 담당 컨설턴트이며 IT 보안, 소프트웨어 지표 등의 분야에 80편이 넘는 논문을 썼다.

롭 반 더 리크
SIG 소프트웨어 품질 담당 컨설턴트로 SIG 소프트웨어 분석 툴의 개발/유지보수를 담당하는 내부 팀을 이끌고 있다.

실번 리갈
SIG 소프트웨어 품질 컨설턴트로 소프트웨어 디자인 및 개발 프로세스 개선에 우선순위를 부여하고 보안을 향상하는 일을 한다.

히시 위즌홀즈
공공 분야 담당 소프트웨어 품질 컨설턴트로 고객사 프로젝트가 잘 관리될 수 있게 개발 프로세스 전반에 대해 컨설팅한다.

역자 : 이일웅
10년 넘게 국내와 미국 등지에서 대기업/공공기관 프로젝트를 수행한 웹 개발자이자 두 딸의 사랑을 한 몸에 받고 사는 행복한 딸바보다. 자바 기반의 서버 플랫폼 구축, 데이터 연계 그리고 다양한 자바스크립트 프레임워크를 응용한 프런트엔드 화면 개발을 주로 담당해왔다. 시간이 날 땐 피아노를 연주한다
* 홈페이지 http://www.bullion.pe.kr

▣ 주요 목차

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