주석 부적절한 정보 쓸모 없는 주석 중복된 주석 성의 없는 주석 주석 처리된 코드 환경 여러 단계로 빌드해야 한다 빌드는 간단히 한 단계로 끝나야 한다. 한 명령으로 전체를 체크아웃하여 빌드할 수 있어야 한다. 여러 단계로 테스트해야 한다 모든 단위 테스트는 한 명령으로 돌려야 한다. 그러한 방법이 빠르고 쉽고 명백하다. 함수 너무 많은 인수 출력 인수 플래그 인수 죽은 함수 위 4개는 최대한 피하는 것이 좋다. 자바 긴 import 목록을 피하고 와일드카드를 사용한다 import package.*; 긴 import 목록은 읽기에 부담스럽다. 사용하는 패키지를 간단히 명시하면 충분하다. 상수를 상속하지 않는다 상수를 상속 계층 맨 위에 숨겨 상속하면 안 된다. (끔찍한 광행) static import를 ..
이번 장에서는 지금까지 배운 지저분한 코드를 정리한다. 나쁜 냄새 목록이니 가능한 한 기억하고 있다가 고치는 것이 좋다. 일반 한 소스 파일에 여러 언어를 사용한다 HTML, 자바, 태그 라이브러리 구문, 영어 주석, Javadoc 등을 포함한 JSP 파일은 혼란스럽고 조잡하다. 이상적으로 소스 파일 하나에 언어 하나만 사용하는 방식이 가장 좋다. 당연한 동작을 구현하지 않는다 최소 놀람의 원칙에 의거해 함수나 클래스는 프로그래머가 당연하게 여길 만한 동작과 기능을 제공해야 한다. 경계를 올바르게 처리하지 않는다 직관에 의존하지 말고 모든 경계와 구석진 곳에서 코드를 증명해야 한다. 모든 경계 조건을 찾아내고, 모든 경계 조건을 테스트하는 테스트 케이스를 작성한다. 안전 절차 무시 컴파일러 경고 일부나 ..
첫째, 돌려보자 테스트 케이스를 훑어보면 모든 경우를 점검하지 않는다는 것을 알 수 있다. 코드 커버리지 분석 도구를 이용하여 단위 테스트가 실행하는 코드와 실행하지 않는 코드를 조사한다. 클래스를 철저히 이해하고 리팩터링하려면 훨씬 높은 테스트 커버리지가 필요하다. (현재는 50%) 둘째, 고쳐보자 1. 필요없는 주석은 제거 변경 이력은 1960년대에 나온 방식이므로 제거한다. 현재는 소스 코드 제어 도구를 사용한다. 2. Javadoc 주석 한 소스코드에 여러 언어를 사용하는 것은 좋지 않다. 주석 전부를 로 감싼다. 3. 상수 모음 클래스는 enum으로 관리 MonthConstatns 클래스는 달을 정의하는 static final 모음에 불과하므로 enum으로 정의한다. 그 외의 상수 모음으로 쓰이..
JUnit 프레임워크 JUnit은 자바 프레임워크 중에서 가장 유명하다. 오류를 파악할 때 유용한 코드를 제공한다. 테스트 케이스가 모든 행, 모든 if문, 모든 for문을 실행한다. 이것은 모듈이 올바르게 동작한다는 것을 의미한다 ComparsionCompactor 모듈 개선하기 두 문자열을 받아 차이를 반환하는 모듈이다. package junit.framework; public class ComparisonCompactor { private static final String ELLIPSIS = "..."; private static final String DELTA_END = "]"; private static final String DELTA_START = "["; private int fCont..
그저 돌아가는 코드만으로는 부족하다. 나쁜 일정은 다시 짜면 되고, 나쁜 요구사항은 다시 정의하면 된다. 하지만 나쁜 코드는 그대로 썩어간다. 점점 무게가 늘어나 팀의 발목을 잡는다. 물론 나쁜 코드는 고칠 수 있다. 하지만 비용이 엄청나게 많이 든다. 그러므로 코드는 언제나 최대한 깔끔하고 단순하게 정리하자. 절대로 방치하면 안 된다.
클린코드 13장에서는 동시성을 아주 가볍게 다루고 있다. 더 자세한 내용은 뒤쪽 동시성II 또는 관련된 서적을 읽는 게 좋을 것 같다. 객체는 처리의 추상화다. 스레드는 일정의 추상화다. - 제임스 O. 코플리엔 동시성이 필요한 이유 동시성은 결합을 없애는 전략이다. 무엇과 언제를 분리하는 전략이다. 응답 시간과 작업 처리량 개선이라는 요구사항으로 인해 직접적인 동시성 구현이 불가피하다. 하지만 동시성은 다소 부하를 유발한다. 동시성은 복잡하다. 일반적으로 동시성 버그는 재현하기 어렵다. 일회성 문제로 여겨 무시하기 쉽다. 동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다. 동시성 방어 원칙 동시성 코드는 다른 코드와 분리하라 자료 범위를 제한하라 (코드 내 임계영역을 synchronized ..
창발적 설계로 깔끔한 코드를 구현하자 모든 테스트를 실행한다. 리팩터링 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 1. 모든 테스트를 실행하라 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. 테스트가 불가능한 시스템은 검증도 불가능하다. 검증이 불가능한 시스템은 절대 출시하면 안 된다. 즉, 테스트 케이스를 작성하면 설계 품질이 높아진다. 2. 리팩터링 코드를 정리하면서 시스템이 깨질까 걱정팔 필요가 없다. 테스트 케이스가 있기 때문이다. 코드를 점진적으로 고쳐나간다. 응집도를 높이고, 결합도를 낮추고, 관심사를 분리하고, 함수와 클래스 크기를 줄이는 등 다양한 기법을 동원한다. 3. 중복을 없애라 중복은 추가 작업, 추가 위험, 불필요한 복잡도를 뜻한다. 공..
"복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다." - Ray Ozzie, 마이크로포스트 최고 기술 책임자 시스템 제작과 시스템 사용을 분리하라 소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 '연결'하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다. 1. Main 분리 생성과 관련된 코드응 모두 main이나 main이 호출하는 모듈로 옮긴다. 나머지 시스템은 모두 객체로 생성되었고, 모든 의존성이 연결되도록 한다. 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모르게 된다. 2. 팩토리 객체가 생성되는 시점을 애플리케이션이 결정할 때는 팩토리를 사용한다. 이런 경우 ABSTRACT FACTORY ..
