[Book][Clean Code][TIL] 책 리뷰 03

Clean Code 클린코드 TIL(Today I Learned) 2022.02.22

📖 DAY 3

📝 오늘 읽은 범위

3장. 함수

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

• 함수를 만드는 규칙은 ‘작게!’ 다. (p.42)
• 함수는 100줄을 넘어서는 안 된다. 아니 20줄도 길다. (p.43)
• 중첩 구조가 생길만큼 함수가 커져서는 안된다.. (p.44)
• 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. (p.44)
• 함수가 확실히 ‘한 가지’ 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일 해야 한다. (p.45)
• 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. (p.46)
• 일반적으로 나는 switch 문을 단 한 번만 참아준다. 다형적 객체를 생성하는 코드 안에서다. (p.49)
• 이름이 길어도 괜찮다. 길고 서술적인 이름이 길고 서술적인 주석보다 좋다. 함수 이름을 정할 때는 여러 단어가 쉽게 읽히는 명명법을 사용한다. 그런 다음, 여러 단어를 사용해 함수 기능을 잘 표현하는 이름을 선택한다. (p.49)
• 이름을 붙일 때는 일관성이 있어야 한다. (p.50)
• 함수에서 이상적인 인수 개수는 0개(무항)다. (p.50)
• 인수가 2~3개 필요하다면 일부를 독자적인 클래스 변수로 선언할 가능성을 짚어 본다. (p.53)
• 단항 함수는 함수와 인수가 동사/명사 쌍을 이뤄야 한다. (p.54)
• 부수 효과는 시간적인 결합을 초래하고, 시간적인 결합은 결합을 초래한다. 만약 시간적인 결합이 필요하다면 함수 이름에 분명히 명시한다. (p.55)
• 일반적으로 출력 인수는 피해야 한다. (p.56)
• 명령과 조회를 분리하라! (p.56)
• Try/Catch 블록은 코드 구조에 혼란을 일으키며, 정상 동작과 오류 처리 동작을 섞는다. 그러므로 try/caatch 블록을 별도 함수로 뽑아내는 편이 좋다. (p.58)
• 중복은 문제다. 코드 길이가 늘어날 뿐 아니라 알고리즘이 변하면 네 곳이나 손봐야 하니까. 게다가 어느 한곳이라도 빠뜨리는 바람에 오류가 발생할 확률도 네 배나 높다. (.60)
• 진짜 목표는 시스템이라는 이야기를 풀어가는 데 있다. 여러분이 작성하는 함수가 분명하고 정확한 언어로 깔끔하게 같이 맞아떨어져야 이야기를 풀어가기가 쉬워진다. (p.62)

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

• 책의 코드까지 세세하게 살펴봤다. 직접 코드의 수정 전과 후를 보여줘서 이해가 더 빨리 되었다.
• 함수를 만들 때, if/else 문 남발한게 오늘 아침인 것 같은데…오늘부터는 함수를 작고 하나의 작업만 하도록 잘 구성해야겠다.
• 쓸데없는 입력 인수는 쓰지 않도록 하고 최대 1개로 구성하는 노력을 해야겠다. 이것 외에도 함수 이름, 중복 등의 문제도 신경써야겠다.
• 이 책을 읽기 전과 후의 코드의 퀄리티가 차이나도록 코드 구현 하자!!

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

• SRP (Single Responsibility Principle)

  • 단일 책임 원칙
  • 컴퓨터 프로그램의 모든 모듈, 클래스 또는 기능의 단일 부분에 대해 책임을 져야 하며 해당 부분을 캡슐화 해야 한다는 원칙
  • 해당 모듈, 클래스 또는 기능의 모든 서비스는 해당 책임과 좁게 정렬되어야 한다.

• OCP (Open Closed Principle)

  • 개방-폐쇄 원칙
  • 객체 지향 프로그래밍에서 개폐 원칙은 “소프트웨어 엔티티(클래스, 모듈, 기능 등)는 확장을 위해 열려야 하지만 수정을 위해 닫혀 있어야 한다. 즉, 이러한 엔티티는 소스 코드를 수정하지 않고 동작을 확장할 수 있다.

• 플래그 인수

  함수로 부울 값을 넘기는 것은 그 함수가 한꺼번에 여러 가지를 처리한다는 것을 말하는 것이므로 지양한다.

#코딩 #개발자 #노마드북클럽 #노개북 #clean_code