추가 적립 안내

소프트웨어의 소스코드 규모가 방대해지고 복잡해질수록 그만큼 코드에 결함이 발생할 확률도 기하급수적으로 상승한다. 단순한 실수로 치명적인 결함을 발생시키는 소스코드, 혼란스럽고 복잡한 스파게티 코드, 그리고 소프트웨어의 성능과 품질을 떨어뜨리는 코드가 소프트웨어의 어느 한 구석에 숨어있을 가능성은 언제나 있지만, 소프트웨어가 고도화된 만큼 이 같은 결함을 찾아내기는 굉장히 어렵다. 이 책에서는 이런 결함들을 정적 분석 도구인 PMD를 활용해 자동으로 진단하고 실제 프로젝트 경험을 바탕으로 올바른 방향으로 수정하는 최적의 방법을 제시한다.

이제 올바로 코딩하자!

소프트웨어의 소스코드 규모가 방대해지고 복잡해질수록 그만큼 코드에 결함이 발생할 확률도 기하급수적으로 상승한다. 단순한 실수로 치명적인 결함을 발생시키는 소스코드, 혼란스럽고 복잡한 스파게티 코드, 그리고 소프트웨어의 성능과 품질을 떨어뜨리는 코드가 소프트웨어의 어느 한 구석에 숨어있을 가능성은 언제나 있지만, 소프트웨어가 고도화된 만큼 이 같은 결함을 찾아내기는 굉장히 어렵다. 이 책에서는 이런 결함들을 정적 분석 도구인 PMD를 활용해 자동으로 진단하고 실제 프로젝트 경험을 바탕으로 올바른 방향으로 수정하는 최적의 방법을 제시한다.

각 장은 결함의 난이도와 발생 빈도를 기준으로 분류된 여러 개의 항목으로 구성돼 있으며, 각 항목에서는 실제 프로젝트 사례를 바탕으로 결함의 원인과 PMD를 통한 분석 방법, 그리고 문제점의 해결책을 실무에 가까운 소스코드와 간결한 설명으로 쉽고 명확하게 설명한다.

★ 이 책에서 다루는 내용 ★

◎ 프로그래밍 일반 규칙
◎ 가독성과 명명 규칙
◎ 괄호 규칙
◎ 올바른 문자열 처리
◎ 올바른 주석 사용법
◎ 패키지 참조
◎ 빈 코드
◎ 코드 길이와 복잡도
◎ 필수 설계 규칙
◎ 객체 간의 결합 규칙
◎ 소스코드 최적화
◎ JUnit 사용 규칙
◎ 예외 처리

망가진 소스코드를 자동으로 진단하기
IDE별 PMD 설치 및 사용

[1부] 기본 프로그래밍 가이드라인

▣ 01장: 프로그래밍 일반 규칙
1.1 뒤죽박죽 증감변수
1.2 연관된 조건문은 하나로 통합한다
1.3 아무것도 하지 않는 if 문은 제거한다
1.4 잘못된 null 조건 비교
1.5 잘못된 위치의 null 비교
1.6 for 문 vs. while 문
1.7 for 문에서는 절대 float을 증감변수로 사용하지 않는다
1.8 반복문 끝에는 분기문을 두지 않는다
1.9 Boolean 객체의 사용법
1.10 BigInteger 객체의 사용법
1.11 BigDecimal의 함정
1.12 8진수 값은 사용하지 않는다
1.13 잘못 하드코딩된 IP는 위험하다
1.14 올바른 toArray 메서드 사용법
1.15 equals와 hashCode 메서드는 언제나 함께 오버라이드한다
1.16 실수하기 쉬운 skip 메서드
1.17 finally 절에서는 return을 사용하지 않는다
1.18 복합 단항 연산은 가독성이 떨어진다
1.19 Boolean 값을 반환하는 코드는 단순하게
1.20 초기화 블록은 생성자와 혼동될 수 있다
1.21 Double.NaN으로 값을 비교하지 않는다

