전체 글

N7: 이름으로 부수 효과를 설명하라 함수, 변수, 클래스의 이름에 부수 효과를 숨기지 않는다. => 여러 작업을 수행하는 함수일 경우, 하는 일을 모두 기술하는 이름을 사용한다. 테스트 T1: 불충분한 테스트 테스트 케이스는 잠재적으로 깨질 만한 부분을 모두 테스트해야 한다. => 테스트 케이스가 확인하지 않는 조건이나 검증하지 않는 계산이 있다면 그 테스트는 불완전하다. T2: 커버리지 도구를 사용하라! 커버리지 도구를 사용하면 테스트가 불충분한 모듈, 클래스, 함수를 찾기가 쉬워진다. 대다수 IDE는 테스트 커버리지를 시각적으로 표현하여 테스트가 빠뜨리는 공백을 알려준다. T3: 사소한 테스트를 건너뛰지 마라 사소한 테스트는 짜기 쉽고, 제공하는 문서적 가치는 구현에 드는 비용을 넘어선다. T4: ..

자바 J1: 긴 import 목록을 피하고 와일드카드를 사용하라 ex) import package.*; 긴 import 목록은 읽기에 부담스러우며, 명시적인 import문은 강한 의존성을 생성함 J2: 상수는 상속하지 않는다 상수는 상속 대신 static import를 사용한다. J3: 상수 대 Enum public static final int보다 enum을 사용하라. enum은 이름이 부여된 열거체로, 메서드와 필드도 사용할 수 있는 훨씬 유연하고 서술적인 도구이다. 이름 N1: 서술적인 이름을 사용하라 소프트웨어 가독성의 90%는 이름이 결정한다. 서술적인 이름을 신중하게 골라야 함 N2: 적절한 추상화 수준에서 이름을 선택하라 구현을 드러내는 이름은 피하고 작업 대상 클래스나 함수가 위치하는 추상..

G26: 정확하라 코드에서 뭔가를 결정할 때는 정확히 결정하고, 결정을 내리는 이유와 예외를 처리할 방법을 분명히 알아야 한다. -> 모호성과 부정확은 제거해야 함 G27: 관례보다 구조를 사용하라 설계 결정을 강제할 때는 규칙보다 관례를 사용한다. 명명 관례도 좋지만 구조 자체로 강제하면 더 좋다. ex) switch/case 문보다 추상 메서드가 있는 기초 클래스가 더 좋다. G28: 조건을 캡슐화하라 부울 논리는 이해하기 어려우므로 조건의 의도를 분명히 밝히는 함수로 표현하라. ex) if(timer.hasExpired() && !timer.isRecurrent()) -> if(shouldBeDeleted(timer))로 변경 G29: 부정 조건은 피하라 부정 조건은 긍정 조건보다 이해하기 어려우므..

G15: 선택자 인수 선택자 인수 : 함수나 메서드의 인수 중 하나가 다른 인수들의 처리 방식을 결정하는 역할을 하는 것. 선택자 인수는 목적을 기억하기 어려울 뿐 아니라 각 선택자 인수가 여러 함수를 하나로 조합함 ex: calculateWeeklyPay(false) 같은 함수의 boolean 인수 일반적으로 인수를 넘겨 동작을 선택하는 대신 새로운 함수를 만드는 편이 좋다. G16: 모호한 의도 코드를 짤 때는 의도를 최대한 분명히 밝힌다. 행을 바꾸지 않고 표현한 수식, 헝가리식 표기법, 매직 번호 등은 모두 가독성을 흐림 => 피하는 게 좋음 G17: 잘못 지운 책임 코드를 배치할 때는 독자가 자연스럽게 기대할 위치에 배치한다. ex) PI 상수는 삼각함수를 선언한 클래스에 배치 기능을 개발에 편..

냄새와 휴리스틱 다양한 코드 냄새(코드를 좋지 않게 짠 경우)와 코드를 짜면서 사용하는 기교, 휴리스틱을 소개한다. 아래의 경우들은 모두 바람직하지 않은 관습들의 나열임 주석 C1: 부적절한 정보 소스 코드 관리 시스템, 버그 추적 시스템, 이슈 추적 시스템 등 다른 시스템에 저장할 정보는 주석으로 적절치 않음 C2: 쓸모 없는 주석 오래된 주석, 엉뚱한 주석, 잘못된 주석은 더 이상 쓸모가 없음 => 쓸모 없는 주석은 코드와 무관하게 따로 놀며 코드를 그릇된 방향으로 이끎 C3: 중복된 주석 코드만으로 충분한데 구구절절 설명하는 주석은 불필요함 C4: 성의 없는 주석 문법과 구두점을 올바로 사용하고, 간결하고 명료하게 작성한다. C5: 주석 처리된 코드 주석 처리된 코드는 아무도 그 쓰임을 모르며, 매..

