5월 18일 토요일에 마지막 스터디를 했다. 뒤쪽 부록에 있는 동시성II 까지 보면 좋겠다는 생각도 했지만, 부록은 부록이니 각자 보는게 더 낫나 싶기도하고 여튼 끝났다!

16장 SerialDate 리팩터링

옛날 Java에서는 시간과 날짜를 다루는게 꽤 불편했다. 기본 SDK에서 제공해주는 Date와 Calendar는 불편한게 많았기에 Joda-Time을 많이 썼었다. Java8 부터 LocalDate, LocalTime, LocalDateTime을 제공하기 때문에 시간과 관련된 불편함이 많이 사라졌다.

SerialDate github Repo를 보면 클린코드 책에서 지적한 문제점들이 그대로 남아있다. 이번 16장을 보면서도 '왜 개선사항이 반영되지 않았을까?' 가 생각났다.

Jcommon의 열려있는 PR 중에 개선을 시도한 내용이 있긴있다. PR 6은 이 클린코드에서 지적한 것들을 리팩토링하는 내용이 담겨있고, 이런 내용이 본문에 적혀져있다.

I saw that this Jcommon library is to be retired that is why I selected this as a playground.

해석하자면 이젠 Jcommon은 쓰지 않는 것이기 때문에 놀이터로 삼겠다(…)는 내용이다. 이 PR에 아무도 반응조차 안해주고 그대로 열어둔게 신기했다.

p.347 둘째, 고쳐보자

449쪽 61행에서 시작하는 import 문은 java.text.*와 java.util.*로 줄여도 된다. [J1]

모든 것을 import하면 느려지지 않을까?라는 생각을 할 수 있다. 컴파일 할 때는 느려지는것이 맞긴하나, 런타임 속도에는 영향을 주지 않는다. 어차피 결과물로 나오는 바이트 코드는 import java.util.*을 하나 마나 똑같기 때문이다.

테스트 커버리지 100퍼 만드는거 많이 어렵나요?

• 보통 사용하는 프레임워크를 테스트 하지 않는다. 그것을 믿고 가져다 쓰기 때문에 모든 라인을 테스트 하지 않게된다.

• 테스트 커버리지가 높으면 좋긴하나, 100퍼를 달성하려고 하다보면 ‘테스트를 통과하기 위해서’ 코드를 짜게된다. 이 책의 p.286에 있는 것 처럼 테스트 프레임워크 때문에 본 로직을 변경하는 것은 좋지 않다.

• 그런 이유인지는 모르겠지만.. 테스트 커버리지 측정하는 툴에서 커버리지 측정에 포함시키지 않을 것들을 뺄 수 있다. 과거 coveralls 쓸 때 한번 해봤는데, 뺄거 빼고 측정하면 커버리지가 엄청 높아진다.

17장 냄새와 휴리스틱

p.376 G10: 수직 분리

비공개 함수는 처음으로 호출한 직후에 정의한다.

여기서 말하는 비공개 함수는 private 함수다. private 함수를 호출하는 부분이 있으면, 바로 뒤에 해당 private 함수를 정의해야 가독성이 높다. 앞에 소설처럼 읽히게 짜라는 내용이 있었는데, 그 때 한번 언급되었었다.

JavaScript에서는 Java와 반대다. 선언을 먼저하고 사용을 해야한다. 선언하기전에 호출을 해도 돌아는가는데, Lint에서 거른다.

p.379 G15: 선택자 인수

여기서 말하는 내용과는 별개로, 예제를 보면 변수이름도 이상하게 해놨다. 예제에는 아래와 같은 함수가 있다.

public int calculateWeeklyPay(boolean overtime) {
    // ...
}

이 부분을 보다가 ‘왜 boolean이 int로 바뀌는거지? 것보다 이게 돌아가는 코드라고?’ 이 생각을 한참 하고 있었다. 자세히 보면 overtime, overTime 대소문자가 다르다(…)

int overTime = Math.max(0, tenthsWorked - straightTime)

기타

마지막 17장을 읽으면서 좀 읭?스러운 것들이 있긴했는데, 그건 개인 취향문제인듯 하니 넘어가기로 했다. 아래는 17장을 읽으면서 읭?했던 부분들이다.

• p.368 C1: 부적절한 정보

  일반적으로 작성자, 최종 수정일, SPR(Software Problem Report) 번호 등과 같은 메타 정보만 주석으로 넣는다.

• p.380 G17: 잘못 지운 책임

  PI 상수는 삼각함수를 선언한 클래스에 넣어야 맞다.

• p.387 G25: 매직 숫자는 명명된 상수로 교체하라

  하지만 8이 들어간 공식은 너무 깔끔하기에 굳이 18자나 되는 상수를 추가하기 꺼려진다. 첫 번째 FEET_PER_MMILE은 5280이 너무나도 잘 알려진 고유한 숫자라 주변 코드 없이 숫자만 달랑 적어놔도 독자가 금방 알아본다.