> For the complete documentation index, see [llms.txt](https://real-dev.gitbook.io/real-library/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://real-dev.gitbook.io/real-library/clean-code/readme/3..md).

# 3.Function

별 거지같은 함수와 앵간 이해되는 함수는 들이는 노력에 비해 훨씬 큰 차이를 만들어낸다.

* 작게 만들어라! 함수를 만드는 첫째 규칙은 작게. 둘 째 규칙은 더 작게! 이다.
* 80년대에는 함수가 한 화면을 넘어가면 안되다는 규칙으로 짜여졌다.
* 함수에 포함되는 내용에 따라 다르겠지만 이 정도가 적당하다고 한다. 그리고 짧으면 짧을수록 좋다.
* 추상화 수준이 하나다? 이게 무슨 말일까

  ![Untitled](/files/fk1zd3QCsk3lxMj6euiM)

  기존에 ABC 세가지 역할을 하는 함수를 쪼개어 A, B, C로 만들었다. 이 경우 추상화 수준이 한 단계임을 의미한다. 새롭게 D라는 함수가 생성되고, A/B/C 를 호출하여 실행한다면 이 경우의 추상화 수준이 한 단계인 셈이다.
* Switch 문은 본질적으로 나쁘다. 근본적으로 하나의 함수가 길고, 하나의 조건으로 여러가지 일을 한다는 것을 **전제**하기 때문이다. 저자는 switch 문이 아예 사용되지 않을 수는 없겠지만 다형성을 객체를 생성하는 코드로 전환하여 비즈니스 로직에 미치는 영향을 최소화할 수 있다.
  * 사견이지만 이건 좀 강박적인 수준 아닌가 싶은데… 모르겠다. 아는 만큼 보이는 셈이니 나중엔 생각이 달라질지도
* 서술적인 이름을 사용하는게 낫다. 이름이 길어도 괜찮다. 짧고 어려운 이름보다 길고 쉬운 이름이 낫다. 길고 쉬운 주석보다 길고 쉬운 함수명이 낫다.
* 인수는 적을 수록 좋다. 테스트 용이성과 역할 분담 면에서 그러하다. 인수가 적을 수록 테스트하기 용이하고, 함수를 이해하기 쉬워진다.
* 인수가 2,3개로 늘어난다면 독자적인 클래스로 분리하는 것을 고려하는 것이 좋다. 무작정 늘어나는 인수보다 해당 인수들을 포함하는 객체가 더 좋을 수 있다. DTO 클래스의 사용성을 좀 더 높여도 좋을듯
* 함수는 \*\*절대로 \*\*부수 효과를 일으켜선 안 된다.

  ![Untitled](/files/PK40lq0Ev6jFJJXgs5UB)

  * 이런 식이라면 중간에 Session.initialize()는 함수명에 명시되지 않은 세션 초기화 로직을 내포한다.
* 명령과 조회 함수는 분리되어야 한다. createNewUser에서 User객체를 반환하는 것은 유저 객체 생성 + 유저 조회의 역할을 한다. 하 근데 이건 그래도 괜찮지 않나 아닌가
* 함수를 짤 때 처음부터 완벽할 수는 없다는 사실을 인지하고 있어야 한다. 하지만 개선 과정에서 함수를 쪼개고, 클래스를 만들어서 역할을 분리하고, 함수명을 바꾸기도 한다. 이 과정에서 테스트는 항상 통과하는 상태를 유지해야한다.