SerialDate 클래스 리팩터링 작업 정리 주석 개선 enum을 독자적인 소스 파일로 옮김 정적 변수와 정적 메서드를 위치와 연관성에 따라 새 클래스로 옮김 일부 추상 메서드를 클래스로 끌어올림 enum 변경 새 메서드를 생성해 중복을 없앰 숫자 1을 다른 변수 혹은 상수로 변경 리팩토링을 통해 테스트 커버리지가 증가하고, 버그를 고치고, 코드 크기를 줄이고 코드를 명확하게 함.

리팩터링 과정 2 일반적으로 기반 클래스(부모 클래스)는 파생 클래스(자식 클래스)를 몰라야 바람직 => ABSTRACT FACTORY 패턴을 적용해 DayDateFactory를 생성 => DayDate 인스턴스를 생성하는 클래스를 분리. createInstance 메서드를 좀 더 서술적인 makeDate라는 이름으로 변경 변수를 적절한 클래스로 옮김 상수를 enum으로 변경 변수 이름만으로 의미가 확실한 주석 삭제 사용하지 않는 변수, 메서드 등 제거 변수가 사용되는 위치에 가깝게 옮김 이름 변경 기본 생성자 제거 final 키워드 제거 로직을 옮기며 클래스 내의 일부 코드가 독자성을 갖고 커지면 클래스에서 빼내 별도의 소스 파일로 분리 서술적인 코드로 변환하며 가독성 높임 복잡한 알고리즘의 경우 임시..

SerialDate 리팩터링 JCommon 라이브러리의 org.jfree.date 패키지 내에 있는 SerialDate 클래스를 탐험한다. SerialDate : 날짜를 표현하는 자바 클래스. 시간대에 무관하게 날짜를 표현하기 위한 클래스다. 첫째, 돌려보자 테스트 케이스 점검 기존 테스트 케이스가 모든 경우를 점검하지 않음. => 코드 커버리지 분석 도구인 클로버를 이용해 조사한 결과, 실행 가능한 문장 중 약 50%만 단위 테스트가 실행됨 +테스트 케이스의 많은 코드가 주석으로 처리됨(실패한 테스트 케이스) => 독자적으로 단위 테스트 케이스 구현 -> 코드 커버리지 대략 92% 달성 => 주석으로 뺀 코드 점검 => 통과해야 할 테스트들을 살리고, 테스트 케이스를 통과하도록 디버깅. 둘째, 고쳐보자..

JUnit 들여다보기 리팩토링 과정 함수 사용방식이 일관적이지 못한 부분 수정 함수에서 마지막 두 줄은 변수를 반환하지만 첫째 줄과 둘째 줄은 반환값이 없음 => 각각 함수를 변경해 무언가를 반환하도록 수정 부정확한 멤버 변수 이름 변경 prefix/suffix 변수가 실제로는 색인 위치를 나타내고 있으므로 각각 뒤에 -Index를 추가 숨겨진 시간적인 결합 외부에 노출 findCommonSuffix 함수는 findCommonPrefix가 prefixIndex를 계산한다는 사실에 의존 => 만약 findCommonSuffix와 findCommonPrefix를 잘못된 순서로 호출하면 원인을 찾기 어려움 => 시간 결합을 외부에 노출하고자 prefixIndex가 findCommonSuffix의 인수로 넘어가..

JUnit 들여다보기 JUnit : 유명한 자바 프레임워크. 구현이 잘 되어 있음. JUnit 프레임워크 JUnit의 ComparisonCompactor 모듈을 살펴 본다. -> 두 문자열을 받아 차이를 반환하는 코드. ex) ABCDE와 ABXDE를 받으면 를 반환 코드를 살펴보면 잘 분리되었고 표현력이 적절하며 구조가 단순함. ComparisonCompactor 모듈을 살펴 보고 보이스카우트 규칙에 따라 리팩토링해 보는 시간을 가진다. 리팩토링 과정 멤버 변수 앞에 붙인 접두어 f 제거 오늘날 사용하는 개발 환경에서는 변수 이름에 범위를 명시할 필요가 없으며 접두어 f는 중복되는 정보임. 캡슐화되지 않은 조건문 캡슐화 의도를 명확히 표현하기 위해 조건문을 메서드로 뽑아내 적절한 이름을 붙인다. 이름이..