[Clean Code] 1~4장 내용 정리 + 리뷰

중요하다고 생각하는 부분

• 개발자는 의사와 같다!
  "빨리 수술해달라는 환자에 말을 듣고 서두르기보다는, 손씻기를 우선하는 의사와 같이 전문성을 갖춰야 한다"
  
• 함수는 한 가지만을, 잘 해야 한다
• 주석은 사실상 필요악이며, 없는 게 최선이다.

내가 활용할 수 있는 부분

• 체계적이고 의미있는 이름 짓기
• 함수가 몇 가지의 일을 하는지 파악하고, 한 가지 일을 하게끔 만들기
  (들여쓰기는 1~2단을 넘어서지 않도록 하기)
• 최대한 주석 제거하기
  
  

인사이트

• 개발을 공부한 지 얼마 되지 않았고, 특히나 혼자 힘으로 실습을 해나가면서 아직 이런저런 습관을 바로잡을 생각을 못했었다.
  이 책을 4장까지 읽어나가며 그동안 내가 얼마나 잘못된 습관을 많이 가지고 있었는지를 알 수 있었다.
• 항상 네이밍이 많이 어렵고 고민되었는데 구체적으로 네이밍 예시를 들어주니 더 와닿았다. 평소에 이름을 길게 짓는 편이라, 지을 때마다 사실 '너무 길어지는 거 아닌가..? 축약해서 써야 할까?'라고 고민을 많이 했다. 그러나 오히려 그런 방면에서는 줄이기보다 지금처럼 자세히 풀어서 작성하는 게 더 좋다는 걸 깨달았다.
• 주석은 부연설명을 하는 포스트잇, 즉 메모같은 역할이라고 생각해서 나쁘다고 여기지 않았는데.. '아예 없는 게 베스트'라는 내용을 보고 조금 놀랐다. 없을수록 좋은 거였다니! 특히 아직까지 혼자서만 작업하다보니.. 테스트 삼아 코드를 바꾸면서 이전 코드를 주석처리해놓는 경우가 있었다. 앞으로는 처음부터 코드를 다른 곳에 저장해놓고 주석을 사용하지 않는 방향으로 바꿔야겠다고 생각했다.

 

---

1장. 깨끗한 코드

1-1) 코드는 없어지지 않는다!

• 코드는 요구사항을 상세히 표현하는 수단이다.
• 코드 생성이 자동화되어도 고도로 추상화된 언어나 특정 분야의 언어로 작성하는 것 역시 코드이기 때문에, 코드가 없어질 일은 없다. 
• 오히려 어떤 언어이든 코드는 기계가 이해하고 실행할 수 있도록 세밀하고 구체적으로 작성되어야 한다.

1-2) 좋은 코드 vs 나쁜 코드

• 개발자는 바쁘더라도 서두르기보다는 손씻기를 우선하는 의사처럼 프로페셔널해야 한다.
• 기한을 맞출 수 있는 유일한 방법은 언제나 깨끗한 코드를 유지하는 습관이다.
• 깨끗한 코드를 작성하려면 좋고 나쁜 코드를 구분하는 '코드 감각'이 있어야 한다.

1-3) 깨끗한 코드란? 전문가의 의견은..

• 세세한 사항까지 꼼꼼히 처리하는 코드
• 사실에 기반하여 필요한 내용만 명확히 드러낸 것
• 다른 사람이 고치기 쉬운 코드
• 주의 깊게 작성한 코드
• 다른 사람이 고치기 쉽다.
• 중복 없이, 한 기능만 수행하고, 제대로 표현하며 작게 추상화된 것
• 읽으면서 짐작한 대로 돌아가는 코드

 

---

2장. 의미 있는 이름

그렇다면 좋은 코드란 어떤 것을 가리키는 것일까?

 

2-1) 의도를 분명히 밝혀라

• 의도가 분명한 이름은 시간 절약 차원에서 정말 중요하다.
• 변수 / 함수 / 클래스명에 존재 이유, 수행 기능, 사용 방법 명시할 것
• 코드의 단순성 < 코드의 함축성
• 너무 기발해서 의도가 명료하게 보이지 않는 이름은 피하자

2-2) 잘못된 정보를 피하라

• 일반적인 의미를 가진 단어를 다른 의미로 사용하지 말자
• 서로 비슷한 이름을 사용해 헷갈리지 않도록 주의하기
• 일관성이 떨어지는 표기법은 잘못된 정보이다

2-3) 의미 있게 구분하라

• 이름이 다르다면 의미도 달라져야 한다. 
• name1, name2, name3 등의 연속적 숫자, a / the 추가, data / info 사용 등 주의하기
• variable, table, name, string 등 불용어를 사용하지 말자

2-4) 클래스 , 객체 , 메소드 네이밍

• 클래스, 객체 이름
  - 명사나 명사구가 적합하다
  - 예) Info, Data  (x) AddressParser, WikiPage (o)
