Skip to main content

이정우

1. 📌 핵심 개념 정리

✅ 요약하기

  1. 오류 코드보다 예외를 사용하라
    • 논리가 오류 처리 코드와 뒤섞이지 않아 호출자 코드가 더욱 깔끔해진다.
  1. Try-Catch-finally 문부터 작성하라.
    • try 블록은 트랜잭션과 비슷하다. try블록과 별개로 catch 블록은 프로그램 상태를 일관성 있게 유지해야 하기 때문.
    • try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워짐

  1. 미확인 예외를 사용하라

    • 확인된 오류가 치르는 비용에 상응하는 이익을 제공하는지 따져봐야한다.
    • 개선 전
    class Naver {
  void fetchAPI();
}

class Kakao {
  void retrieveAPI();
}

class Toss {
  void getAPI();
}

    위의 코드는 같은 역할을 하는 메서드 이름을 클래스마다 다르게 지어 어느 클래스에서 어느 이름을 썼는지 기억하기 어렵다.

    • 개선 후 -
    class Naver {
  void fetchAPI();
}

class Kakao {
  void fetchAPI();
}

class Toss {
  void fetchAPI();
}

    fetch에 대한 기능을 하는 메서드 이름을 통일시켜 기억하기 쉽게 변경했다.

  2. 한 개념에 한 단어만 사용하자
    똑같은 기능의 메서드를 클래스마다 fetch, retrieve, get과 같이 제각각 부르면 혼란스럽다.

    • 개선 전
    class Naver {
  void fetchAPI();
}

class Kakao {
  void retrieveAPI();
}

class Toss {
  void getAPI();
}

    위의 코드는 같은 역할을 하는 메서드 이름을 클래스마다 다르게 지어 어느 클래스에서 어느 이름을 썼는지 기억하기 어렵다.

    • 개선 후 -
    class Naver {
  void fetchAPI();
}

class Kakao {
  void fetchAPI();
}

class Toss {
  void fetchAPI();
}

    fetch에 대한 기능을 하는 메서드 이름을 통일시켜 기억하기 쉽게 변경했다.

2. 🤔 이해가 어려운 부분

🔍 질문하기

  1. 의도를 드러내는 변수명
    • 어려웠던 부분
      • 변수명을 짧게 하면 간결하지만 의미 전달이 부족하고, 길게 하면 가독성이 떨어질 수도 있다.
      • 책에서는 "의도를 드러내라"라고 했지만, 어디까지 길게 써야 하는지 기준이 모호하다.
    • 궁금한 점
      • 변수명이 너무 길어지는 것을 방지하면서도 의미를 명확히 하는 방법이 있을까?
      • 실무에서 일반적으로 따르는 변수명 작성 규칙이 있을까?
  1. 함수(메서드) 분리 기준
    • 어려웠던 부분
      • "함수는 한 가지 일만 해야 한다"는 원칙이 있지만, 어떤 기준으로 분리해야 하는지 애매하다.
      • 너무 잘게 나누면 오히려 코드가 더 복잡해질 수도 있을 것 같다.
    • 궁금한 점
      • 좋은 함수 분리 기준을 정하는 방법이 있을까?
      • 특정 길이(예: 10줄 이하) 같은 정량적인 기준이 존재할까?
  1. 주석 대신 코드로 의도를 표현하는 방법
    • 어려웠던 부분
      • "주석을 줄이고, 코드 자체로 의미를 표현하라"는 원칙을 강조했지만, 모든 경우에 적용하기 어려워 보인다.
      • 예외 처리나 복잡한 로직을 설명할 때도 주석 없이 이해할 수 있는 코드가 가능할까?
    • 궁금한 점
      • 주석 없이도 충분히 이해할 수 있는 코드를 작성하는 실질적인 방법이 있을까?
      • 코드의 가독성을 유지하면서도 주석을 최소화할 수 있는 팁이 있을까?

3. 📚 참고 사항

📢 논의하기

  1. 관련 자료 공유
  1. 논의하고 싶은 주제
    • 주제
      메서드는 몇 줄까지가 적당할까?
    • 설명
      • Clean Code에서는 짧을수록 좋다고 하지만 너무 잘게 쪼개면 오히려 가독성이 떨어질 수도 있다.
      • 실무에서는 어느 정도가 적절한 기준인지 논의해 보면 좋을 것 같다.
Back to top