Skip to main content

챕터 템플릿

1. 📌 요약하기

가이드라인

✅ 핵심 개념 정리

각자 해당 챕터에서 중요하다고 느낀 개념이나 아이디어를 간략하게 정리하고 개선 전, 후에 대한 예시 코드를 비교하며 개념을 설명합니다.

  1. 한 줄 요약 내용
  • 개선 전
개선 전 코드

개선 전 코드의 문제점을 작성합니다.

  • 개선 후
개선 후 코드

개선 후의 코드에 대한 설명을 작성합니다.

  1. 한 줄 요약 내용
    .
    .
    .
  1. 한 줄 요약 내용
    .
    .
    .

아래는 초안 작성 예시입니다.
초안 작성 시 내용을 지우고 작성해주세요.

✅ 핵심 개념 정리

  1. 의도를 분명히 밝혀라
    좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.

    • 개선 전
    int d; // 경과 시간(단위: 날짜)

    위의 코드는 아무 의미도 드러나지 않는다. 따라서 측정값과 단위를 표현하는 이름이 필요하다.

    • 개선 후
    int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification
int fileAgeInDays;

    의도가 드러나는 이름을 사용해 코드 이해와 변경을 높일 수 있었다.

  1. 한 개념에 한 단어만 사용하자
    똑같은 기능의 메서드를 클래스마다 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. 개념 또는 원칙의 이름

    • 어려웠던 부분
      해당 개념이 헷갈리거나 명확하지 않았던 점을 구체적으로 설명합니다.
    • 궁금한 점
      해당 개념이 어떤 원리로 동작하는지, 실무에서 어떻게 활용되는지 등을 질문 형태로 정리합니다.

  2. 개념 또는 원칙의 이름
    .
    .
    .

  3. 개념 또는 원칙의 이름
    .
    .
    .

아래는 초안 작성 예시입니다.
초안 작성 시 내용을 지우고 작성해주세요.

🔍 어려웠던 개념 정리

  1. 의도를 드러내는 변수명

    • 어려웠던 부분
      • 변수명을 짧게 하면 간결하지만 의미 전달이 부족하고, 길게 하면 가독성이 떨어질 수도 있다.
      • 책에서는 "의도를 드러내라"라고 했지만, 어디까지 길게 써야 하는지 기준이 모호하다.
    • 궁금한 점
      • 변수명이 너무 길어지는 것을 방지하면서도 의미를 명확히 하는 방법이 있을까?
      • 실무에서 일반적으로 따르는 변수명 작성 규칙이 있을까?

  2. 함수(메서드) 분리 기준

    • 어려웠던 부분
      • "함수는 한 가지 일만 해야 한다"는 원칙이 있지만, 어떤 기준으로 분리해야 하는지 애매하다.
      • 너무 잘게 나누면 오히려 코드가 더 복잡해질 수도 있을 것 같다.
    • 궁금한 점
      • 좋은 함수 분리 기준을 정하는 방법이 있을까?
      • 특정 길이(예: 10줄 이하) 같은 정량적인 기준이 존재할까?

  3. 주석 대신 코드로 의도를 표현하는 방법

    • 어려웠던 부분
      • "주석을 줄이고, 코드 자체로 의미를 표현하라"는 원칙을 강조했지만, 모든 경우에 적용하기 어려워 보인다.
      • 예외 처리나 복잡한 로직을 설명할 때도 주석 없이 이해할 수 있는 코드가 가능할까?
    • 궁금한 점
      • 주석 없이도 충분히 이해할 수 있는 코드를 작성하는 실질적인 방법이 있을까?
      • 코드의 가독성을 유지하면서도 주석을 최소화할 수 있는 팁이 있을까?

3. 📚 참고 사항

가이드라인

📢 추가 자료 및 논의하고 싶은 내용

관련된 자료가 있다면 공유하고, 더 깊이 논의하고 싶은 아이디어나 의견을 정리합니다.

  1. 관련 자료 공유

    • 추가 자료
      관련 블로그 글이나 공식 문서 링크를 제공합니다.

  2. 논의하고 싶은 주제

    • 주제
      논의하고 싶은 내용을 간략히 정리합니다.
    • 설명
      논의하고 싶은 이유를 작성합니다.

아래는 초안 작성 예시입니다.
초안 작성 시 내용을 지우고 작성해주세요.

📢 추가 자료 및 논의하고 싶은 내용

  1. 관련 자료 공유

  2. 논의하고 싶은 주제

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