Season 2 Day 4 (2020.12.26)
모임날짜: 2020-12-26(토)
참여자:강인한, 김근욱, 최승연, 한승엽
주제: 주석 (클린 코드 4장) / 개발 구조 및 회원가입 모듈 개발에 대한 토의
1.1 좋은 주석
1.2 나쁜 주석
나쁜 코드에 주석을 달지 마라. 새로 짜라.
-브라이언 w.커니핸, p.j. 플라우거
주석을 다는 이유: 코드로 의도를 표현하는 것에 실패하기 때문에. 주의해야할 것: 주석은 코드를 따라가지 않음. 따라서 주석을 달지 않아도 쉽게 이해되는 코드 작성을 목표로 하기 명심해야할 것: 주석은 나쁜 코드를 보완하지 못함. 주석을 달기 보다 코드 보완에 신경 쓰기
- 가능한 주석을 줄이도록 노력해야 함
- 함수나 변수로 표현할 수 있다면 주석을 달지 말 것
- 그냥 주석을 달아야한다는 맹목적인 생각에서 벗어날 것
- 네이밍을 잘하면 주석이 필요 없음
if(employee.isEligibleForFullBenefits())
vs
//직원에게 복지 혜택을 받을 자격이 있는지 검사한다.
if ((employee.flags && HOURLY_FLAG) && (employee.age>65))결론: 가능한 주석을 줄이도록 노력해야 함
1.1 좋은 주석
| 내용 | 예시 |
|---|---|
| 꼭 넣어야하는 주석 | 법적인 이유로 넣어야 할 것 |
| 정보를 제공하는 주석 | 반환값에 대한 설명, 정규식을 쓸 경우 그 예시 |
| 의도를 설명하는 주석 | for문으로 thread를 대량 생산했다면 그 이유에 대한 서술 |
| 의미를 명료하게 밝히는 주석 | 테스트코드에서 assertTrue가 어떤 상황을 검사하고 있는지에 대한 서술 |
| 결과를 경고하는 주석 | 실행시간이 오래걸린다 등의 기록 |
| TODO 주석 | 필요하다 여기지만 당장 구현하기 어려운 업무 기술 그렇다고 나쁜 코드를 남겨놓는 핑계가 되어서는 안됨! 주기적으로 검사해서 TODO 주석 점검 |
| 중요성을 강조하는 주석 | - |
| 공개API에서 Javadocs | - |
1.2 나쁜 주석
| 내용 | 예시 |
|---|---|
| 주절거리는 주석 | 이 주석을 이해하기 위해 다른 코드를 뒤적거려야 할 때 |
| 같은 이야기를 중복하는 주석 | 주석이 코드 내용을 보충하는 것도 아니고, 오히려 코드 읽는걸 귀찮게 만듬 이건 영어권의 시각임. 우리 입장에서는 번역이라 편의성 증가 |
| 오해할 여지가 있는 주석 | 코드 내용과 다른 주석 |
| 의무적으로 다는 주석 | 모든 함수의 모든 파라미터마다 설명을 달아두는 것 |
| 이력을 기록하는 주석 | 관례였으나 ,이젠 깃허브 같은 것들이 대신 해줌 |
| 있으나 마나한 주석 | 너무나도 당연한 사실을 기술 ex. //기본 생성자 |
| 닫는 괄호에 다는 주석 | 중첩이 심하면 필요하겠지만, 너무 복잡해질 경우 함수를 나누는 것을 고려해야 함 |
| 주석으로 처리한 코드 | 깃허브가 대신 기억해주니 지워도 됨 |
| 멀리있는 코드에 대한 주석 | 이 코드가 하는 역할에 대해서만 한정지어서 기술해야 함 |
| 모호한 관계 | (주석) 과 (주석이 설명하는 코드)와의 관계는 명백해야 함. 숫자값이 나오면 그 값이 어떤 의미인지 주석에 명시되어 있어야함 |
- DDD 기반으로 진행
- 객체 간 의존성을 줄이고, 책임을 다할 것
└── src
├── main
│ ├── java
│ │ └── com
│ │ └── example
│ │ └── demo
│ │ ├── DemoApplication.java
│ │ ├── customer
│ │ │ ├── controller
│ │ │ ├── domain // entity, repository, dto, vo
│ │ │ ├── exception
│ │ │ └── service
│ │ └── seller
│ │ | ├── controller
│ │ | ├── domain
│ │ | ├── exception
│ │ | └── service
| | └── global
│ │ └── exception
│ └── resources
│ └── application.properties
