TIL (Today I Learned)

2022.02.23

오늘 읽은 범위

3장. 함수

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

• 작게 만들어라

  1. 가로 150자를 넘어서는 안 된다. 함수는 100줄을 넘어서는 안 된다. 아니 20줄도 길다.(p.43)

• 한 가지만 해라!

  1. 함수는 한가지를 해야한다. 그 한가지를 잘 해야 한다. 그 한 가지만을 해야 한다.(p.44)

  2. 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다.(p.45)

  3. 단순히 다른 표현이 아니라 의미있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.(p.45)

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

  1. 함수가 확실히 '한 가지' 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다.(p.45)

  2. 위에서 아래로 코드 읽기: 내려가기 규칙 - 코드는 위에서 아래로 이야기처럼 읽혀야 좋다.(p.46)

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

  1. 코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다(p.49)

• 함수 인수

  1. 함수에서 이상적인 인수 개수는 0개(무항)다. 다음은 1개(단항)고, 다음은 2개(이항)다. 3개(삼항은 가능한 피하는 편이 좋다. 4개 이상(다항)은 특별한 이유가 필요하다. 특별한 이유가 있어도 사용하면 안된다.(p.50)

• 많이 쓰는 단항 형식

  1. 인수에게 질문을 던지는 경우 (p.51)

  2. 인수를 뭔가로 변환해 결과를 반환하는 경우 (p.51)

• 인수 객체

  1. 인수가 2-3개 필요하다면 일부를 독자적인 클래스 변수로 선언할 가능성을 짚어 본다.(p.53)

• 동사와 키워드

  1. 단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야 한다.(p.54)

• 명령과 조회를 분리하라!

  1. 함수는 뭔가를 수행하거나 뭔가에 답하거나 둘 중 하나만 해야한다.(p.56)

  2. 객체 상태를 변경하거나 아니면 객체 정보를 반환하거나 둘 중 하나다.(p.56)

• 대가 프로그래머는 시스템을 (구현할) 프로그램이 아니라 (풀어갈) 이야기로 여긴다. (p.62)

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

• 함수를 만들면서 이 함수의 위치는 호출하는 곳의 바로 아래가 좋을까 아님 충돌 때문에라도 뒤쪽으로 내려야 하나 하는 고민도 있었고 함수를 제일 바깥엔 흐름만 넣고 안쪽으로 타고 가면서 상세를 호출하는 식으로 구현하면 너무 잘게 쪼개는거 같아서 이게 맞나 하는 고민도 있었는데 그런 부분들이 많이 해소가 되는 챕터였다. 그리고 읽으면서 내가 잘못 만들고 있던 것들도 생각이 나서 함수를 수정해나가면서 배운걸 실천해 봐야 겠다고 생각했다.

• 시스템 전체를 이야기처럼 여기고 이야기를 풀어나가는 식으로 코드를 짠다는 말이 이 챕터에서 가장 인상적인 말이었다. 시스템의 흐름을 이해하기 좋게 이야기처럼 보이도록 깨끗하게 코드를 짜는게 이 책의 목표라는 생각이 들어서 엄청 멋지게 느껴졌다.

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

• SRP(Single Responsibility) : 객체 지향 프로그래밍에서 단일 책임 원칙이란 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 함을 일컫는다.

• OCP(Open Closed Principle) : 개방-폐쇄 원칙은 '소프트웨어 개체는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다'는 프로그래밍 원칙이다.

• AOP(Aspect Oriented Programming) : 관점 지향 프로그래밍은 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하겠다는 것이다.