▣ 02장: 가독성과 명명 규칙
2.1 패키지 명명 규칙
2.2 클래스 및 인터페이스 명명 규칙
2.3 추상 클래스 명명 규칙
2.4 메서드 명명 규칙
2.5 사용할 수 없는 메서드명
2.6 변수 명명 규칙
2.7 변수 명명 규칙의 예외 사항
2.8 상수 명명 규칙
2.9 헝가리안 표기법

▣ 03장: 괄호 규칙
3.1 if 문 괄호 규칙
3.2 for와 while 문의 괄호 규칙

▣ 04장: 올바른 문자열 처리
4.1 중복된 문자열은 삭제한다
4.2 올바른 문자열 객체 사용법
4.3 비효율적인 StringBuffer/StringBuilder 사용
4.4 대소문자를 포함한 문자열 비교법
4.5 올바른 StringBuffer/StringBuilder 생성자 사용
4.6 StringBuffer/StringBuilder 사용 시 주의해야 하는 실수
4.7문자열에서 특정 문자 찾기
4.8 빈 문자열 확인
4.9 문자열의 시작 문자를 검사할 때는 startsWith가 아닌 chartAt을 활용하자

▣ 05장: 올바른 주석 사용법

▣ 06장: 패키지 참조
6.1 중복된 참조는 가독성이 떨어진다
6.2 불필요한 참조는 하지 않는다
6.3 너무 많은 정적 참조는 불필요하다

▣ 07장: 빈 코드
7.1 비어있는 예외 처리는 치명적인 결함을 무시한다
7.2 비어있는 finally 블록은 시스템 자원을 낭비할 수 있다
7.3 비어있는 반복문은 불필요한 시스템 자원을 소비한다
7.4 과도한 스레드 동기화는 병목현상을 유발한다

[2부] 설계에 도움이 되는 가이드라인

▣ 08장: 코드 길이와 복잡도
8.1 길고 복잡한 코드는 단순하게
8.2 너무 많은 기능을 한 클래스에 넣지 않는다
8.3 연관성 있는 변수는 하나의 객체로 묶는다
8.4 클래스의 결합도는 낮춰야 한다
8.5 복잡한 메서드는 재앙이다

▣ 09장: 필수 설계 규칙
9.1 복잡한 단계의 if 문은 위험하다
9.2 switch 문에서 break는 필수다
9.3 switch 문의 default 절은 필수다
9.4 복잡한 switch 문과 템플릿 메서드 패턴
9.5 생성자에서는 재정의 가능한 메서드를 호출해서는 안 된다
9.6 캡슐화를 위한 내부 클래스는 오히려 결합도와 응집도를 모두 저해한다
9.7 스레드 동기화는 중복해서 하지 않는다
9.8 static 메서드로만 이뤄진 클래스는 싱글톤 패턴으로 변환한다
9.9 사용한 리소스는 꼭 반환한다
9.10 메서드 단위의 스레드 동기화에 주의한다

▣ 10장: 객체 간의 결합 규칙
10.1 객체를 선언할 때는 클래스가 아닌 인터페이스로 선언한다
10.2 불필요한 클래스 간의 소통을 최소화한다

[3부] 성능 개선을 위한 가이드라인

▣ 11장: 소스코드 최적화
11.1 적절한 컬렉션 선택은 소프트웨어의 성능을 좌우한다
11.2 리스트와 배열 간 빠른 복사 방법
11.3 형변환에 불필요한 메서드 사용
11.4 불변 객체는 객체 관리를 수월하게 만들어준다
11.5 방어복사는 객체를 방어하는 가장 쉬운 방법이다
11.6 인터페이스는 기능의 명세서 역할만을 수행한다
11.7 사용하지 않는 소스코드는 삭제하자
11.8 중복 소스코드 진단
11.9 스레드 그룹은 사용하지 않는다
11.10 Thread의 run 메서드 대신 start 메서드를 사용한다

