0. 추천사 & 들어가면서

내용

• 우리 개발자들에게는 체크아웃해 코드를 꺼낼 때보다 체크인해서 코드를 넣을 때 더 깨끗한 상태로 만들어야 할 의무가 있다.
• 신은 세세함에 깃들어 있다.
• 작은 것에도 충실한 사람이 큰 것에도 충실하다.
• 품질은 하늘에서 뚝 떨어진 위대한 방법론이 아니라 사심 없이 기울이는 무수한 관심에서 얻어진다.
• 어쩌면 7주, 7일, 7시간 단위로 코드를 고쳐야 할지도 모르겠다. 세세함은 바로 여기에 있다.
• 불행히도 우리는 세세함에 집중하는 태도가 프로그래밍 기술의 핵심이라 여기지 않고 코드에서 일찌감치 손을 뗀다.
• 흔히 고차원적인 뭔가가 품질을 결정하는 요인이기 바라기 때문에 코더가 간단한 들여쓰기 스타일로 가치를 더하는 것에 모욕감을 느낀다.

감상

클린 코드를 작성하려면 어떻게 해야될까 하는 생각으로 읽기 시작했는데, 결국 중요한 것은 사소한 디테일에 집중하고 코드를 여러번 보는 것이라고 한다. 구현을 완료하고 나면 코드리뷰 요청하기 전에 리팩토링하고, 리뷰 받은 것들을 수정하고, 배포하기 전에 제거해야 할 것들을 제거했는지 확인하는 정도로 보고 있었다. 본인이 예전에 썼던 코드를 시간이 지나 다시 보면 왜 이렇게 썼지하는 코드가 많을 거라는 조언을 들었었는데, 배포 완료하고 수정이 필요하지 않은 이상 다시 코드를 찾아보진 않았었다. 근데 생각보다 짧은 주기마다 코드를 고쳐야한다 걸 읽고, 작성하고 꽤 긴 시간이 지난 코드도 보지 않은 것이 아쉬웠고 다시 찾아보고 고쳐봐야겠다고 생각했다. 성능을 향상시키기 위해서는 설계가 중요하다고 생각했는데, 들여쓰기 같은 꽤 간단한 것들이 품질을 결정하는 요인이라고 하는 것도 의외였다. 대단한 것들을 하려고 하기 전에 사소한 것들을 지키고 고쳐야겠다는 생각이 들었다.

1장. 깨끗한 코드

내용

• 궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다. 어느 순간에는 정밀한 표현이 필요하므로 코드도 항상 존재하리라.
• 회사가 망한 원인은 바로 나쁜 코드 탓이었다.
• 우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.
• 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 그러다가 마침내 0에 근접한다.
• 시간을 들여 깨끗한 코드를 만드는 노력은 비용을 절감하는 방법일 뿐만 아니라 전문가로서 살아남는 길이다.
• 좋은 코드를 사수하는 일은 바로 우리 프로그래머의 책임이다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.
• 기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.
• 깨끗한 코드는 세세한 사항까지 꼼꼼하게 처리하는 코드다. (오류 처리 등)
• 깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로.
• 나는 주로 중복에 집중한다. 같은 작업을 여러 차례 반복한다면 코드가 아이디어를 제대로 표현하지 못한다는 증거다.
• 짐작하는 기능을 그대로 수행하는 모듈을 마지막으로 접한 때가 언제였던가? 헷갈리고, 복잡하고, 뒤엉킨 모듈이 얼마나 많던가?
• 깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다.
• 프로그램을 단순하게 보이도록 만드는 열쇠는 언어가 아니다. 언어를 단순하게 보이도록 만드는 열쇠는 프로그래머다!
• 저자에게는 독자와 잘 소통할 책임이 있다. 다음에 코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하기 바란다.
• 시간이 지나도 언제나 깨끗하게 유지해야 한다. 시간이 지나면서 엉망으로 전락하는 코드가 한둘이 아니다. 우리는 적극적으로 퇴보를 막아야 한다.
• 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
• 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if 문 하나를 정리하면 충분하다.
• 지속적인 개선이야말로 전문가 정신의 본질이 아니던가?

감상

