범위

• 3장. 함수

작게 만들어라!

• 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다.

한 가지만 해라!

• 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다.

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

• 함수 내 모든 문장의 추상화 수준이 동일해야 한다.

  💡 추상화 수준이란 무엇일까? 클린아키텍처에서 봤던 것 같은데 가물…. 하지만 정리해보자면 더 이상 코드로도 쪼갤 수 없을 때가 가장 낮은 추상화 단계인 듯 하다.

Switch문

• 각 switch문을 저차원 클래스에 숨기고 절대로 반복하지 않는 방법

• Factory에서만 허용해주고 나머지 switch로 분기했던 로직은 인터페이스 클래스를 선언해 각 구현체에 함수 선언을 강제하는 방법

  💡 지금 내가 딱히 enum + switch 조합을 사용해 구현한 것은 아니지만 혹여라도 밥아저씨가 제안한대로 구현했다면…. 최근 기획된 빨간 프로모션 파란 프로모션이 얼마나 아작났을지… 아니다 같은 레벨의 구현체가 아닌 상속으로 풀었으면 됐을까…? 어렵다 어려워

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

• 길고 서술적인 이름이 짧고 어려운 이름보다 좋다.

• 길고 서술적인 이름이 길고 서술적인 주석보다 좋다.

함수 인수

• 3개(삼항)는 가능한 피하는 편이 좋다.

반복하지 마라!

• 중복은 소프트웨어에서 모든 악의 근원이다.

함수를 어떻게 짜죠?

• 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다.

• 함수는 그 언어에서 동사며, 클래스는 명사다.

• 시스템은 풀어나갈 이야기다.

• 프로그래밍 언어라는 수단을 사용해 좀 더 풍부하고 좀 더 표현력이 강한 언어를 만들어 이야기를 풀어간다.

약간의 반항심..

함수인수에 대한 고민은 정말로 해본 적이 없기 때문에 신선했고 부끄러웠다. 다만 제시하는 모든 방법에 동의하지는 않는다. 저자가 말하는 것이 정답이라기 보다 취향이라고 느껴지는 부분이 있었기 때문에… 프로그래밍이 여느 글짓기와 비슷하다면 각자 문장을 해석하는 순서가 있고 취향이 있기 마련일 것이다. 개인적으로 밥아저씨가 제시한 방법은 내겐 depth가 깊어 금방 흐름을 잃어버리고 말 것 같다고 느꼈다. 특히 중복이 없는데도 추상화 레벨이 달라서 private 메소드 여러개로 쪼갠 부분은… 동의할 수 없었다. 메소드 이름이 적절히 수행기능을 설명하고 있다면 어느 정도 엇비슷한 추상화 레벨의 코드가 20줄 이하로는 있어도 되는 것 아닌가 싶다. 5줄 넘 각박…

그리고 중간중간 재컴파일/재배치에 대한 얘기가 있었는데 요새 거의 MSA로 넘어가는 추세에 엄청난 크기의 프로젝트를 일부 패치하는 곳이 많은가 싶다. (물론 우리 옆팀이 그러고는 있다만…) 만약 여건이 된다면 못쌩긴 try/catch 와 exception을 발생시켜 흐름을 끊어먹는 것보다 에러코드를 활용해 더 readable한 코드를 작성해도 되지 않을까 싶다.