트렁크 기반 개발에서는 메인 브랜치를 언제든지 배포할 수 있어야 한다. 모든 구성원은 메인에서 브랜치를 분기할 수 있으며, 작은 기능을 개발하거나 버그를 수정하고 메인 브랜치로 병합한 후 사용자에게 릴리스한다. / 지속적인 통합은 오래된 브랜치들 때문에 일어나는 병합 충돌(merge conflict)을 줄이며, 피드백 루프를 강화한다. 선택한 접근 방식이 다른 팀의 지지를 받지 못하거나 프로젝트의 다른 부분과 잘 통합되지 않는다는 것을 아는 데 걸리는 시간을 줄인다. 또한 팀원과 협업하도록 하며 필요하다면 아무도 기분이 상하지 않게끔 경로를 수정한다.
--- p.9

애플리케이션에서 사용하는 모든 것은 통합 테스트에 반영되어야 한다. 특히 구조화된 로깅은 통합 테스트가 실패했을 때 디버깅의 속도를 상당히 높여준다. 디버거를 연결할 필요가 없을 수도 있고, 로그가 우리에게 무엇이 잘못되었는지 알려줄 수 있는 경우가 더 많다. 좋은 벤치마크이기도 하다. 로그를 통해 디버그할 수 없다면, 프로덕션에서 디버그를 하는 것이 얼마나 어려울지 상상해보자.
--- p.142

수신자 이메일 주소, 제목, 이메일 내용은 반드시 필요하다. HTML과 일반 텍스트 버전의 이메일 콘텐트를 요청할 것이다. 일부 이메일 클라이언트들은 HTML을 렌더링하지 못하며 또 어떤 사용자들은 명시적으로 HTML 이메일을 비활성화하기까지 한다. 두 개의 버전을 함께 보냄으로써 안전한 사이트에 설 수 있다. 보내는 사람의 이메일 주소는 어떻게 해야 하는가? 클라이언트 인스턴스에 의해 전송되는 모든 메일은 동일한 메일 주소로부터 전송된다고 가정한다. 따라서 발신자 이메일 주소를 send_email의 인수로 넣을 필요는 없다. 발신자 주소는 클라이언트 생성자의 인수 중 하나가 될 것이다.
--- p.254

좋은 테스트 스위트는 무엇보다 리스크 완화에 도움이 된다. 자동화된 테스트는 기존 코드베이스에 대한 변경과 관련된 리스크를 줄인다. 대부분의 재귀와 버그들은 지속적인 통합 파이프라인에서 잡히며 사용자에게 도달하지 않는다. 따라서 팀은 빠르게 반복하고 더 자주 릴리스할 수 있게 된다. / 테스트는 문서의 역할도 한다. 테스트 스위트는 알지 못하는 코드베이스에 뛰어들기 위해 좋은 시작점이다. 테스트 스위트는 코드가 어떻게 동작하기로 가정되어 있는지, 어떤 시나리오들이 전담 테스트를 가질 만큼 관련이 있는지 알려준다.
--- p.299

제어 흐름은 스크립트로 작성된다. 다음에 할 일이 무엇인지 결정하기 위해 필요한 모든 정보는 머신에 접근할 수 있어야 한다. 내부 오류를 위해서는 타입(즉, enum 변형), 메서드, 필드를 사용한다. 경계에서의 오류는 상태 코드에 의존한다. / 대신 오류 보고서는 주로 사람이 참조한다. 콘텐츠는 소비 대상에 따라 조정되어야 한다. 운영자는 시스템 내부에 접근할 수 있다. 운영자는 실패 모드에 관해 가능한 한 많은 정보를 얻을 수 있어야 한다. 사용자는 애플리케이션 경계 바깥에 앉아 있다. 사용자들은 필요한 경우 그들의 행동을 조정하는 데 있어 필요한 정도의 정보만 받아야 한다(예: 잘못된 입력을 수정한다).
--- p.379~380

세션 기반 인증은 모든 페이지마다 사용자에게 비밀번호를 요청하는 것을 피하기 위한 전략이다. 사용자는 로그인 폼을 통해 한 번만 인증을 요청받는다. 인증이 성공하면 서버는 일회성 시크릿, 즉 인증된 세션 토큰을 생성한다. 백엔드 API는 사용자 이름/비밀번호 조합 대신 세션 토큰을 받고 제한된 기능에 대한 접근을 허가한다. 이 세션 토큰은 모든 요청마다 제공되어야 한다. 그러므로 세션 토큰은 쿠키로 저장된다. 브라우저는 API로 전송되는 모든 요청에 쿠키를 붙여야 한다.