김시용

1. 📌 핵심 개념 정리

✅ 요약하기

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

냄새와

한휴리스틱

줄

해당 요약챕터에서는 책의 전체 내용

개선 전 코드

개선 후 코드

1. 주석
   • 부적절한 줄정보 요약: 내용
     변경 .
     이력, .
     장황한 .날짜 넣지 말기 (작성자, 최종 수정일, SPR 번호 등 메타 정보만 넣기)
   • 쓸모 없는 주석 : 재빨리 삭제하기
   • 중복된 주석 : 코드만으로 충분한데 구구절절 설명하는 주석, 함수 서명만 있는 Javadoc
   • 성의 없는 주석 : 단어를 신중하게 선택
   • 주석 처리된 코드 : 즉시 지우기 (이전 버전 소스 코드 관리 시스템이 기억함)

2. 환경 / 함수
   • 환경 - 여러 단계로 빌드 : 한 줄명령으로 전체를 체크아웃해서 한 명령으로 빌드해야 함
   • 환경 - 여러 단계로 테스트 : 모든 단위 테스트는 한 명령으로 돌려야 함
   • 함수 - 너무 많은 인수 : 인수 개순느 적을수록 좋다 (4개 이상은 그 가치가 의심스럽다)
   • 함수 - 출력 인수 : 일반적으로 인수는 입력으로 간주 (출력 인수 대신 함수가 속한 객체의 상태 변경)
   • 함수 - 플래그 인수 : boolean인수 피하기 (함수가 여러 기능 수행한다는 명백한 증거)
   • 죽은 함수 - 삭제하기

3. 일반
   • 한 소스 파일에 여러 언어 사용 : 하나의 언어만 사용 (언어 수와 범위 최소화)
   • 당연한 동작을 구현하지 않는다 : 당연하게 여길만한 동작과 기능 제공해야 함
   • 경계 올바로 처리하지 않는다 : 모든 경계 조건, 구석진 곳 직관에 의존하지 말고 찾아서 테스트하기
   • 안전 절차 무시 : 컴파일러 경고 일부 끄기, 실패하는 테스트 케이스 미뤄두기 등 하지마라
   • 중복 : DRY원칙. 중복 발견시, 제거 = 추상화, 다형성, TEMPLATE METHOD 패턴/STRATEGY 패턴
   • 추상화 수준이 올바르지 못하다 : 저차원 (상세 개념), 고차원 (일반 개념) 분리하기
     -> 기초 클래스, 파생 클래스 분리 / 소스 파일 모듈, 컴포넌트 분리
   • 기초 클래스가 파생 클래스에 의존한다 : 독립성 보장 위해 기초 클래스는 파생 클래스를 아예 몰라야 한다. 변경이 시스템에 미치는 영향이 아주 작아지므로 유지보수에 편해짐
   • 과도한 정보 : 잘 정의된 모듈은 인터페이스가 아주 작다. (변수, 함수가 적다) -> 결합도가 낮다
   • 죽은 코드 : 불가능한 조건 확인, 호출 안되는 함수 등 제거하기
   • 수직 분리 : 변수, 함수 사용되는 위치에 가깝게 정의 / 비공개 함수는 처음으로 호출한 직후에 정의
   • 일관성 부족 : '최소 놀람의 원칙' : 유사한 개념은 같은 방식으로 구현
   • 잡동사니 : 쓸데 없는 코드, 주석 제거
   • 인위적 결합 : 서로 무관한 개념 결합하지 말기 -> 함수, 상수, 변수 선언시, 위치 잘 결정하기
   • 기능 욕심 : 클래스 메서드는 다른 클래스의 변수와 함수에 관심 갖지 말기 (예외도 존재)
   • 선택자 인수 : 선택자 인수는 여러 함수를 하나로 조합함 -> 여러 함수로 쪼개서 구현
   • 모호한 의도 : 행을 바꾸지 않거나 헝가리식 표기법, 매직 번호 등 사용x
   • 잘못 지운 책임 : 코드를 배치하는 위치 (예를 들어 상수 선언 위치 -> 함수 이름 살펴보고 기능에 맞게 적절한 위치에 선언)
   • 부적절한 static 함수 : 특정 인스턴스와 관련된 기능이 아닌 함수 + 재정의 가능성이 적은 함수에 static 선언
   • 서술적 변수 : 계산을 여러 단계로 나누고 중간 값으로 서술적 변수 이름 사용하기
   • 알고리즘 이해하라 : 기능이 뻔히 보일 정도로 함수를 깔끔하고 명확하게 재구성하여 알고리즘 올바르다는 사실 확인하기
   • 논리적 의존성은 물리적으로 드러내라 : 의존하는 모듈이 상대 모듈에게 명시적으로 요약청하기
   • If/Else 혹은 Switch/Case 문보다 다형성 사용
   • 표준 표기법 사용 : 팀이 정한 표준 따르기
   • 매직 숫자는 명명된 상수로 교체 : 코드에서 숫자를 사용하지 말라 (대표적으로 의미가 나타난 숫자 빼고는 상수 선언하여 뒤에 숨기기)
   • 정확하라 : 코드에서 뭔가를 결정할 때 정확히해라 (이유, 예외 처리 방법 분명히하기)
   • 관례보다 구조 사용 : 설계 결정 -> 규칙보다 관례 사용
   • 조건 캡슐화
   • 부정 조건 피하라
   • 함수는 한 가지만 해야 한다 : 한 가지 기능만 수행하게 작게 쪼개기
   • 숨겨진 시간적인 결합 : 연결 소자를 생성해 시간적인 결합 노출하기
   • 일관성 유지하라 : 일관성이 있는 코드면 남들도 그 일관성을 따른다
   • 경게 조건 캡슐화하기 : 반복되는 경계 조건일 경우에
   • 함수는 추상화 수준을 한 단계만 내려가야 한다 : 함수 이름이 의미하는 작ㅇ업보다 한 단계만 낮아야 한다.
   • 설정 정보는 최상위 단계에 둬라
   • 추이적 탐색 피하라 : 디미터의 법칙 -> 자신이 직접 사용하는 모듈만 알아야 한다

