[클린코드] 3. 함수

읽은 날짜 : 2024.08.26
지은이 : 로버트 C. 마틴
출판사 : 인사이트

 

✔️ 기억하고 싶은 내용

의도를 분명히 표현하는 함수를 만드는 방법

1. 작게 만들어라

• 길이가 짧을수록 좋다.

2. 한 가지 일만 해라

• 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다.

3. 하나의 함수 내의 추상화 수준을 동일하게 만들어라

• 코드는 위에서 아래로 이야기처럼 읽혀야 한다.
• 위에서 아래로 읽을 때 추상화 수준이 한 번에 한 단계씩 낮아지면 읽기 쉬워진다.

4. Switch 문을 추상 팩토리에 숨겨라

• 각 case 조건에 대한 구현을 캡슐화하고, 이를 추상 팩토리를 사용하여 동적으로 선택할 수 있도록 한다.

5. 서술적인 이름을 사용해라

• 길고 서술적인 이름이 짧고 어려운 이름보다 좋다.
• 서술적인 이름을 사용하면 개발자 머릿속에서도 설계가 뚜렷해지므로 코드를 개선하기 쉬워진다.

6. 이상적인 함수 매개변수의 개수는 2개 이하 [참고]

• 매개변수로 플래그를 사용하지 말자.
  • 플래그를 사용하는 것 자체가 함수가 한 가지 이상의 역할을 하고 있다는 뜻이다.
  • boolean 기반으로 함수가 실행되는 코드가 나뉜다면 함수를 분리하자.
• 매개변수가 2~3개 필요하다면 클래스 변수로 선언해 개념을 묶는다.

Circle makeCircle(double x, double y, double radius);
Circle makeCircle(Pointer center, double radius);

• 매개변수가 1개인 함수는 함수와 매개변수가 동사-명사 쌍을 이루면 이해하기 쉽다.
  • write(name) ➡️ writeField(name)
• 함수 이름에 매개변수 이름을 넣으면 매개변수 순서를 기억하지 않아도 돼서 이해하기 쉽다.
  • assertEquals(expected, actual) ➡️ assertExpectedEqualsActual(expected, actual)

7. 부수 효과를 조심해라

• 예측 가능하고, 외부 상태에 의존하지 않도록 하기 위해 다음을 조심하자. [참고1] [참고2]
  • 함수로 넘어온 매개변수를 수정하지 않는다.
  • 함수 내부에서 전역 변수를 수정하지 않는다.

// Bad
const addItemToCart = (cart, item) => {
  cart.push({ item, date: Date.now() });
};

// Good
const addItemToCart = (cart, item) => {
  return [...cart, { item, date : Date.now() }];
};

• 특정 상황에서만 호출하게 되지 않도록 한 가지 일만 수행하게 한다.
  • 예를 들어 checkPassword()라는 함수가 있다면, 사용자의 비밀번호를 확인하고 true/false를 반환할 것을 기대한다.
  • 이외에 비밀번호가 유효한 경우 세션을 초기화하는 코드가 포함되어 있다면, 이름만 보고 호출했을 때 세션 초기화에 대한 부수 효과가 발생한다.

8. 명령과 조회를 분리하라

• 함수는 상태를 변경하거나 정보를 반환하거나 둘 중 하나만 해야 한다.

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

• 오류 코드를 반환하면 호출자는 오류 코드를 곧바로 처리해야 한다는 문제가 있다.
• 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리될 수 있다.
• 그러나 try/catch 블록은 정상 동작과 오류 처리를 뒤섞는다. 별도의 함수로 추출하면 가독성이 올라간다.
• 오류 처리도 한 가지 작업만 해야 한다.

// Bad ❌
if (deletePage(page) == E_OK) {
  if (registry.deleteReference(page.name) == E_OK) {
    if (configKeys.deleteKey(page.name.makeKey()) == E_OK) {
      logger.log("page deleted");
    } else {
      logger.log("configKey not deleted");
    }
  } else {
    logger.log("deleteReference from registry failed");
  }
} else {
  logger.log("delete failed");
  return E_ERROR;
}

// Good ✅
try {
  deletePageAndAllReferences(page);
}
catch (Exception e) {
  logError(e)
}

private void deletePageAndAllReferences(Page page) throws Exception {
  deletePage(page);
  registry.deleteReference(page.name);
  configKey.deleteKey(page.name.makeKey());
}

private void logError(Exception e) {
  logger.log(e.getMessage());
}

 

✔️ 오늘 읽은 소감

'진짜 목표는 시스템이라는 이야기를 풀어나가는 데 있다'는 말이 크게 와닿았다. 

위에서 아래로 이야기처럼 읽히면서, 한 가지 일을 잘 해내는 함수를 작성하는 것이 중요하다는 것을 알게 되었다. 