[4부] 디버깅을 위한 JUnit과 예외 처리

▣ 12장: JUnit 사용 규칙
12.1 JUnit 3에서는 오타가 가장 큰 오류의 주범이다
12.2 단정 메서드의 실패 메시지는 디버깅에 효율적이다
12.3 assertTrue가 JUnit의 유일한 단정 메서드는 아니다
12.4 너무 긴 테스트 시나리오는 단위 테스트의 목적을 불분명하게 만든다

▣ 13장: 예외 처리
13.1 예외 정보를 무시하는 것은 소프트웨어 유지보수를 포기하는 것과 같다
13.2 통합된 예외 처리가 아닌 각 예외의 유형에 맞게 처리해야 한다
13.3 GOTO와 같은 예외 처리 구조는 예외 처리를 더욱 복잡하게 만든다

자바는 분명 잘 만들어진 언어이고 그러한 이유로 수많은 오픈소스 프로젝트와 상용 소프트웨어에서 활용되고 있으며, 수많은 관련 라이브러리와 정보가 매일 매일 쏟아져 나오고 있다. 하지만 안타깝게도 이런 과도한 활용도와 정보로 인해 많은 개발자들이 자바를 매우 쉽게 생각하고 올바른 사용법보다 단순히 당장 필요한 라이브러리를 사용하기 위한 기본 정보와 인터넷 상의 잘못된 정보를 아무런 검증 없이 프로젝트에 활용하고 있다. 특히 일부 프로젝트에서는 자바가 C와 다르게 메모리를 VM이 자동으로 관리해준다는 점을 맹신함으로써 메모리 관리 자체를 포기한 소스코드 또한 빈번히 발견된다. 결국 아무리 좋은 도구가 있더라도 제대로 사용할 줄 모르면 무용지물인 것처럼 자바라는 언어의 특성을 정확하게 인지하지 못하고 단편적인 정보만을 활용해 당면한 문제를 해결하는 데만 급급하기 때문에 자바를 최대한 활용하는 모습을 보기 어렵다.

또한 그동안 다양한 프로젝트를 수행하면서 경험한 바는 의외로 잘못 작성된 코드가 전체 코드의 구석구석에 숨어 있어도 이런 문제점을 발견하기가 매우 곤란하다는 점이다. 코드 사이사이에 숨은 잘못된 코드를 리뷰와 검수를 통해 찾기란 여간 곤혹스러운 일이 아니다.

정적 분석 도구인 PMD는 이런 문제점을 해결할 수 있는 유용한 해결책 중 하나다. PMD는 작성된 소스코드를 자동으로 분석해 잘못된 코드의 잠재적인 문제점을 유형별로 진단하고 간략한 설명을 첨언함으로써 코드의 품질을 향상시키는 데 매우 유용하다. 물론 PMD가 완벽한 것은 아니다. PMD의 진단 항목 가운데 아직까지 논란의 대상이 되고 있는 항목이나 상황에 따라 불필요한 항목도 있으며, 아직 진단하지 못하는 문제점들도 있다. 하지만 PMD가 판올림을 거듭하면서 각종 필수항목과 유용한 진단 항목들이 포함되어 자바 프로그래밍을 위한 최소한의 가이드라인 역할은 수행할 수 있다.

이 책은 실제 사례를 기준으로 빈번히 발생하는 잘못된 코드를 PMD로 진단하고 발견된 문제점을 올바르게 수정하는 방법을 제시하기 위한 명확한 설명과 예제로 구성돼 있다. 특히 예제 코드는 가급적 실제 코드를 활용했으며, 그렇지 못한 경우에는 최대한 실제로 일어날 수 있을 법한 예를 들려고 노력했다.

완벽한 프로그래밍이란 불가능하지만 이 책을 통해 자바라는 언어를 좀 더 이해하고 효과적으로 활용해 잘못된 코드로 발생하는 개발의 괴로움을 더는 데 도움 되기를 바란다.

- 저자 서문 중에서