책 이미지
책 정보
· 분류 : 국내도서 > 컴퓨터/모바일 > 프로그래밍 언어 > 프로그래밍 언어 기타
· ISBN : 9791192987385
· 쪽수 : 696쪽
· 출판일 : 2024-02-22
책 소개
목차
옮긴이 머리말 xi
베타리더 후기 xii
추천 서문 xiii
이 책에 대하여 xv
CHAPTER 1 시작하기
1.1 러스트 툴체인 설치하기 1
1.2 프로젝트 셋업 3
1.3 IDE 4
1.4 내부 개발 루프 6
1.5 지속적인 통합 9
CHAPTER 2 이메일 뉴스레터 만들기
2.1 구현 예시 15
2.2 뉴스레터의 기능에 관하여 16
2.3 반복적으로 작업하기 18
2.4 진척 확인하기 19
CHAPTER 3 신규 구독자로 등록하기
3.1 전략 20
3.2 웹 프레임워크 선택하기 21
3.3 첫 번째 엔드포인트: 기본 헬스 체크 22
3.4 첫 번째 통합 테스트 34
3.5 첫 번째 통합 테스트 구현하기 41
3.6 다시 집중하자 50
3.7 HTML 폼 다루기 51
3.8 데이터 저장하기: 데이터베이스 66
3.9 신규 구독자 저장하기 90
3.10 테스트 업데이트하기 101
3.11 정리 108
CHAPTER 4 텔레메트리
4.1 알려지지 않은, 알려지지 않은 것들 110
4.2 관측 가능성 111
4.3 로깅 112
4.4 POST /subscriptions 측정하기 118
4.5 구조화된 로깅 125
4.6 정리 158
CHAPTER 5 프로덕션에서 구동하기
5.1 배포의 중요성 159
5.2 도구 선택하기 160
5.3 애플리케이션용 도커 파일 162
5.4 디지털오션 앱 플랫폼으로의 배포 184
CHAPTER 6 유효하지 않은 구독자 거부하기 1
6.1 요구 사항 199
6.2 첫 번째 구현 201
6.3 검증은 구멍 난 가마솥이다 203
6.4 타입 주도 개발 205
6.5 오너십과 불변량 209
6.6 패닉 216
6.7 값으로서의 오류: Result 218
6.8 통찰력 있는 어서션 오류: claim 222
6.9 단위 테스트 223
6.10 Result 다루기 226
6.11 이메일 포맷 229
6.12 SubscriberEmail 타입 230
6.13 속성 기반 테스팅 235
6.14 페이로드 검증 241
6.15 정리 248
CHAPTER 7 유효하지 않은 구독자 거부하기 2
7.1 확인 이메일 249
7.2 이메일 전달 컴포넌트: EmailClient 251
7.3 유지 가능한 테스트 스위트의 스켈레톤과 원칙 298
7.4 돌아보기 320
7.5 제로 다운타임 배포 321
7.6 데이터베이스 마이그레이션 326
7.7 확인 이메일 전송하기 331
7.8 데이터베이스 트랜잭션 365
7.9 정리 371
CHAPTER 8 오류 핸들링
8.1 오류의 목적은 무엇인가? 373
8.2 운영자를 위한 오류 핸들링 380
8.3 제어 흐름에 대한 오류 394
8.4 'Ball Of Mud' 오류 enum를 피하자 404
8.5 누가 오류를 기록해야 하는가? 412
8.6 정리 414
CHAPTER 9 단순한 뉴스레터 전달
9.1 사용자 스토리는 아직 확고하지 않다 416
9.2 확인되지 않은 구독자에게 스팸을 보내지 말자 417
9.3 확인된 모든 구독자는 새 이슈를 받는다 422
9.4 구현 전략 424
9.5 바디 스키마 425
9.6 확인된 구독자 리스트 꺼내기 428
9.7 뉴스레터 이메일 전송하기 431
9.8 저장된 데이터 검증 433
9.9 단순한 접근 방식의 한계 442
9.10 정리 444
CHAPTER 10 API 보호하기
10.1 인증 445
10.2 비밀번호 기반 인증 447
10.3 과연 안전한가? 490
10.4 인터루드: 다음 단계 494
10.5 로그인 폼 494
10.6 로그인 498
10.7 세션 548
10.8 최초 사용자 568
10.9 리팩터링 589
10.10 정리 597
CHAPTER 11 결함 감내 워크플로
11.1 POST /admin/newsletters: 리프레셔 599
11.2 우리의 목표 601
11.3 실패 모드 602
11.4 멱등성: 소개 604
11.5 테스트로서의 요구 사항 #1 608
11.6 구현 전략 609
11.7 멱등성 스토어 611
11.8 Save와 Replay 614
11.9 동시 요청 630
11.10 오류 처리하기 640
마치며 663
찾아보기 665
리뷰
책속에서
트렁크 기반 개발에서는 메인 브랜치를 언제든지 배포할 수 있어야 한다. 모든 구성원은 메인에서 브랜치를 분기할 수 있으며, 작은 기능을 개발하거나 버그를 수정하고 메인 브랜치로 병합한 후 사용자에게 릴리스한다. / 지속적인 통합은 오래된 브랜치들 때문에 일어나는 병합 충돌(merge conflict)을 줄이며, 피드백 루프를 강화한다. 선택한 접근 방식이 다른 팀의 지지를 받지 못하거나 프로젝트의 다른 부분과 잘 통합되지 않는다는 것을 아는 데 걸리는 시간을 줄인다. 또한 팀원과 협업하도록 하며 필요하다면 아무도 기분이 상하지 않게끔 경로를 수정한다.
애플리케이션에서 사용하는 모든 것은 통합 테스트에 반영되어야 한다. 특히 구조화된 로깅은 통합 테스트가 실패했을 때 디버깅의 속도를 상당히 높여준다. 디버거를 연결할 필요가 없을 수도 있고, 로그가 우리에게 무엇이 잘못되었는지 알려줄 수 있는 경우가 더 많다. 좋은 벤치마크이기도 하다. 로그를 통해 디버그할 수 없다면, 프로덕션에서 디버그를 하는 것이 얼마나 어려울지 상상해보자.
