TIL (Today I Learned)

2022.02.22

오늘 읽은 범위

3장. 함수

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

작게 만들어라!

- 함수를 만드는 첫번째 규칙은 '작게' 둘째 규칙은 '더 작게' 

- if, else, while에 들어가는 블록은 한 줄이어야 한다

- 중첩 구조가 생길만큼 함수가 커져서는 안된다. 그러므로 함수에서 들여쓰기는 1단 or 2단 까지가 적당하다.

이래야 읽고 이해하기 쉬워진다

한 가지만 하라! 

- 함수 하나에 initializer, rendering, retrieve, post 등 온갖 기능을 넣어서 짜지 말아라 다 쪼개라 함수 하나에는 하나의 기능만 하도록 짜야한다. 그리고 그 하나의 기능만을 잘 해야한다.

- 이 함수에서 의미있는 이름으로 다른 함수를 추출할 수 있다면? 그 함수는 여러 작업을 하는 함수다

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

 - 함수 내 모든 문장의 추상화 수준은 한가지로 통일 되어야 한다. 

예를 들어 getHtml() 은 추상화 수준이 높다, string pagePathName = PathParser.render(pagepath); 는 추상화 수준이 중간이다. .append("\n")은 추상화 수준이 아주 낮다. 한 함수 내에 추상화 수준을 섞으면 읽는 사람이 헷갈린다. 한가지 수준으로 통일하라.

- 코드는 책읽듯 위에서 아래로 읽혀야 한다. 그렇게 되면 추상화 수준이 한단계씩 내려간다.

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

- 이름이 길어도 괜찮다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다.

- 이름을 정하느라 시간을 들여도 괜찮다. 서술적인 이름을 사용하면 실제로 설계가 뚜렷해져 코드 개선도 쉬워진다.

- 이름을 붙일 때는 일관성이 있어야 한다. 모듈 내에서 함수 이름은 같은 문구, 명사, 동사를 사용한다.

함수 인수

- 함수에서 이상 적인 인수는 0개, 차선은 입력인수가 한개 뿐인 경우

예를 들어 .render(pageData) 는 pageData 객체를 렌더링 하겠다는 뜻이다

명령과 조회를 분리하라!

- 함수는 수행 하거나 답하거나 둘 중 하나만 해야 한다. 예를 들어 객체 상태를 변경하거나 반환하거나 둘 중 하나 말이다.

오류 코드보다 예외를 사용하라!

- 오류 코드를 보내지 말고 예외처리를 사용하자! 

- 대표적인 예외처리 try/catch ? 추하다. 정상동작과 오류 동작을 뒤섞여있다. 별도의 함수로 뽑아내는것이 낫다.

- 오류 처리도 한 가지 작업에 속한다. 

반복하지 마라!

 - 보고서에 같은 단어나 문장이 계속 반복되면 가독성이 떨어진다, 함수에도 반복되는 알고리즘이 사용된다면? 가독성이 떨어진다. 관계형 db의 정규형식이나 객체지향 프로그래밍, 구조적 프로그래밍 모두 중복을 제거하기 위한 목적으로 만들어졌다. 

단항 형식(인수 1개) 가장 흔한 경우 두가지

  1. 인수를 체크하기 위한 경우 :  boolean fileExists("MyFile")

  2. 인수를 뭔가로 변환시켜 리턴하는 경우 : InputStream fileOpen("myFile") -> str인 myFile을 InputSteam 으로 변환한다. 

이항 함수

  쓰이긴 쓰이는데 일반적이지 않다. 인수가 두개 들어가면 이해하기도 어렵고 오류를 만들어 낼 수도 있다.

  적절한 경우도 있다. ex) point P = new Point(0, 0) 처럼 x, y 의 좌표를 찍는 경우나 assertEquals(expected, actual) 처럼 두 인수의 동일 여부를 판단 하거나 하는경우다.

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

함수는 간단하게!

긴글 읽는것을 좋아하지 않는다. 세 줄 요약 아주 좋아한다. 그래서 뭔데 라는 말이 나오는 글을 싫어한다.

함수도 똑같다. 함수 이름 하나에 기능은 하나만, 인수도 최대한 안넣을 수 있게, 함수 구성도 통일성 있게 등, 어찌보면 코드도 참 글을 쓰는 것 같다는 생각이 든다.

컴퓨터에게 쓰는 보고서 랄까..? 

함수 like 글 짓 기!

3단원의 결론이다. 코드를 작성하는 것 또한 글쓰기와 같다. 초안을 작성하고, 원하는대로 읽힐때까지 다듬고 고치고 정리한다.

이 3단원의 규칙들을 통해 시스템의 이야기를 잘 풀어내 보라고 한다.

글을 잘 쓰는 사람도 초안은 지저분 하지만, 수정하고 다시 수정해서 좋은 글을 써내듯, 개발자도 좋은 코드를 구현하기 위해 다시 수정하고 수정하라는 이야기인가... 싶다.