1. 깨끗한 코드

• 코드에 정직하고, 코드의 상태에 관하여 동료들에게 정직하고, 무엇보다도, 자기 코드에 대해서 자신에게 정직하라는 뜻이다.
• 우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 나중은 결코 오지 않는다.
• 나쁜 코드를 양산하면 기한을 맞추지 못한다.오히려 엉망진창으로 속도가 늦어지고, 결국 기한을 놓친다. 기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.
• 깨진 창문
• 한 가지 기능만 수행하라. 중복없이.
• 짐작했던 기능을 그대로 수행하도록.

2. 의미 있는 이름

• 단순하지만 그 의미가 분명해야 한다.(의미 있는 맥락을 추가)
• 클래스 이름은 명사로, 메서드 이름은 동사로 시작하도록.
• 한 개념에 대해서는 한 단어 e.g.get, retrieve, fetch/ controller, manager, driver를 한 코드 안에서 섞어 쓰지 말기

• 자신이 짠 모든 클래스, 메서드 이름을 외우지는 못하는게 당연하다. 우리는 문장이나 문단처럼 읽히거나 표나 자료 구조처럼 읽히는 코드를 짜는데만 집중해야 한다. 코드를 개선하려는 노력을 중단해서는 안된다.

  3. 함수

• 작게, 더 작게 만들자. 한 가지 작업만 하도록.
• 길어도 서술적인 이름이 짧고 어려운 이름보다 낫다. - 좋은 이름은 짐작한 대로 이야기가 흘러가게 한다.
• 인수는 적을수록 좋다. 0개>1개>2개. 그 이상은 가능한 피하자. 분명 필요한 순간도 있지만, 헷갈릴 우려도 높다.
• 부수효과를 일으키지 말자. 부수효과는 함수의 사용성을 낮추고, 의도치 않은 결합을 만든다.
• 처음에는 길고 복잡하다. 단위테스트는 항상 통과해가면서 코드를 다듬어 나가는 과정이 필요하다. 처음부터 그것이 가능한 사람은 없다.
• 프로그래밍 언어를 사용해 좀 더 풍부하고 좀 더 표현력이 강한 언어를 만들어 이야기를 풀어나가자.

4. 주석

• 코드만이 정확한 정보를 제공한다. ‘나쁜 코드 + 주석’보다 그 코드를 개선시키는데에 시간을 쓰자.

  • 결국 주석없이 명확한 코드는 좋은 이름과 한 가지 기능을 하는 분명한 함수에서 나온다.
• 주석이 있어 알고리즘을 이해하기 쉬워진다면, 주석을 다는 편이 좋다. 하지만 그것이 코드로만으로 가능한 것이 더 좋을 것이다.

6. 객체와 자료 구조

• 객체는 동작(함수)를 공개하고 내부 구조(자료구조)를 숨긴다.
  → 기존 동작 변경 없이 새로운 객체 추가는 쉽지만, 기존 객체에 새 동작 추가는 어렵다.
  → 새로운 자료 타입이 필요하면 클래스와 객체지향이 가장 적합

• 자료구조는 자료를 노출한다.
  → 기존 자료 구조에 새로운 함수 추가는 쉽지만, 기존 함수에 새 자료 구조 추가는 어렵다.
  → 새로운 동작이 필요하면 자료구조와 절차적 코드가 더 적합

  느낀 점

• 나중은 다시 오지 않는다. 지금 상황에서 할 수 있는 최선을 다하고, 나중에 다시 이 코드를 리팩토링해야지라는 계획을 미리 짜지는 말자.(2/21)
• 돌아가는 쓰레기와 안 돌아가는 쓰레기 중에서는 돌아가는 쓰레기가 낫겠지만, 그것에 만족하며 끝내버리지는 말자.(2/21)
• 오늘 코드를 짜면서 ‘의미 있는 이름’에 대해 다시 한번 떠올렸고, 그 생각을 반영했다. 이미 한 번 읽었던 책이지만, 역시 반복해서 적용할 수 있도록 노력해야겠다. (2/22)
• 모든 것은 선택의 문제라는 것을 다시 한번 배운다. 나쁜 코드에 주석을 달아서 당장의 문제를 해결(하는 척)하고 벗어날 것인지, 그것을 주석 없이 분명한 코드로 개선시킬지는 나의 선택에 달려있다. (2/23)
• 객체지향과 절차지향에 대해 궁금한 것이 많이 생겨서 학습 후 정리해야겠다. (3/1)