[클린코드] 14~16장 정리(점진적인 개선, JUnit 들여다보기, SerialDate 리팩터링)

<클린코드> 책을 통해 공부한 내용을 정리하기 위해 작성하였습니다. 제 개인적인 각색과 의견이 첨가되어 있어 실제 책의 내용과는 차이가 있을 수 있습니다.

14장. 점진적인 개선

- (내 생각) 해당 장은 Args 클래스에 대한 첫 작성부터 리팩터링까지의 과정이 디테일하게 기록되어있다. 그렇기에 양이 방대하다. 해당 장을 어떻게 공부하는 것이 내가 인사이트를 많이 얻을 수 있는 방법일까 생각해 봤을 때 우선은 전 과정을 차근차근 읽고 밑줄을 치거나 기록을 하는 방법이라고 생각했다. 공부를 하다 보니 원론적인 해당 클래스에 대한 기능 이해 자체가 부족함을 느꼈다. 그렇기에 메서드의 정확한 기능과 선언된 프로퍼티들의 의도의 파악이 어려웠고 이에 따라 리팩터링 역시 완전한 공감이 어려웠다. 그래서 아래와 같이 Nestjs + TS 기반의 간단한 프로젝트로 Args 클래스를 작성했고 그 동작을 이해해 보려고 노력했다. 
https://github.com/mmmmicha/args-marshaler-ts-playground/tree/main/src

args-marshaler-ts-playground/src at main · mmmmicha/args-marshaler-ts-playground

15장. JUnit 들여다보기

- 부정문은 긍정문보다 이해하기 약간 더 어렵다.

 

- (각색) 간혹 코드를 보다보면 숨겨진 시간적인 결합이 존재하는 경우가 있다. 이런 경우 시간 결합을 외부에 노출하도록 한다. 그 방법으로는 먼저 진행해야 하는 함수의 리턴값을 다음 단계 함수의 인수로 넣게끔 구조를 만들어 시간 결합을 대놓고 노출하는 방식이 있다.

 

- (각색) 코드를 고치다보면 기존에 선언되어 있던 변수의 잘못된 네이밍을 발견하게 되는 경우도 있다. 이럴경우 역시 주변을 잘 살펴보고 리팩터링을 함께 진행해주면 좋겠다.

16장. SerialDate 리팩터링

- 강조하건대, 이 장에서 분석하는 분석은 악의나 자만과는 거리가 멀다. 전문가 입장에서 수행하는 검토, 그 이상도 그 이하도 아니다. 우리 모두가 편안하게 여겨야 할 활동이다. 남이 내게 해준다면 감사히 반겨야 할 활동이다. 이와 같은 비판이 있어야만 발전도 가능하다. 의사들도 한다. 조종사들도 한다. 법률가들도 한다. 우리 프로그래머들도 방법을 배워야 한다.

 

- '일련번호'라는 용어는 정확하지 못하다. 사소한 꼬투리일지도 모르지만, 일련번호보다 '상대 오프셋'이 더 정확하다. '일련번호'라는 용어는 날짜보다 제품 식별 번호로 더 적합하다. 그래서 나는 SerialDate가 그다지 서술적인 이름이 아니라 생각한다. 좀 더 서술적인 용어로는 '서수(ordinal)'이 있다.

- (내 생각) 영어권의 개발자들 조차 용어 사용이 잘못되는 경우가 많은데, 비 영어권 개발자들은 더욱 고심하고 실제 영어권에서 어떤 단어를 어떤 용도로 많이 사용하는지 알아보려는 노력이 몇배는 더 필요하다.

 

- 일반적으로 기반 클래스(Base class, 부모 클래스)는 파생 클래스(Derivative, 자식 클래스)를 몰라야 바람직하다.

 

- 일반적으로 메서드 인수로 플래그는 바람직하지 못하다. 특히 출력 형식을 선택하는 플래그는 가급적 피하는 편이 좋다.

 

- ...코드를 읽는 사람은 분명히 addDays가 date 객체를 변경한다고 생각한다. 그러므로 이런 모호함을 해결할 이름이 필요하다. 그래서 나는 plusDays와 plusMonths라는 이름을 선택했다. 메서드의 원래 의도를 잘 반영하는 이름이라 생각한다.