자바코딩, 이럴 땐 이렇게(위키북스 프로그래밍 & 프랙티스 시리즈 7)

이제 올바로 코딩하자!



소프트웨어의 소스코드 규모가 방대해지고 복잡해질수록 그만큼 코드에 결함이 발생할 확률도 기하급수적으로 상승한다. 단순한 실수로 치명적인 결함을 발생시키는 소스코드, 혼란스럽고 복잡한 스파게티 코드, 그리고 소프트웨어의 성능과 품질을 떨어뜨리는 코드가 소프트웨어의 어느 한 구석에 숨어있을 가능성은 언제나 있지만, 소프트웨어가 고도화된 만큼 이 같은 결함을 찾아내기는 굉장히 어렵다. 이 책에서는 이런 결함들을 정적 분석 도구인 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와 같은 예외 처리 구조는 예외 처리를 더욱 복잡하게 만든다

배병선 저자 배병선은 시스템 분석을 전공으로 Queensland University of Technology를 졸업했으며, 사이트 정보 파악 방법에 대한 기술 특허를 고안했고, ISO TC211 국제 주소 표준화 구조 분석 연구원으로 참여했다. 또한 다양한 언어와 환경에서 프로젝트를 수행한 경험을 바탕으로 정부 및 대기업의 자바 기반 프로젝트에서 시스템 분석 설계 개발자로 활동하고 있다. 현재 많은 자바 프로젝트에서 비슷한 실수들이 치명적인 결함을 일으키는 것에 관심을 두고 정적 분석 도구인 PMD를 활용해 소프트웨어의 문제점을 진단하고 코드상의 실수를 방지해 소프트웨어의 품질을 향상시키는 데 노력하고 있다.