Skip to main content

챕터 템플릿 예시

1. 📌 요약하기

가이드라인

  • ✅

    핵심 개념 정리:

    각자 해당 챕터에서 중요하다고 느낀 개념이나 아이디어를 간략하게 정리합니다.

    하고
    • 개선
  • 전,

    후에 대한 예시 코드와 함께 작성:
    간단한 코드 예시를 통해비교하며 개념을 설명합니다.

    1. 한 줄 요약 내용
    • 개선 전
    //개선 예시:전 Clean Code에서 제시한 메서코드 분리 예시
public class Calculator {
    public int add(int a, int b) {
        // 두 수의 합을 반환
        return a + b;
    }
}

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

    • 개선 후
    개선 후 코드

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

    1. 한 줄 요약 내용
      .
      .
      .

    2. 한 줄 요약 내용
      .
      .
      .

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

    ✅ 핵심 개념 정리

    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. 📚 참고 사항

    가이드라인

    • 📢 추가 자료 및 링크:
      덧붙이논의하고 싶은 내용이나

      관련된 자료가 있다면 공유하고, 참고할더 만한 사깊이트 링크 등을 기재합니다.

    • 부연 설명:
      추가적으로 논의하고 싶은 아이디어나 의견을 정리합니다.

      1. 관련 자료 공유롭게

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

      2. 논의하고 싶은 주제

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

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

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

      1. 관련 자료 공유

      2. 논의하고 싶은 주제

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