[book] CLEAN CODE
- 1 minCLEAN CODE
18.10.28
- 코드는 요구사항을 표현하는 언어
- 요구사항에 더욱 가까운 언어를 만들거나, 요구사항에서 정형구조를 뽑아내는 도구를 만들 수는 있다.
- 하지만, 정밀한 표현이 필요한 순간은 분명히 오고, 그 필요성을 없앨 방법은 없다.
- 따라서 코드는 항상 존재한다.
- 그러므로 좋은 코드를 짜는 것은 언제나 중요한 과제이다.
- 르블랑의 법칙
- 나중은 결코 오지 않는다
- 기술부채
- 프로그래머가 나쁜 코드의 위험을 이해하지 못하는 관리자의 말을 단호하게 거부하는 것
- 의사가 수술전 손을 씻지 말라는 환자(고객)의 말을 단호하게 거부하는 것과 같다.
- 프로젝트가 망하는 것은 전적으로 전문가답게 행동하지 못한 프로그래머의 책임이다.
- 많은 프로그래머가 기한을 맞추기 위해 나쁜 코드를 양산하는 것을 어쩔 수 없다고 생각한다.
- 즉, 빨리 가기 위해 시간을 들이지 않는다.
- 즉, 네모난 바퀴를 둥근 바퀴로 바꾸기 위한 시간을 들이지 않는다.
- 코드는 추측이 아닌 사실에 기반해야하며, 단호한 인상을 심어주어야 한다.
- 깨끗한 코드는 잘 쓴 문장처럼 읽혀야한다.
- 좋은 책을 읽을 때, 단어가 사라지고 한 편의 영화를 보는듯한 이미지가 떠오르듯, 코드도 그래야한다.
- 작성자가 아닌 사람도 읽고 고치기 쉬워야한다.
아무리 가독성이 높아도 테스트케이스가 없는 코드는 깨끗한 코드가 아니다.
- 중복을 피하라, 한 기능한 수행하라, 제대로 표현하라, 작게 추상화하라
- 깨끗한 코드는 읽으면서 놀랄 일이 없어야한다.
- 너무 깨끗해서 읽는이가 그냥 고개를 끄덕이고 넘어갈 정도로
- 특정 언어를 신봉하는 사람이 많은데, 결국 프로그램을 깨끗하게 만드는 것은 언어가 아닌 그 언어를 깨끗하게 보이도록 만드는 프로그래머이다.
- 프로그래머는 저자이다.
- 저자에게는 독자가 있고, 그 독자와 잘 소통할 책임도 있다.
- 독자는 제 3자가 아닌 프로그램을 짜는 프로그래머 본인도 포함된다.
- 편집 세션을 재생해보면, 우리는 새 코드를 짜면서도 끊임없이 기존 코드를 읽는다.
보이스카웃 원칙 : 캠프장을 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라
- 이름 붙이기의 중요성
- 우리는 작은 변수부터 시작해 메소드, 클래스, 모듈, 패키지등의 모든 컴포넌트에 이름을 붙인다.
- data, info 같은 애매한 표현을 쓰지 말자
- 검색하기 쉬운 이름을 사용하자. (이름의 길이는 범위의 크기에 비례한다)
- 클래스나 객체의 이름은 명사나 명사구로, 메소드 이름은 동사나 동사구로