[Clean Code] 1장. 깨끗한 코드

좋은 팀원들을 만나서 함께 스터디를 하면서 기록을 하게 됐습니다.
제가 발표할 자료들을 짧게 요약한 파일입니다.

1회독이라 이해가 잘못된 부분이 있을 수 있습니다. 언제든지 비난, 비판은 환영입니다 ^^.

Clean Code 1장 (깨끗한 코드)

코드가 존재하리라

• 책에서는 코드를 자동으로 생성해주는 시대가 온다고 말한다. 근데 Copilot은 이미 왔다. 물론 엄청나긴 하지만, 고도로 추상된 언어나 특정 도메인 지식의 언어들을 이해하진 못할것이다. (그라고 그래야한다. 아니면 난 일자리를 잃는다...)
• 제대로 명시한 요구사항은 코드만큼 정형적이고, 테스트 케이스로 사용해도 좋다. 테스트케이스는 잘 설명된 요구사항 그 자체로도 만족할 수 있다.

나쁜 코드

• 르블랑의 법칙(Leblanc's law) 나중은 결코 오지 않는다.
• 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋겠다고 위로하지 말아야한다. 나중에는 하는것은 없다 지금 해야한다.

프로그래머의 역할

• 관리자의 이상한 요구사항들이 쌓여서, 코드가 엉망이 되어 프로젝트 기한을 맞추지 못한다면 그것은 누구 책임일까?
  • 관리자가 헛소리를 한 문제 아닐까?... 관리자의 역할은 일정과 요구사항을 강하게 push하는 역할이다.
• 프로그래머의 역할은?
  • 그런 헛소리에서도 좋은 코드를 사수하는 일이다. 나쁜 코드의 위험을 이해하지 못하는 관리자의 말을 그대로 따르지 말고, 계속 코드를 깨끗하게 유지하려고 해야한다.

깨끗한 코드란?

• 철저한 오류처리 (ex : 메모리 누수, race condition, 일관성 없는 명명법) 들을 처리해야한다.
• 가독성 (닌자코딩 금지)
• 중복이 없다
• 클래스, 메서드, 함수 등을 최대한 줄인다
  • 이건 사실 잘 와닿지 않음. 나중가면 여러 기능들을 최대한 함수로 빼서 만들라면서..
• 모든 테스트를 통과한다.
• 초반부터 간단한 추상화를 고려하기 (여기에 대한 이해가 약간 부족하다. 와닿지 않음. 스터디때 해결 필요)

보이스카우트 규칙

• 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라
• 어떻게 깨끗하게 할 수 있을까?
  • 조금 긴 함수를 분할하기
  • 약간의 중복을 제거하기
  • 복잡한 if문 하나를 정리하기

여기서 우리 프로젝트에 적용할점은?

• 나중은 결코 오지 않는다
  • 이건 나중에 리팩토링 하죠.. 2월 말 안에 꼭 리팩토링해서 출시합시다!! 안하면 저주받습니다..