챕터 템플릿

1. 📌 핵심 개념 정리

개선 전 코드

개선 후 코드

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

✅ 요약하기

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

   • 개선 전

   int d; // 경과 시간(단위: 날짜)
   

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

   • 개선 후

   int elapsedTimeInDays;
   int daysSinceCreation;
   int daysSinceModification
   int fileAgeInDays;
   

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

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

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

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

3. 📚 참고 사항

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

📢 논의하기

1. 관련 자료 공유
   • Martin Fowler의 Refactoring 가이드
   • SOLID 원칙을 활용한 리팩토링 사례

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