• 일정이 급할 때는 스펙을 적당히 타협하거나 컴포넌트를 디자인 시스템에 만들지 않고 그냥 구현하고 나중에 하는 식으로 했었던 적이 꽤 있다. 구현이 복잡한 게 있을 때는 지저분한 코드인 걸 알면서도 나중에 보겠다고 하고 우선 배포하기도 했다. 나중은 절대 오지 않는다는 르블랑의 법칙을 보고 뜨끔했다. 나중이 오지 않았던 건 아닌데, 시간이 나서 리팩토링을 하려고 할 때도 최대한 기능에 구현을 주지 않아 보이는 것들 위주로 리팩토링 했었다. 구현은 잘 되어있는 걸 갈아엎는 게 좀 꺼려졌었다.
• 개발할 때 새로운 코드를 작성하는 시간보다 기존 코드를 읽는 시간이 더 많다고 한다. 기존 코드를 읽으면 자주 등장하는 작가가 있다. 요즘 자주 썼던 레포지토리에 이제 내 코드의 비중이 꽤 커졌는데, 내가 작가라는 생각으로 독자가 읽고 판단하기 좋은 코드를 만들도록 주의해야겠다.
• 코드를 정리할 때 변수 이름 수정, 긴 함수 분할, 중복 제거, 복잡한 if문 정리 등이면 충분하다고 하는데, 그런 것들은 시간을 많이 내지 않고도 할 수 있는 것들이다. 처음에 코드를 작성할 때나, 리뷰 요청 전에 그런 간단한 것들부터 지키고 고치려고 노력해봐야겠다.

2장.

내용

• 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 그러면 코드를 읽는 사람이 좀 더 행복해지리라.
• 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.
• 프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다.
• 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다.
• 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그릇된 정보다.
• 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하는 프로그래머는 스스로 문제를 일으킨다.
• 컴파일러를 통과할지라도 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못하다. 이름이 달라야 한다면 의미도 달라져야 한다.
• 발음하기 어려운 이름은 토론하기도 어렵다. 발음하기 쉬운 이름은 중요하다. 프로그래밍은 사회 활동이기 때문이다.
• 긴 이름이 짧은 이름보다 좋다. 검색하기 쉬운 이름이 상수보다 좋다.
• 클래스와 함수는 점차 작아지는 추세다. 즉, 변수를 선언한 위치와 사용하는 위치가 멀지 않다.
• 전문가 프로그래머는 명료함이 최고라는 사실을 이해한다.
• 클래스 이름과 객체 이름은 명사나 명사구가 적합하다.
• 메서드 이름은 동사나 동사구가 적합나다.
• 일관성 있는 어휘는 코드를 사용할 프로그래머가 반갑게 여길 선물이다.
• 한 단어를 두 가지 목적으로 사용하지 마라.
• 일반적으로는 짧은 이름이 긴 이름보다 좋다. 단, 의미가 분명한 경우에 한해서다.
• 좋은 이름을 선택하려면 설명 능력이 뛰어나야 하고 문화적인 배경이 같아야 한다. 이것이 제일 어렵다.

감상

• 의미 있게 구분하라. 지금 하고 있는 업무를 하다보면 한 파일 안에서 문구를 나타내는 변수와 api에서 받아온 데이터 값이 들어있는 변수가 있다. 문구를 나타낼 때 문구를 가져와서 이름을 바꿔주는 코드가 아래처럼 들어있다. 전체 레포지토리에서 이 문구를 모두 수정하는데 많이 받아올 때는 몇 줄씩 써있다. 그래서 굳이 변수명이 길어지게 Message를 붙여야할까 했었는데, 데이터 값과 구분할 수도 있고 메세지라는 것을 의미 있게 구분할 수도 있게 되기 때문에 변수명을 이렇게 하는 게 좋겠다는 생각이 들었다.

  const { reservation: reservationMessage } = sentences

• 변수명에 Data, Info 등을 붙인 변수를 많이 보기도 하고 내가 쓴 적도 있는 것 같아 뜨끔했다. Data와 Info 등의 단어는 보기에 의미있는 단어라고 생각해서 문제 의식을 갖지 못했는데 예시와 사용 이유를 보니 이런 단어들을 noise word라고 칭하는 것에 납득이 갔다. 이런 단어를 보통 변수에 붙이는 이유는 다른 단어와 구분하기 위해서였던 것 같다.
• 발음하기 쉬운 이름을 사용하라 api에서 값을 받아올 때 모음을 빼고 읽기 힘들게 줄인 변수명이 있었다. 값을 보고 뭘 나타내는 값인지는 알 수 있었지만 그걸 알아도 해독하기 힘든 변수명이었다. 궁금해서 서버 개발자에게 물어보니 서버 개발자도 DB에서 가져와서 쓴 변수명이라 모르겠다고 했다. 누군가 처음에 자기만 아는 변수명을 지어버리면 그 후의 사람들이 연쇄적으로 의문을 갖게 된다. 저자의 역할이 중요하다는 걸 실감했다.