티스토리 뷰
반응형
[클린코드 - http://www.yes24.com/Product/Goods/11681152]
외부 코드 사용하기
- 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓히려 애쓴다
- 사용자는 자신의 요구에 집중하는 인터페이스를 바란다
-> 이로인해 시스템 경계에서 문제가 생길 소지가 많다 - Map과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노추되지 않도록 주의한다
- Map 인스턴스를 공개 API의 인수로 넘기거나 반환값으로 사용하지 않는다
경계 살피고 익히기
- 우리의 편의를 위해 외부에서 가져온 코드를 테스트하는게 좋다
- 학습 테스트 : 곧바로 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히기
- 프로그램에서 사용하려는 방식대로 외부 API를 호출한다
- 학습 테스트는 API를 사용하려는 목적에 초점을 맞춘다
log4j 익히기
- 테스트 케이스를 먼저 작성해서 하면서 외부 코드에 대한 이해를 높인다
학습 테스트는 공짜 이상이다
- 학습 테스트는 이해도를 높여주는 정확한 실험이다
- 학습 테스트는 투자하는 노력보다 성과가 더 크다
- 학습 테스트는 패키지가 예상대로 도는지 검증한다
- 학습 테스트를 이용한 학습이 필요하든 그렇지 않든 실제 코드와 동일한 방식으로 인터페이스를 사용하는 테스트 케이스가 필요하다
- 이런 경계 테스트가 있다면 패키지의 새 버전으로 이전하기 쉬워진다
아직 존재하지 않는 코드를 사용하기
- 아는 코드와 모르는 코드를 분리하는 경계
- 우리가 바라는 인터페이스를 구현하고 외부 코드와 ADAPTER 패턴으로 연결해
API 사용을 캡슐화해서 API가 바뀔 때 수정할 코드를 한 곳으로 모으면 편리하다- 우리가 인터페이스를 전적으로 통제한다는 장점이 생긴다
깨끗한 경계
- 경계에 위차하는 코드는 깔끔히 분리한다
- 기대치를 정의하는 테스트 케이스도 작성한다
- 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자
- 새로운 클래스로 경계를 감싸거나
ADAPTER 패턴을 사용해
우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자 - 경계 인터페이스를 사용하는 일관성도 높아지며 외부 패키지가 변했을 때 변경할 코드도 줄어든다
- 새로운 클래스로 경계를 감싸거나
반응형
댓글
반응형
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- Kubernetes
- ddd
- java
- 도메인주도설계
- clean code
- gradle
- linuxkit
- IntelliJ
- docker
- springboot
- QuickTimePlayer
- 자바
- 클린코드
- k8s
- ImagePullBackOff
- kotlin
- 쿠버네티스
- JavaScript
- 도커
- kotlin In Action
- 자바스크립트
- 스프링부트
- 코틀린
- gasmask
- docker pull limit
- Spring
- 스프링
- back merge
- docker for mac
- cacheable
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
글 보관함