01장. 깨끗한 코드 02장. 의미 있는 이름 03장. 함수 04장. 주석 05장. 형식 맞추기 06장. 객체와 자료 구조 07장. 오류 처리 08장. 경계 09장. 단위 테스트 10장. 클래스 11장. 시스템 12장. 창발성 13장. 동시성 14장. 점진적인 개선 15장. JUnit 들여다보기 16장. SerialDate 리팩터링 17장. 냄새와 휴리스틱
주석 코드를 읽으면서 나쁜 냄새와 기교 및 휴리스틱를 정리해보자. 1) 부적절한 정보 주석은 코드와 설계에 기술적인 설명을 부연하는 수단이므로 일반적으로 작성자, 최종 수정일, SPR 번호 등과 같은 메타 정보만 넣는다. 2) 쓸모 없는 주석 오래된 주석, 엉뚱한 주석, 잘못된 주석은 더 이상 쓸모가 없다. 쓸모 없어진 주석은 재빨리 삭제하는 편이 가장 좋다. 3) 중복된 주석 코드만으로 충분한데 구구절절 설명하는 주석인 중복된 주석은 필요 없다. 주석은 코드만으로 다하지 못하는 설명을 부언한다. 4) 성의 없는 주석 주석을 달 참이라면 시간을 들여 최대한 멋지게 작성한다. 단어를 신중하게 선택하고 문법과 구두점을 올바로 사용한다. 주절대지 않는다. 당연한 소리를 반복하지 않는다. 간결하고 명료하게 작성..
첫째, 돌려보자 분석은 검토, 그 이상도 그 이하도 아니다. 우리 모두가 편안하게 여겨야 할 활동이며 남이 내게 해준다면 감사히 반겨야 할 활동이다. 비판이 있어야 발전도 가능하다. 날짜를 표현하는 자바 클래스인 SerialDate를 비판해보자. SerialDate는 SerialDateTests라는 단위 테스트 케이스를 몇 개 포함하고 있는 클래스를 가진다. 하지만 모든 경우를 점검하지 않으므로 클래스를 철저히 이해하고 리팩터링하려면 훨씬 높은 테스트 커버리지가 필요하다. 그리고 경계 조건 오류, 항상 거짓인 if문과 같은 버그들을 수정한다. 변경한 SerialDate가 모든 테스트 케이스를 통과한다면 SerialDate 코드가 제대로 돈다고 믿는다. 이후 SerialDate 코드를 '올바로' 고쳐보자...
JUnit 프레임워크 JUnit은 자바 테스트 프레임워크 중에서 가장 유명하다. JUnit에서 문자열 비교 오류를 파악하기 위해 두 문자열을 받아 차이를 반환하는 모듈인 ComparisonCompactor와 테스트를 살펴보며 모듈에 필요한 기능을 알아보고, 테스트 구조 분석 및 코드를 평가해보자. // ComparisonCompactor.java public class ComparisonCompactor { private static final String ELLIPSIS = "..."; private static final String DELTA_END = "]"; private static final String DELTA_START = "["; private int fContextLength; pr..
Args 구현 출발은 좋았으나 확장성이 부족했던 모듈을 점진적으로 개선하고 정리해보자. 프로그램을 짜다 보면 종종 명령행 인수의 구문을 분석할 필요가 생긴다. 이때 편리한 유틸리티가 없다면 main 함수로 넘어오는 문자열 배열을 직접 분석하게 된다. 또는 여러 가지 훌륭한 유틸리티가 있지만 내 사정에 딱 맞는 유틸리티가 없다면 직접 짜겠다고 결심한다. 이제 새로 짤 유틸리티를 Arg라 부르겠다. Args를 사용하기 위해서는 Args 생성자에 인수 문자열과 형식 문자열을 넘겨 Args 인스턴스를 생성한 후 Args 인스턴스에다 인수 값을 질의하게 되고 생성자에 ArgsException이 발생하지 않는다면 명령행 인수의 구문을 성공적으로 분석했으므로 Args 인스턴스에 질의를 던져도 좋게 된다. 만약 형식 ..
동시성이 필요한 이유? 동시성은 결합을 없애는 전략으로 무엇과 언제를 분리하는 전략이다. 스레드가 하나인 프로그램은 무엇과 언제가 서로 밀접하다. 무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. 마치 프로그램이 작은 협력 프로그램 여럿으로 보인다. 동시성을 정확히 구현하기 위해서는 각별한 주의와 노력을 기울여야 하지만 그럼에도 이것이 제공하는 구조적 이점은 아주 크다. 또한 응답 시간과 작업 처리량 개선이라는 요구사항으로 인해 직접적인 동시성 구현이 불가피한 상황이 발생하기도 한다. 이렇듯 반드시 동시성이 필요한 상황이 존재한다. 동시성은 항상 성능을 높여주는 것이 아니라 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산..
창발적 설계로 깔끔한 코드를 구현하자 켄트 백이 제시한 단순한 설계 규칙 네 가지가 소프트웨어 품질을 크게 높여준다고 믿는다. 1. 모든 테스트를 실행한다. 2. 중복을 없앤다. 3. 프로그래머 의도를 표현한다. 4. 클래스와 메서드 수를 최소로 줄인다. 이로 인해 코드 구조와 설계를 파악하기 쉬워져 단일 책임 원칙, 의존 관계 역전 원칙을 적용하기 쉬워지고 우수한 설계의 창발성을 촉진하게 된다. 단순한 설계 규칙 1: 모든 테스트를 실행하라 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. 테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템은 '테스트가 가능한 시스템'이다. 테스트가 불가능한 시스템은 검증도 불가능하다. 테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진..
도시를 세운다면? 도시는 수도 관리 팀, 전력 관리 팀, 교통 관리 팀, 건축물 관리 팀 등 각 분야를 관리하는 팀이 있기 때문에 잘 돌아간다. 또한 적절한 추상화와 모듈화로 인해 큰 그림을 이해하지 못해도 개인과 개인이 관리하는 '구성요소'는 효율적으로 돌아간다. 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다. 그러므로 높은 추상화 수준인 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴보자. 시스템 제작과 시스템 사용을 분리하라 제작은 사용과 아주 다르다. 소프트웨어 시스템은 애플리케이션 객체를 제작하고 의존성을 서로 연결하는 준비 과정과 준비 과정 이후에 이어지는 런타임 로직을 분리해야 한다. 시작 단계는 모든 애플리케이션이 풀어야 할 관심사이지만 대다수 애플리케이션은 시작 ..
