[클린 코드] 1장 깨끗한 코드

TIL (Today I Learned)

2022.02.19

 

오늘 읽은 범위

추천사 ~ 1장. 깨끗한 코드

 

책에서 기억하고 싶은 내용

5S 법칙(추천사 xxiv)

- 정렬 : 적절한 명명법 등과 같은 방법을 사용해 무엇이 어디에 있는지 알아야 한다.

- 체계화 : 코드는 누구나 예상하는 위치에 있어야 한다.

- 정리 : 주석으로 처리한 코드나 프로젝트와 상관 없는 주석은 지운다.

- 표준화 : 그룹 내에서 일관적인 구현 스타일과 기법을 도입해야 한다.

- 규율 : 관례를 따르고, 자기 코드를 자주 돌아보고 기꺼이 변경한다.

 

깨끗한 코드란?

1) 논리가 간단한 코드(중복이 없다)

2) 의존성이 최소이며 각 의존성을 명확히 정의하는 코드 -> 유지보수가 쉬워진다

3) 오류를 명백한 전략에 의거해 철저히 처리하는 코드

4) 한 가지를 제대로 하는 코드

5) 모든 테스트를 통과 : 단위 테스트와 인수 테스트 케이스가 존재하는 코드

6) 의미있는 이름으로 시스템 내 모든 설계 아이디어를 표현

7) 클래스, 메서드, 함수 등을 최대한 줄인다.

 

문장

- 빨리 가는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. (7p)

- 테스트 케이스가 없으면 깨끗하지 않다. (12p)

- 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. (18p)

 

오늘 읽은 소감

- 빨리 가는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. (7p)

이 문장이 정말 공감됐다. 사실 졸업프로젝트를 하면서 계속 하는 생각이 '코드 너무 더럽다. 이 기능만 끝나면 뜯어고쳐야지'였는데, 나중에 하지 말고 중간중간에 조금씩 고쳐나가는 습관을 들여야겠다. 사실 지금도 코드 고치고 있다...

- 테스트 케이스가 없으면 깨끗하지 않다. (12p)

사실 조금....아주 많이 찔리는 문장. 지금까지는 스프링에 입문한 지 얼마 되지 않았다는 핑계로 테스트 케이스를 작성하지 않았는데 여기에서 아예 '깨끗하지 않다'라고 못박으니까 죄책감이 든다. 앞으로 하는 프로젝트에는 무조건 테스트 케이스를 작성해야겠다.(사실 일일히 postman으로 돌리는 게 힘든 이유도 있다. swagger도 좋지만 얘는 그렇게 믿음직스럽지 않다)

- 의존성이 최소이며 각 의존성을 명확히 정의하는 코드 -> 유지보수가 쉬워진다

강의 들으면서 절절하게 느낀 것. 이번에 RESTful API 관련 강의를 들었는데 1년 전 강의라 그런지 후반부 50%에서 dependency 버전 오류가 끊임없이 발생했다. 그런데 각 의존성이 어떤 역할을 하는지 나와있지 않아 일일히 찾아보느라 힘들었던 기억이 생생하다. 이번 주 내에 의존성 공부하고 필요한 애들만 골라 써야겠다.

 

궁금하거나 잘 이해되지 않는 내용

- 르블랑의 법칙(leblanc's law) : Later Equals Never

https://yiming.dev/clipping/2019/03/21/le-blanc's-law-a-k-a-later-equals-never/

LeBlanc's Law (a.k.a Later Equals Never) - Yiming Chen

 

객체지향 설계의 5가지 원칙

1) SRP(The Single Responsibility Principle) : 클래스에는 한 가지, 단 한 가지 변경 이유만 존재해야 한다.

-> 변경 이유가 무슨 말인지? 클래스를 왜 변경하는 건지 잘 모르겠다. 

2) OCP(The Open Closed Principle) : 클래스는 확장에 열려 있어야 하며 변경에 닫혀 있어야 한다.

3) LSP(The Liskov Substitution Principle) : 상속받은 클래스는 기초 클래스를 대체할 수 있어야 한다.

4) DIP(The Dependency Inversion Principle) : 추상화에 의존해야 하며, 구체화에 의존하면 안 된다.

5) ISP(The Interface Segregation Principle) : 클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다.