또한, 당장 함수를 다 분리해내지 못하더라도, 이름을 의미있게 짓고 함수의 크기를 작게 만드려고 하다보면 가독성은 저절로 올라간다는 점을 이해하게 되었다.

 

✔️ 궁금한 내용 & 잘 이해되지 않는 내용

SRP(Single Responsibility Principle)

• "한 가지 이유로만 변경되어야 한다."
  • 클래스나 모듈은 단 하나의 변경 이유만을 가져야 합니다. 즉, 클래스가 변경되어야 하는 이유는 딱 하나여야 한다.
  • 책임은 '왜 변경되는가'에 따라 구분되어야 하며, 변경되는 이유가 여러 개라면 클래스가 여러 개의 책임을 가지고 있다고 판단한다.

OCP(Open-Closed Principle)

• "소프트웨어의 확장에는 열려 있고, 수정에는 폐쇄적이어야 한다."
  • 새로운 기능이나 동작을 추가할 때에는 기존 코드를 변경하지 않고 확장할 수 있어야 한다. 모듈이나 클래스는 새로운 요구사항이나 기능이 추가될 때에 대응하여 확장 가능해야 한다.
  • OCP는 주로 다형성을 활용하여 달성됩니다. 즉, 인터페이스와 추상화를 통해 새로운 기능을 추가하거나 변경할 수 있도록 설계되어야 한다.

추상 팩토리

• 객체 생성에 관련된 인터페이스를 이용하여 여러 종류의 연관된 객체를 생성할 수 있도록 하는 디자인 패턴. 구체적인 클래스의 인스턴스를 생성하는 것이 아니라, 관련된 여러 종류의 객체들을 생성하기 위한 인터페이스를 만드는 것이다.
• 언제 사용할까?
  • 여러 종류의 연관된 객체를 생성해야 할 때
  • 객체의 생성과 조립이 서로 관련되어 있을 때
• 구성 요소
  • AbstractFactory : 객체 생성에 관련된 인터페이스를 정의한다. 일반적으로는 여러 종류의 "생성 메서드"를 제공한다.
  • ConcreteFactory : AbstractFactory를 구현한 클래스. 특정한 종류의 객체를 생성하는 책임이 있다.
  • AbstractProduct : 생성되는 객체들에 대한 인터페이스를 정의한다. 여러 종류의 제품에 대한 공통의 인터페이스를 제공한다.
  • ConcreteProduct : AbstractProduct를 구현한 클래스. 구체적인 객체의 생성과 구현을 담당한다.
  • Client : 추상 팩토리를 이용하여 객체를 생성하고 사용하는 클라이언트 코드. 클라이언트는 구체적인 팩토리와 제품 클래스를 몰라도 된다.

명령 / 조회 분리(Command Query Separation, CQS)

• 함수는 명령(command) 또는 조회(query) 중 하나만 수행해야 한다는 원칙.
• command는 시스템의 상태를 변경하는 작업을 수행하고, query는 시스템의 상태를 읽고 반환하는 작업을 수행한다.
• 함수의 의도가 명확해지므로 가독성은 올라가지만, 작은 규모의 프로그램에서는 오버 엔지니어링이 될 수 있다.
• CQS(Command Query Separation) vs CQRS(Command Query Responsibility Segregation)
  • CQS는 함수 레벨에서 적용하는 원칙이고, CQRS는 시스템 차원에서 명령과 조회를 분리하는 아키텍처를 의미한다.
  • 둘 다 작은 규모의 프로그램, 시스템에서 오버엔지니어링이 될 수 있다.

AOP(Aspect Oriented Programming)

• 코드의 횡단 관심사(cross-cutting concerns)를 모듈화하고 분리하기 위한 프로그래밍 패러다임 중 하나이다.
• 횡단 관심사는 여러 모듈이나 클래스에 영향을 미치는 공통적인 부분(e.g. 로깅, 보안, 트랜잭션 관리 등)을 말한다.
• Spring에서는 AOP, AspectJ 등의 AOP 프레임워크가 있고, NestJS에서는 Interceptor, Custom Decorator 등이 있다.
• 클린 코드 책에서는 중복을 없애기 위한 방법 중 하나로 언급되었다.

COP(Component Oriented Programming)

• 소프트웨어를 구성하는 주요 단위를 "컴포넌트"로 보고, 이러한 컴포넌트들을 조립하여 전체 소프트웨어를 구축하는 프로그래밍 패러다임이다.
• 각각의 컴포넌트는 재사용 가능하고 독립적으로 개발될 수 있는 단위이다.

 

✔️ 참고

clean-code-javascript

💠 추상 팩토리(Abstract Factory) 패턴 - 완벽 마스터하기

명령-조회-분리(CQS)- 간단하고 강력한 디자인 패턴