김시용
1. 📌 핵심 개념 정리
✅ 요약하기
각자 해당 챕터에서 중요하다고 느낀 개념이나 아이디어를 간략하게 정리하고 개선 전, 후에 대한 예시 코드를 비교하며 개념을 설명합니다.
냄새와 휴리스틱
해당 챕터에서는 책의 전체 내용을 정리하는 느낌으로 아래와 같은 내용들을 설명과 간단한 예시들을 들어 설명해준다.
- 냄새 : 코드에 문제가 있음을 나타내는 경고 신호. 버그는 아니지만, 유지보수성, 가독성, 확장성에 악영향을 미침.
- 휴리스틱 : 코드를 개선할 때 참고할 수 있는 실용적 원칙. 엄밀한 법칙은 아니지만, 경험적으로 유용하며 좋은 설계로 가는 길잡이 역할.
- 주석
- 부적절한 정보 : 변경 이력, 장황한 날짜 넣지 말기 (작성자, 최종 수정일, SPR 번호 등 메타 정보만 넣기)
- 쓸모 없는 주석 : 재빨리 삭제하기
- 중복된 주석 : 코드만으로 충분한데 구구절절 설명하는 주석, 함수 서명만 있는 Javadoc
- 성의 없는 주석 : 단어를 신중하게 선택
- 주석 처리된 코드 : 즉시 지우기 (이전 버전 소스 코드 관리 시스템이 기억함)
- 환경 / 함수
- 환경 - 여러 단계로 빌드 : 한 명령으로 전체를 체크아웃해서 한 명령으로 빌드해야 함
- 환경 - 여러 단계로 테스트 : 모든 단위 테스트는 한 명령으로 돌려야 함
- 함수 - 너무 많은 인수 : 인수 개순느 적을수록 좋다 (4개 이상은 그 가치가 의심스럽다)
- 함수 - 출력 인수 : 일반적으로 인수는 입력으로 간주 (출력 인수 대신 함수가 속한 객체의 상태 변경)
- 함수 - 플래그 인수 : boolean인수 피하기 (함수가 여러 기능 수행한다는 명백한 증거)
- 죽은 함수 - 삭제하기
- 일반
- 한 소스 파일에 여러 언어 사용 : 하나의 언어만 사용 (언어 수와 범위 최소화)
- 당연한 동작을 구현하지 않는다 : 당연하게 여길만한 동작과 기능 제공해야 함
- 경계 올바로 처리하지 않는다 : 모든 경계 조건, 구석진 곳 직관에 의존하지 말고 찾아서 테스트하기
- 안전 절차 무시 : 컴파일러 경고 일부 끄기, 실패하는 테스트 케이스 미뤄두기 등 하지마라
- 중복 : DRY원칙. 중복 발견시, 제거 = 추상화, 다형성, TEMPLATE METHOD 패턴/STRATEGY 패턴
- 추상화 수준이 올바르지 못하다 : 저차원 (상세 개념), 고차원 (일반 개념) 분리하기
-> 기초 클래스, 파생 클래스 분리 / 소스 파일 모듈, 컴포넌트 분리 - 기초 클래스가 파생 클래스에 의존한다 : 독립성 보장 위해 기초 클래스는 파생 클래스를 아예 몰라야 한다. 변경이 시스템에 미치는 영향이 아주 작아지므로 유지보수에 편해짐
- 과도한 정보 : 잘 정의된 모듈은 인터페이스가 아주 작다. (변수, 함수가 적다) -> 결합도가 낮다
- 죽은 코드 : 불가능한 조건 확인, 호출 안되는 함수 등 제거하기
- 수직 분리 : 변수, 함수 사용되는 위치에 가깝게 정의 / 비공개 함수는 처음으로 호출한 직후에 정의
- 일관성 부족 : '최소 놀람의 원칙' : 유사한 개념은 같은 방식으로 구현
- 잡동사니 : 쓸데 없는 코드, 주석 제거
- 인위적 결합 : 서로 무관한 개념 결합하지 말기 -> 함수, 상수, 변수 선언시, 위치 잘 결정하기
- 기능 욕심 : 클래스 메서드는 다른 클래스의 변수와 함수에 관심 갖지 말기 (예외도 존재)
- 선택자 인수 : 선택자 인수는 여러 함수를 하나로 조합함 -> 여러 함수로 쪼개서 구현
- 모호한 의도 : 행을 바꾸지 않거나 헝가리식 표기법, 매직 번호 등 사용x
- 잘못 지운 책임 : 코드를 배치하는 위치 (예를 들어 상수 선언 위치 -> 함수 이름 살펴보고 기능에 맞게 적절한 위치에 선언)
- 부적절한 static 함수 : 특정 인스턴스와 관련된 기능이 아닌 함수 + 재정의 가능성이 적은 함수에 static 선언
- 서술적 변수 : 계산을 여러 단계로 나누고 중간 값으로 서술적 변수 이름 사용하기
- 알고리즘 이해하라 : 기능이 뻔히 보일 정도로 함수를 깔끔하고 명확하게 재구성하여 알고리즘 올바르다는 사실 확인하기
- 논리적 의존성은 물리적으로 드러내라 : 의존하는 모듈이 상대 모듈에게 명시적으로 요청하기
- If/Else 혹은 Switch/Case 문보다 다형성 사용
- 표준 표기법 사용 : 팀이 정한 표준 따르기
- 매직 숫자는 명명된 상수로 교체 : 코드에서 숫자를 사용하지 말라 (대표적으로 의미가 나타난 숫자 빼고는 상수 선언하여 뒤에 숨기기)
- 정확하라 : 코드에서 뭔가를 결정할 때 정확히해라 (이유, 예외 처리 방법 분명히하기)
- 관례보다 구조 사용 : 설계 결정 -> 규칙보다 관례 사용
- 조건 캡슐화
- 부정 조건 피하라
- 함수는 한 가지만 해야 한다 : 한 가지 기능만 수행하게 작게 쪼개기
- 숨겨진 시간적인 결합 : 연결 소자를 생성해 시간적인 결합 노출하기
- 일관성 유지하라 : 일관성이 있는 코드면 남들도 그 일관성을 따른다
- 경게 조건 캡슐화하기 : 반복되는 경계 조건일 경우에
- 함수는 추상화 수준을 한 단계만 내려가야 한다 : 함수 이름이 의미하는 작ㅇ업보다 한 단계만 낮아야 한다.
- 설정 정보는 최상위 단계에 둬라
- 추이적 탐색 피하라 : 디미터의 법칙 -> 자신이 직접 사용하는 모듈만 알아야 한다
- 자바/이름
- 자바 - 긴 import 목록 피하고 와일드카드 사용 :
import package.*-> 특정 클래스 존재할 필요x, 진정한 의존성 생기는게 아니기 때문에 - 자바 - 상수는 상속하지 않는다
- 자바 - 상수 대 Enum : enum은 메서드 사용이 가능하고 필드로도 사용이 가능하다
- 이름 - 서술적인 이름 사용 : 가독성의 90% 결정
- 이름 - 적절한 추상화 수준에서 이름 선택 : 구현을 드러내는 이름 피하기.
- 이름 - 가능하다면 표준 명명법 사용
- 이름 - 명확한 이름 : 목적을 명확히 밝혀라
- 이름 - 긴 범위는 긴 이름 사용
- 이름 - 인코딩 피하기 : 이름에 유형 정보, 범위 정보 넣지말기
- 이름 - 이름으로 부수 효과 설명하라 : 함수, 변수, 클래스가 하는 일을 모두 기술하라
- 자바 - 긴 import 목록 피하고 와일드카드 사용 :
- 테스트
- 불충분한 테스트 : 잠재적으로 깨질 만한 부분 모두 테스트
- 커버리지 도구 사용
- 사소한 테스트 건너뛰지 마라
- 경계 조건 테스트하라
- 버그 주변 철저히 테스트하라 : 버그는 서로 모이는 경향이 있다
- 실패 패턴 살피라 : 합리적인 순서로 정렬된 꼼꼼한 테스트 케이스는 실패 패턴을 드러낸다
- 테스트 커버리지 패턴 살펴라 : 통과하는 테스트가 실행하거나 실행하지 않는 코드를 살펴보면 실패하는 테스트 케이스 원인 파악 가능
- 테스트는 빨라야 한다.
2. 🤔 이해가 어려운 부분
🔍 질문하기
책을 읽으며 이해하기 어려웠던 개념이나 명확하지 않았던 내용을 정리합니다.
- 개념 또는 원칙의 이름
- 어려웠던 부분
해당 개념이 헷갈리거나 명확하지 않았던 점을 구체적으로 설명합니다. - 궁금한 점
해당 개념이 어떤 원리로 동작하는지, 실무에서 어떻게 활용되는지 등을 질문 형태로 정리합니다.
- 어려웠던 부분
- 개념 또는 원칙의 이름
- 어려웠던 부분
. - 궁금한 점
.
- 어려웠던 부분
- 개념 또는 원칙의 이름
- 어려웠던 부분
. - 궁금한 점
.
- 어려웠던 부분
3. 📚 참고 사항
📢 논의하기
관련된 자료가 있다면 공유하고, 더 깊이 논의하고 싶은 아이디어나 의견을 정리합니다.
- 관련 자료 공유
- 추가 자료
관련 블로그 글이나 공식 문서 링크를 제공합니다.
- 추가 자료
- 논의하고 싶은 주제
- 주제
논의하고 싶은 내용을 간략히 정리합니다. - 설명
논의하고 싶은 이유를 작성합니다.
- 주제
No Comments