스트리트 코더

1장 거리로
1.1 길거리에서 중요한 것
1.2 누가 스트리트 코더인가?
1.3 훌륭한 스트리트 코더
__1.3.1 질문하기
__1.3.2 결과 중심적
__1.3.3 높은 처리량
__1.3.4 복잡성과 모호성 수용
1.4 최근 소프트웨어 개발의 문제점
__1.4.1 너무 많은 기술
__1.4.2 패러다임의 패러글라이딩
__1.4.3 기술의 블랙박스
__1.4.4 오버헤드 과소평가
__1.4.5 내 일이 아니다
__1.4.6 시시해 보이는 일도 도움이 될 수 있다
1.5 이 책에서 다루지 않는 것
1.6 주제
1.7 요약


2장 실용적인 이론
2.1 알고리즘 특강
__2.1.1 빅오를 더 잘 이해하면 좋다
2.2 내부 데이터 구조
__2.2.1 문자열
__2.2.2 배열
__2.2.3 리스트
__2.2.4 연결 리스트
__2.2.5 큐
__2.2.6 딕셔너리
__2.2.7 해시 집합
__2.2.8 스택
__2.2.9 호출 스택
2.3 타입에 대한 과대 포장은 무엇인가?
__2.3.1 타입에 강해지기
__2.3.2 유효성 증명
__2.3.3 무조건 프레임워크를 사용하지 말고 똑똑하게 활용하라
__2.3.4 오타 이상의 타입
__2.3.5 %00;able이 아니라 non-%00;able이라 했어야 한다
__2.3.6 무료 성능 향상
__2.3.7 참조 타입 대 값 타입
2.4 요약

3장 유용한 안티패턴
3.1 깨지 않았다면 깨버려라
__3.1.1 코드 경직성에 맞서라
__3.1.2 빠르게 옮기고 깨버리자
__3.1.3 경계를 존중하라
__3.1.4 공통적인 기능을 분리하라
__3.1.5 예제 웹 페이지
__3.1.6 빚을 지지 마라
3.2 처음부터 다시 작성하라
__3.2.1 지우고 다시 써라
3.3 코드가 멈추지 않았어도 개선하자
__3.3.1 미래를 향한 경주
__3.3.2 코드를 깔끔하게 만드는 것은 작성하는 것만큼 중요하다
3.4 스스로 반복하라
__3.4.1 재사용 대 복사
3.5 지금 새로운 것을 시도하라
3.6 상속을 사용하지 마라
3.7 클래스를 사용하지 마라
__3.7.1 열거형은 맛있다!
__3.7.2 구조체는 아주 좋다!
3.8 불량 코드를 작성하라
__3.8.1 If/Else를 사용하지 마라
__3.8.2 goto를 사용하라
3.9 코드 주석을 작성하지 마라
__3.9.1 이름을 잘 선택하라
__3.9.2 함수를 활용하라
3.10 요약

4장 맛있는 테스트
4.1 테스트의 유형
__4.1.1 수동 테스트
__4.1.2 자동 테스트
__4.1.3 위험을 감수하라: 프로덕션 환경에서의 테스트
__4.1.4 적합한 테스트 방법 선택하기
4.2 걱정을 멈추고 테스트를 사랑하는 법
4.3 TDD와 같이 약어로 된 용어를 사용하지 마라
4.4 자신의 이득을 위해 테스트를 작성하라
4.5 테스트 대상 결정하기
__4.5.1 경계를 존중하라
__4.5.2 코드 커버리지
4.6 테스트를 작성하지 마라
__4.6.1 테스트를 작성하지 마라
__4.6.2 모든 테스트를 작성하려고 하지 마라
4.7 컴파일러가 코드를 테스트하도록 하라
__4.7.1 널 검사를 제거하라
__4.7.2 범위 점검을 제거하라
__4.7.3 유효 값을 확인하는 로직에서 중복을 제거하라
4.8 테스트 이름 정하기
4.9 요약

5장 보람 있는 리팩터링
5.1 우리는 왜 리팩터링을 하는가?
5.2 아키텍처 변경
__5.2.1 구성 요소를 식별하라
__5.2.2 작업량과 위험도를 추정하라
__5.2.3 평판
__5.2.4 더 쉽게 리팩터링되도록 리팩터링하라
__5.2.5 마지막 코스
5.3 신뢰할 만한 리팩터링
5.4 리팩터링을 하지 않는 경우
5.5 요약

6장 조사를 통한 보안
6.1 해커를 넘어서
6.2 위협 모델링
__6.2.1 주머니에 들어갈 만큼 작은 위협 모델
6.3 웹 앱을 안전하게 작성하라
__6.3.1 보안을 염두에 두고 설계하라
__6.3.2 은둔 보안 방식의 유용성
__6.3.3 자신만의 보안을 구현하지 마라
__6.3.4 SQL 삽입 공격
__6.3.5 XSS
__6.3.6 크로스 사이트 요청 위조(CSRF, XSRF)
6.4 첫 번째 플러드 그리기
__6.4.1 캡차를 사용하지 마라
__6.4.2 캡차의 대체 방안
__6.4.3 캐시를 구현하지 마라
6.5 암호 저장하기
__6.5.1 소스 코드에 암호를 유지하는 것
6.6 요약

7장 자기 주장이 뚜렷한 최적화
7.1 올바른 문제를 해결하라
__7.1.1 단순한 벤치마킹
__7.1.2 성능 대 응답성
7.2 완만함의 분석
7.3 최고부터 시작하라
__7.3.1 중첩 루프
__7.3.2 문자열 지향 프로그래밍
__7.3.3 2b || !2b 평가하기
7.4 병목 현상 깨뜨리기
__7.4.1 데이터를 패킹하지 마라
__7.4.2 근접성을 활용하라
__7.4.3 종속 작업을 세분화하라
__7.4.4 예측할 수 있도록 하라
__7.4.5 SIMD
7.5 1초와 0초의 I/O(입출력)
__7.5.1 I/O 속도 향상
__7.5.2 I/O를 논-블로킹(non-blocking)으로 만들라
__7.5.3 오래된 방법
__7.5.4 최신 비동기/대기
__7.5.5 비동기 I/O의 잠재적 문제
7.6 다른 모든 것이 실패할 경우, 캐시를 이용하라
7.7 요약

8장 기분 좋은 확장성
8.1 잠금을 사용하지 마라
__8.1.1 이중 점검된 잠금
8.2 불일치를 수용하라
__8.2.1 무서운 NOLOCK
8.3 데이터베이스 연결을 캐시하지 마라
__8.3.1 ORM의 형태로
8.4 스레드를 사용하지 마라
__8.4.1 비동기 코드의 주의사항
__8.4.2 비동기를 이용한 멀티스레딩
8.5 모놀리스를 존중하라
8.6 요약

9장 버그와의 동거
9.1 버그를 수정하지 마라
9.2 오류에 대한 두려움
__9.2.1 예외에 대한 진실
__9.2.2 예외를 잡아내지 마라
__9.2.3 예외 복원성
__9.2.4 트랜잭션이 없는 복원력
__9.2.5 예외와 오류
9.3 디버깅하지 마라
__9.3.1 printf() 디버깅
__9.3.2 덤프 다이빙
__9.3.3 고무 오리 디버깅
9.4 요약