[목 차]
옮긴이 머리말 xi
베타리더 후기 xii
추천 서문 xiii
이 책에 대하여 xv
CHAPTER 1 시작하기 1
1.1 러스트 툴체인 설치하기 1
1.2 프로젝트 셋업 3
1.3 IDE 4
1.4 내부 개발 루프 6
1.5 지속적인 통합 9
CHAPTER 2 이메일 뉴스레터 만들기 15
2.1 구현 예시 15
2.2 뉴스레터의 기능에 관하여 16
2.3 반복적으로 작업하기 18
2.4 진척 확인하기 19
CHAPTER 3 신규 구독자로 등록하기 20
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 텔레메트리 109
4.1 알려지지 않은, 알려지지 않은 것들 110
4.2 관측 가능성 111
4.3 로깅 112
4.4 POST /sub-scriptions 측정하기 118
4.5 구조화된 로깅 125
4.6 정리 158
CHAPTER 5 프로덕션에서 구동하기 159
5.1 배포의 중요성 159
5.2 도구 선택하기 160
5.3 애플리케이션용 도커 파일 162
5.4 디지털오션 앱 플랫폼으로의 배포 184
CHAPTER 6 유효하지 않은 구독자 거부하기 1 198
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 249
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 오류 핸들링 373
8.1 오류의 목적은 무엇인가? 373
8.2 운영자를 위한 오류 핸들링 380
8.3 제어 흐름에 대한 오류 394
8.4 'Ball Of Mud' 오류 enum를 피하자 404
8.5 누가 오류를 기록해야 하는가? 412
8.6 정리 414
CHAPTER 9 단순한 뉴스레터 전달 416
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 보호하기 445
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 결함 감내 워크플로 599
11.1 POST //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)을 줄이며, 피드백 루프를 강화한다. 선택한 접근 방식이 다른 팀의 지지를 받지 못하거나 프로젝트의 다른 부분과 잘 통합되지 않는다는 것을 아는 데 걸리는 시간을 줄인다. 또한 팀원과 협업하도록 하며 필요하다면 아무도 기분이 상하지 않게끔 경로를 수정한다. (9쪽)
애플리케이션에서 사용하는 모든 것은 통합 테스트에 반영되어야 한다. 특히 구조화된 로깅은 통합 테스트가 실패했을 때 디버깅의 속도를 상당히 높여준다. 디버거를 연결할 필요가 없을 수도 있고, 로그가 우리에게 무엇이 잘못되었는지 알려줄 수 있는 경우가 더 많다. 좋은 벤치마크이기도 하다. 로그를 통해 디버그할 수 없다면, 프로덕션에서 디버그를 하는 것이 얼마나 어려울지 상상해보자. (142쪽)
수신자 이메일 주소, 제목, 이메일 내용은 반드시 필요하다. HTML과 일반 텍스트 버전의 이메일 콘텐트를 요청할 것이다. 일부 이메일 클라이언트들은 HTML을 렌더링하지 못하며 또 어떤 사용자들은 명시적으로 HTML 이메일을 비활성화하기까지 한다. 두 개의 버전을 함께 보냄으로써 안전한 사이트에 설 수 있다. 보내는 사람의 이메일 주소는 어떻게 해야 하는가? 클라이언트 인스턴스에 의해 전송되는 모든 메일은 동일한 메일 주소로부터 전송된다고 가정한다. 따라서 발신자 이메일 주소를 send_email의 인수로 넣을 필요는 없다. 발신자 주소는 클라이언트 생성자의 인수 중 하나가 될 것이다. (254쪽)
좋은 테스트 스위트는 무엇보다 리스크 완화에 도움이 된다. 자동화된 테스트는 기존 코드베이스에 대한 변경과 관련된 리스크를 줄인다. 대부분의 재귀와 버그들은 지속적인 통합 파이프라인에서 잡히며 사용자에게 도달하지 않는다. 따라서 팀은 빠르게 반복하고 더 자주 릴리스할 수 있게 된다. / 테스트는 문서의 역할도 한다. 테스트 스위트는 알지 못하는 코드베이스에 뛰어들기 위해 좋은 시작점이다. 테스트 스위트는 코드가 어떻게 동작하기로 가정되어 있는지, 어떤 시나리오들이 전담 테스트를 가질 만큼 관련이 있는지 알려준다. (299쪽)
제어 흐름은 스크립트로 작성된다. 다음에 할 일이 무엇인지 결정하기 위해 필요한 모든 정보는 머신에 접근할 수 있어야 한다. 내부 오류를 위해서는 타입(즉, enum 변형), 메서드, 필드를 사용한다. 경계에서의 오류는 상태 코드에 의존한다. / 대신 오류 보고서는 주로 사람이 참조한다. 콘텐츠는 소비 대상에 따라 조정되어야 한다. 운영자는 시스템 내부에 접근할 수 있다. 운영자는 실패 모드에 관해 가능한 한 많은 정보를 얻을 수 있어야 한다. 사용자는 애플리케이션 경계 바깥에 앉아 있다. 사용자들은 필요한 경우 그들의 행동을 조정하는 데 있어 필요한 정도의 정보만 받아야 한다(예: 잘못된 입력을 수정한다). (379~380쪽)
세션 기반 인증은 모든 페이지마다 사용자에게 비밀번호를 요청하는 것을 피하기 위한 전략이다. 사용자는 로그인 폼을 통해 한 번만 인증을 요청받는다. 인증이 성공하면 서버는 일회성 시크릿, 즉 인증된 세션 토큰을 생성한다. 백엔드 API는 사용자 이름/비밀번호 조합 대신 세션 토큰을 받고 제한된 기능에 대한 접근을 허가한다. 이 세션 토큰은 모든 요청마다 제공되어야 한다. 그러므로 세션 토큰은 쿠키로 저장된다. 브라우저는 API로 전송되는 모든 요청에 쿠키를 붙여야 한다. (549쪽)
이 책을 읽고 어떤 느낌을 받으셨나요?
리뷰를 남기고 다른 독자들과 함께 공유해보세요.
안내 열기구매(배송/수령완료) 후 리뷰를 작성하시면 적립금 300원을 드려요!