• 메소드 이름
  - 동사나 동사구가 적합하다
  - 접근자, 변경자, 조건자는 값 앞에 get, set, is 를 붙인다
  - 예) getName, setName, isPosted

2-5) 그 외 주의사항

• 발음이 쉽고, 검색이 용이한 이름 사용하기
• 문자 하나만을 변수 이름으로 쓰지 말자
• 한 단어를 두 가지 목적으로 사용하지 말 것
• 의미 있는 맥락 추가, 불필요한 맥락 제거
• 인코딩을 피하라
  - 인코딩한 이름은 발음이 어렵고 오타가 생기기 쉽다
  - 인코딩을 하더라도 접두사는 붙이지 말 것
• 한 개념에 한 단어 사용하기
  - 추상적 개념 하나에 단어 하나를 선택해 꾸준히 사용하자
  - 일관성 있는 어휘를 사용할 것!
• 기술 개념에는 기술 분야와 관련된 이름을 붙여라
  - 적절한 용어가 없다면 문제 영역에서 이름을 가져올 것

---

3장. 함수

 

3-1) 작게 만들어라

• if 문 / else 문 / while 문 등에 들어가는 블록은 한 줄이어야 한다
• 중첩 구조가 생길만큼 함수가 커져서는 안된다
• 함수에서 들여쓰기는 1~2단을 넘어서지 않는 것이 좋다

3-2) 한 가지만 해라

• "함수는 한 가지만을, 잘 해야 한다!"
• 우선 작성한 함수가 몇 가지의 일을 하는지 파악해야 한다
• 한 함수의 이름 내에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다
• 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다

3-3) 함수 당 추상화 수준은 하나로!

• 짧으면서도 한 가지만 하는 함수를 만들자
• 함수를 내려가기 규칙에 따라 작성할 것
• 코드는 위에서 아래로 이야기처럼 읽는 게 좋다 (함수 추상화 수준이 한 단계씩 낮아짐)

3-4) 구조적 프로그래밍

• 구조적 프로그래밍 원칙: 모든 함수와 그 안의 모든 블록에 입구와 출구가 하나만 존재해야 한다
  → 함수는 return 문이 하나여야 한다
  → 루프 안에서 break 나 continue 를 사용해서는 안된다
  → goto 는 절대 사용하지 않아야 한다
• 위와 같은 원칙은 함수가 아주 클 때만 유리하다
  → 함수가 작다면 return, break, continue 를 사용해도 된다
  → goto 문은 작은 함수에서는 피하자

3-5) 기타

• 서술적인 이름을 사용해라
  예) testableHTML → setupTeardownIncluder.render
• 한 가지만 하겠다고 하고 다른 일을 더 하게 하지 말자 (부수 효과 X)
• 명령과 조회를 분리해라
• 중복은 최대한 제거하는 것이 좋다
• 소프트웨어를 짜는 것은 글짓기와 비슷하다 (생각 기록 → 다듬기)

 

---

4장. 좋은 주석 vs 나쁜 주석

클린코드의 저자는 주석이 사실상 필요악이라고 말한다. 
주석을 사용하는 것은 거의 대부분 실패한 경우이기 때문에, 가능한 안쓰는게 좋다고 말이다.
특시 주석은 코드를 수정할 때 자동으로 수정되지 않는 부분이기 때문에, 유지보수가 어렵다는 큰 단점이 있다.
 
애초에 주석이 없는 게 좋지만..
만약 꼭 써야만 한다면, 어떤 것이 좋고 나쁜 주석일까?

4-1) 좋은 주석

• 법적인 이유로 주석을 넣어야 하는 경우
• 기본적인 정보를 제공하는 경우
• 결정에 대한 이유를 설명하는 주석
• 모호한 인수나 반환값의 의미를 밝히는 주석
• 다른 개발자에게 결과를 경고하는 내용
• 앞으로 할 일 (//TODO)
• 쉽게 넘어갈 수 있는 부분의 중요성을 강조할 때
• 공개 API를 구현할 경우 Javadocs 작성
  
  

4-2) 나쁜 주석

• 이유 없이 의무감으로 작성한 주석
• 너무 당연하거나 오해의 여지가 있는 내용
• 저자를 표시하는 주석
• 모든 함수에 Javadocs를 달거나, 모든 변수에 주석을 달 필요는 없다!
  → 비공개 코드에서 Javadocs는 쓸모없다
• 관련 없는 정보를 작성하거나 코드 내용을 반복한 주석
  → 함수나 변수로 표현할 수 있다면 주석을 달지 말자
  → 코드를 주석으로 처리하지 말자
• 소스 파일에서 특정 위치를 표시하는 주석 (ex. ////// Actions /////// )
  → 배너를 남용하면 독자가 쓸데없는 내용으로 여기고 무시하기 쉽다
• 닫는 괄호에 다는 주석
  → 주석 대신 함수를 줄이도록 노력해보자
• 코드 일부에 주석을 달면서 시스템의 전반적인 정보를 기술하지 말자 
  → 주석을 단다면 근처에 있는 코드만 기술하자