작게 만들어라!

• 첫째도 작게, 둘째도 작게!
• 각 함수는 명백하되 각자 이야기 하나를 표현하도록 작은 단위로 구성한다.
• 함수 내 블록은 한줄이 적당하며, 들여쓰기가 깊어질수록 코드는 길 것이고 이해하기 힘들어진다.

한가지만 해라!

• 함수는 한가지를 해야한다. 그 한가지를 잘해야한다. 그 한가지만을 해야한다.
• 우리가 함수를 만드는 이유는 큰 개념을 다음 추상화 수준에서 여러 단계로 나누어 수행하기 위해서다.
• 하나의 함수를 의미있는 이름으로 추상화할 수 있다면, 그건 여러 역할을 하고있는 함수일 것이다.

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

• 함수가 명확하게 한 가지 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야한다.
• 위에서 아래로 코드 읽기
  • 코드는 위에서 아래로 이야기처럼 읽혀야 좋다.
  • 한 함수 다음에는 추상화 수준이 한 단계 낮은 함수가 온다.

서술적인 이름을 사용하라!

• 이름이 길어도 괜찮다.
• 길고 서술적인 이름이 짧고 어려운 이름보다는 낫다.
• 이름을 정하느라 시간을 들여도 괜찮다.

함수 인수

• 이상적인 인수 개수는 0개이다.
• 인수 개수가 많아질수록, 전달할 순서를 알고있어야 한다는 불편함이 생긴다.
• 전달할 인수에 대한 이해가 필요하기 때문에 2차적인 수고가 생긴다.

부수 효과를 일으키지 마라!

• 예상치 못하게 클래스 변수를 수정하거나, 이름에 표현되지 않은 행위를 한다면, 원하지 않은 결과를 얻을 수 있다.
• 각 함수는 하나의 행동을 한다는 것에 연장선으로, 불가피 하다면 함수명에 명확히 표현하는게 좋다.

결론

프로그래머는 시스템을 구현할 프로그램이 아니라 풀어낼 이야기로 여긴다.

이 장의 결론이었다.
뭔가 오글거리는 말이지만, 생각해보지 않았던 관점이라 멋있게 느껴졌다 ㅋㅋㅋㅋㅋ
이번 장을 읽으면서, 생각보다 내가 스스로 정의하고 지켜왔던 규칙들과 비슷해서 놀랐다.
사실 일부 내용은 별로 공감가지 않아서 지킬것 같지는 않지만,
보다 구체적인 룰을 정하는데 큰 도움이 될 것 같다.