Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
[TIL] 3. 함수
#clean_code
2년 전
521


TIL (Today I Learned)

2022.02.22

오늘 읽은 범위

3장. 함수

책에서 기억하고 싶은 내용을 써보세요.

  • 어떤 프로그램이든 가장 기본적인 단위가 함수다.

  • 함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다. 함수가 얼마나 짧아야 하느냐고? 다시 말해, if문/else문/for문 등에 들어가는 블록은 한 줄이어야 한다는 의미다. 그러면 바깥을 감싸는 함수가 작아질 뿐 아니라, 블록 안에서 호출하는 함수 이름을 적절히 짓는다면, 코드를 이해하기도 쉬워진다. 이 말은 중첩 구조가 생길만큼 함수가 커져서는 안 된다는 뜻이다. 그러므로 함수에서 들여쓰기 수준은 1단이나 2단을 넘어서면 안 된다.

  • 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다. 어쨌거나 우리가 함수를 만드는 이유는 큰 개념을 (다시 말해, 함수 이름을) 다음 추상화 수준에서 여러 단계로 나눠 수행하기 위해서가 아니던가. (중략) 따라서, 함수가 '한 가지'만 하는지 판단하는 방법이 하나 더 있다. 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.

  • 서술적인 이름을 사용하라! 목록 3-7에서 나는 예제 함수 이름 testableHtml 을 SetupTeardownIncluder.render 로 변경했다. 함수가 하는 일을 좀 더 잘 표현하므로 훨씬 좋은 이름이다. 이름이 길어도 괜찮다. 겁먹을 필요없다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다. 이름을 정하느라 시간을 들여도 좋다. 이런저런 이름을 넣어 코드를 읽어보면 더 좋다. 이름을 붙일 때는 일관성이 있어야 한다. 모듈 내에서 함수 이름은 같은 문구, 명사, 동사를 사용한다.

  • 함수에서 이상적인 인수개수는 0개(무항)이다. 인수는 개념을 이해하기 어렵게 만든다. 테스트 관점에서 보면 인수는 더 어렵다. 갖가지 인수 조합으로 함수를 검증하는 테스트 케이스를 작성한다고 상상해보라! 최선은 입력 인수가 없는 경우이며, 차선은 입력 인수가 1개뿐인 경우다. SetupTeardownIncluder.render(pageData) 는 이해하기 아주 쉽다. pageData 객체 내용을 랜더링하겠다는 뜻이다.

  • 함수에 인수 1개를 넘기는 이유로 가장 흔한 경우는 두 가지다. 하나는 인수에 질문을 던지는 경우다. boolean fileExists("MyFile") 이 좋은 예다. 다른 하나는 인수를 뭔가로 변환해 결과를 반환하는 경우다. InputStream fileOpen("MyFile")은 String 형의 파일 이름을 InputStream으로 변환한다.

  • 플래그 인수는 추하다. 함수로 부울 값을 넘기는 관례는 정말로 끔찍하다. 왜냐고? 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이니까! 플래그가 참이면 이걸 하고 거짓이면 저걸 한다는 말이니까!

  • 소프트웨어를 짜는 행위는 여느 글짓기와 비슷하다. 처음에는 길고 복잡하다. 들여쓰기 단계도 많고 중복된 루프도 많다. 인수 목록도 아주 길다. 이름은 즉흥적이고 코드는 중복된다. 하지만 나는 그 서투른 코드를 빠짐없이 테스트하는 단위 테스트 케이스도 만든다. 그런 다음 나는 코드를 다듬고, 함수를 만들고, 이름을 바꾸고, 중복을 제거한다. 메서드를 줄이고, 순서를 바꾼다. 때로는 전체 클래스를 쪼개기도 한다. 이 와중에도 코드는 항상 단위 테스트를 통과한다.

  • 모든 시스템은 특정 응용 분야 시스템을 기술할 목적으로 프로그래머가 설계한 도메인 특화 언어(DSL)로 만들어진다. 함수는 그 언어에서 동사며, 클래스는 명사다. 프로그래밍의 기술은 언제나 언어 설계의 기술이다. 예전에도 그랬고 지금도 마찬가지다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

  • 항상 단위 테스트를 염두에 두고 코드를 짜는 것이 클린한 코드를 짜는 것에 도움이 될 것 같다. 이는 인수 부분을 읽으면서 한 생각이다. 단위 테스트를 짠다는 것이 나에게는 매우 생소한 것이라 지금부터 틈틈이 알아보고 작성해봐야겠다는 생각이 든다. 그리고 단위 테스트가 존재한다면 에러 잡기에도 더 수월할 것 같아 기대가 된다.

  • 이전에 나는 최대 4개의 인수를 사용하여 코드를 짠 적이 있었다. 그때는 그게 더 심플하다고 생각했었다.

  • 플래그 인수 부분 너무 웃겼다. 저자의 빡침과 진절머리남이 잘 느껴지는 파트.. 그리고 읽다 보니 나도 알겠다. 플래그 인수는 추하다!

  • 역시 함수를 만드는 일은 어렵고 아주 아주 오래 걸려서 해내야 하는 일이다. 회사에서 일하다보면 이 진실을 자꾸만 잊게 된다. (실은 아무도 재촉하지 않았음에도 불구하고) 최대한 인수를 줄이고, 1-2단 내의 들여쓰기만 허용한다는 규칙은 어느 정도의 길이가 적절한지 감이 오게 해준다. 주로 인수로 처리하여 큼지막한 함수 2-3개로 모든 기능을 끝내버렸던 내 자신을 반성하게 하는 장이었다.. 사실 방금까지도 인수 3개짜리 함수를 적다가 왔다.

  • 파이썬에서 함수를 생성하는 예약어는 def와 lambda 이다. 적어두자.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

  • 예시 코드가 자바로 작성되어 있어서 단번에 읽히지 않아 아쉬웠다. 그렇다고 자바를 공부해야겠다는 생각은 들지는 않았다..ㅎ

  • DSL 이란? Domain Specific Language란, 특정 영역을 타겟으로 하고 있는 언어를 말한다. 예를 들어 SQL이 대표적인 DSL인데 SQL은 DB의 데이터를 참조하기 위한 목적으로만 사용되며, SQL를 사용하여 웹 애플리케이션 서버를 만드는 것은 불가능하다. 반면, JAVA는 SQL도 만들어낼 수 있고, 웹 애플리케이션 서버도 만들 수 있고 그 외에도 많은 것을 할 수 있다. SQL처럼 어떤 목적이 있으며 그 목적만 달성할 수 있는 언어를 DSL이라고 한다.

  • Python 에서 단위 테스트를 구현하게 해줄 unittest 표준 라이브러리를 한번 사용해보자!

  • 매개변수와 인수 구별하기!