4. 자바/이름
   
   • 자바 - 긴 import 목록 피하고 와일드카드 사용 : import package.* -> 특정 클래스 존재할 필요x, 진정한 의존성 생기는게 아니기 때문에
   • 자바 - 상수는 상속하지 않는다
   • 자바 - 상수 대 Enum : enum은 메서드 사용이 가능하고 필드로도 사용이 가능하다
   • 이름 - 서술적인 이름 사용 : 가독성의 90% 결정
   • 이름 - 적절한 추상화 수준에서 이름 선택 : 구현을 드러내는 이름 피하기.
     
   • 이름 - 가능하다면 표준 명명법 사용
   • 이름 - 명확한 이름 : 목적을 명확히 밝혀라
   • 이름 - 긴 범위는 긴 이름 사용
   • 이름 - 인코딩 피하기 : 이름에 유형 정보, 범위 정보 넣지말기
   • 이름 - 이름으로 부수 효과 설명하라 : 함수, 변수, 클래스가 하는 일을 모두 기술하라

5. 테스트
   • 불충분한 테스트 : 잠재적으로 깨질 만한 부분 모두 테스트
   • 커버리지 도구 사용
   • 사소한 테스트 건너뛰지 마라
   • 경계 조건 테스트하라
   • 버그 주변 철저히 테스트하라 : 버그는 서로 모이는 경향이 있다
   • 실패 패턴 살피라 : 합리적인 순서로 정렬된 꼼꼼한 테스트 케이스는 실패 패턴을 드러낸다
   • 테스트 커버리지 패턴 살펴라 : 통과하는 테스트가 실행하거나 실행하지 않는 코드를 살펴보면 실패하는 테스트 케이스 원인 파악 가능
   • 테스트는 빨라야 한다.
     
   .

2. 🤔 이해가 어려운 부분

🔍 질문하기

책을 읽으며 이해하기 어려웠던 개념이나 명확하지 않았던 내용을 정리합니다.

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

2. 개념 또는 원칙의 이름
   • 어려웠던 부분
     .
   • 궁금한 점
     .

3. 개념 또는 원칙의 이름
   • 어려웠던 부분
     .
   • 궁금한 점
     .

3. 📚 참고 사항

📢 논의하기

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

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

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