2022/01/03 TIL

클린 코드 1장

기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업
궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다.

개발에 대한 복잡한 생각이 간단하고 명료하게 정리되는 것 같아 좋은 표현이라고 생각한다.
복잡한 요구사항을 받았을 때 이렇게 생각해봐야겠다.

르블랑의 법칙 : 나중은 절대 오지 않는다.

처음 작성할 때부터 좋은 코드를 작성하라는 의미 같다.

1874년에 의사에게 손을 씻으라고 했지만 환자를 보느라 너무 바쁘므로 환자 방문 사이에 손 씻을 시간이 없다는 이유로 거부했다.

회사에서 항상 일정에 대한 논의를 하게 된다. 회사의 성과만을 생각해서 주로 테스트 코드, 유지 보수하기 좋은 코드를 포기했던 경험이 있는데 이를 반성하게 하는 내용이었다.

클린 코드 2장

의도를 분명히 밝히라 라는 챕터를 보게 되면 가독성을 위해 배열 + 상수 코드보다 _Class + Collection_으로 사용하는 예시가 나온다. 프론트 개발자와 의사소통할 때 종종 class의 필요성에 대해 설명하기 어려웠는데 이 예시가 좋은 예시가 될 것 같다.

해법 영역과 문제 영역을 구분할 줄 알아야 한다.

해법 영역은 개발자 영역(전산, 알고리즘, 패턴, 수학)이고 문제 영역(도메인)은 비개발자 영역으로 설명한다. 여기서는 적절한 해법 영역에 없을 때 문제 영역의 용어를 사용하라고 하는데 이 부분에서는 전적으로 동의하지는 않는다. 간단한 어휘를 문제 영역에서 찾을 수 있는데 불필요하게 해법 영역을 찾는 경우 코드를 이해하는데 더 오랜 시간이 걸릴 경우가 있기 때문이다.

_noise word란? 단어가 너무 일반적이어서 검색에 유용하지 않은 단어들_

클린 코드 3장

if, else, while 문 등에 들어가는 블록은 한 줄이어야 한다.
함수에서 들여 쓰기 수준은 1단이나 2단을 넘어서면 안 된다.

들여 쓰기와 관련해서는 책을 읽기 전에도 이미 알고 있던 내용이었고, 항상 실천 중인 작업이다.
종종 JPA에서 Optaional로 리턴 값을 받을 때 값이 없는 경우 null로 받는 경우가 있다. (물론 이 부분은 애초에 null을 받지 않는 방법을 고민하는 것이 좋다.)
이럴 경우 null이 아닌 경우 코드를 진행시키는 방법보다는 null인 경우를 리턴하는 것이 좋다.

AS-IS

public String getName(Long id){
    Optional<String> name = userRepository.findById(id).orElse(null);
    if (name != null){
        ...
        ...
    }
}

TO-BE

public String getName(Long id){
    Optional<String> name = userRepository.findById(id).orElse(null);
    if (name == null){
        return null;
    }
    ...
    ...
}

함수가 한 가지만 한다는 것은 의미 있는 이름으로 다른 함수를 추출할 수 없다는 뜻

함수가 한 가지 일만 한다는 것이 항상 모호했었는데, 이 글을 읽고 나서 좋은 방법이라고 생각했다. 하지만 이 부분 역시 어떻게 추출하느냐에 따라 애매한 부분이 있기 때문에 경험을 쌓아가며 나만의 기준을 만드는 것이 중요한 것 같다.