GO SIWOO!

0. SerialDate jcommon/src/main/java/org/jfree/date/SerialDate.java at master · jfree/jcommon (github.com) JCommon 라이브러리 중 org.jfree.date라는 패키지 안에 위치한 SerialDate라는 클래스의 래팩터링에 관해서 얘기한다. 데이비드 길버트가 만든 날짜를 표현하는 자바 오픈소스 클래스이다. java.util.Date, java.util.Calendar과 같은 날짜를 제공하는 자바 클래스와 다르게 시간 기반의 날짜 클래스가 아닌 순수 날짜 클래스를 만들고자 SerialDate를 만들었다. 1. 첫째, 돌려보자 SerialDateTests라는 클래스는 단위 테스트 케이스 몇 개블 제공한다. 하지만 해당 클..

[클린 코드] 11장 - 시스템 [클린 코드] 10장 - 클래스 [클린 코드] 9장 - 단위 테스트 1. TDD의 법칙 세 가지 1. 첫째 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2. 둘째 : 컴파일은 실패하지 않으면 gosiwoo.tistory.com 1. 창발적 설계로 깔끔한 코드를 구현하자 켄트 벡은 다음 규칙을 따르면 설계는 단순하다고 한다. 모든 테스트를 실행한다 중복을 없앤다 프로그래머 의도를 표현한다 클래스와 메서드 수를 최소로 줄인다 단순한 설계 규칙 1: 모든 테스트를 실행하라 테스트가 불가능한 시스템은 검증도 불가능하다. 테스트가 가능한 시스템을 만드려고 애쓰면 설계 품질이 더불어 높아진다. SRP, 단일 책임을 준수하는 클래스는 테스트가 더욱 쉬우며 더..

[클린 코드] 10장 - 클래스 [클린 코드] 9장 - 단위 테스트 1. TDD의 법칙 세 가지 1. 첫째 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2. 둘째 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도 gosiwoo.tistory.com 1. 시스템 제작과 시스템 사용을 분리하라 소프트웨어 시스템은 준비 과정과 런타임 로직을 분리해야 한다. public Service getService(){ if (service == null) service = new MyServiceImpl(...); // 모든 상황에 적합한 기본값일까? return service; } 위의 코드는 Lazy Initialization/Evaluation의 일반적인 형태로 런타임에서 객체를 초기화..

[클린 코드] 9장 - 단위 테스트 1. TDD의 법칙 세 가지 1. 첫째 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2. 둘째 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 3 gosiwoo.tistory.com 1. 클래스 체계 클래스를 정의하는 표준 자바 관례에 따르면 다음과 같다. public static 상수 (클래스 상수) private static 변수 (클래스 변수) private instance 변수 public instance 변수 public 함수 private 함수 public class Person { public static final String DEFAULT_NAME = "Unknown"; // 1. 클래스 상수 ..

[클린 코드] 8장 - 경계 1. 외부 코드 사용하기 패키지 또는 프레임워크 사용자는 자신의 요구에 집중하는 인터페이스를 바란다 -> 시스템 경계에서 문제가 생길 수 있다. // case1 Map sensors = new HashMap(); Sensor s = (Sensor)sensor gosiwoo.tistory.com 1. TDD의 법칙 세 가지 1. 첫째 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 2. 둘째 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 3. 셋째 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 이렇게 하면 수 많은 테스트 코드를 만들어 낸다. 하지만 이는 심각한 관리 문제를 유발하기도 한다. 2. 깨끗..

1. 외부 코드 사용하기 패키지 또는 프레임워크 사용자는 자신의 요구에 집중하는 인터페이스를 바란다 -> 시스템 경계에서 문제가 생길 수 있다. // case1 Map sensors = new HashMap(); Sensor s = (Sensor)sensors.get(sensordId); // case2 Map sensors = new HashMap(); Sensor s = sensors.get(sensordId); case 1에서는 Map에 Sensor 객체가 들어갈지 장담할 수 없다. case 2로 제네릭스를 사용하지만 Map이 제공하는 여러 메서드를 사용할 수 있으므로 위험하다. public class Sensors { private Map sensors = new HashMap(); public ..

1. 주석은 나쁜 코드를 보완하지 못한다 코드에 주석을 추가하는 일반적인 이유는 코드의 품질이 나쁘기 때문이다. 차라리 주석을 달지 말고 코드를 정리하자! 2. 코드로 의도를 표현하라 // 직원에게 복지 혜택을 받을 자격이 있는지 검사한다. if ((employee.flags & HOURLY_FLAG) && (employee.age > 65)) if (employee.isEligibleForFullBenefits()) 위의 2개의 코드중 아래의 것이 코드로 의도를 즉각적으로 파악할 수 있다. 코드로 대다수의 의도를 표현할 수 있으며 주석으로 달려는 의도를 함수를 만들어 표현이 가능하다. 3. 좋은 주석 3-1. 법적인 주석 회사가 정립한 구현 표준에 맞춰 법적인 이유로 특정 주석이 필요한 경우가 있다. ..

1. 작게 만들어라 함수를 만드는 2가지 규칙은 작게 와 더 작게 이다. 작으면 작을수록 좋다. 중첩 구조가 생길 만큼 함수가 커져서 느 안된다. 함수에서 들여 쓰기 수준은 1단이나 2단을 넘어서면 안 된다. 2. 한 가지만 해라 함수는 한 가지를 해야 한다. 그 한 가지를 잘해야 한다. 그 한 가지만을 해야 한다. 우리가 함수를 만드는 이유는 큰 개념을 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서이다. 쉽게 함수를 한 가지만 하는지 판단하기 위해서는 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다. 3. 함수 당 추상화 수준은 하나로 함수가 한가지 작업만 하려면 함수 내 모든 문장의 추상화 수준을 동일해야 한다. #1. 동일한 추상화 수준? 추상화는 구체..

1. 의도를 분명히 밝혀라 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 위의 변수가 무슨 의도를 지니는 변수인지 알 수 없다.(거리(distance), 시간(date)??) 위처럼 의도가 분명한 이름을 만들자 코드가 단순하다고만 해서 코드의 이해를 짐작하기 쉬운 건 아니다. 이름의 함축성, 맥락이 코드에 드러나야지 함수가 하는 일, 코드가 하는 일을 이해하기 쉬워진다. 2. 그릇된 정보를 피하라 1. 널리 쓰이고 있는 의미의 단어를 다른 의미로 사용하지 말자(hp, iso, aco) 2. List는 프로그래머에게 특별한 의미이므로 실제 List가 아니라면 List를 다른 곳에 사용하여 그릇된 정보를 피하자. 3. 유사한 이름을 사용하지 말자, 서로 다른 모듈에서 비..