마감일 vs 코드 품질, 무엇을 우선시할 것인가?
프로그래밍 세계의 이상과 현실 속에서 살아남기 위해 필요한 ‘길거리 지식’을 배우자!

컴퓨터 과학 이론, 알고리즘, 데이터 구조, 테스트, 코드 최적화, 리팩터링 등 코딩할 때 적용해야 하는 다양한 이론이 있다. 하지만 현실은 마감일에 쫓겨 작업의 우선순위를 정하고, 어떤 규칙을 어겨야 할지를 빠르게 결정을 내려야 하는 상황에 내몰리곤 한다. 이때 우리에게 필요한 것은 무엇이 가장 중요한지 알아차릴 수 있는 ‘길거리 지식’이다. 어떤 규칙을 깨야 하고, 어떻게 깰 수 있는지, 무엇을 우선시해야 하는지를 알고 있어야 한다. 이 책은 추상적인 이론이나 상아탑의 이데올로기처럼 뜬구름 잡는 이야기가 아닌 독학으로 마이크로소프트 엔지니어가 되기까지의 경험을 바탕으로 한 실용적인 팁과 노하우를 담고 있다. 이 책으로 다양한 개발자 생존 법칙을 배우고, 새로운 시각을 접하면서 자신만의 사각지대에서 무엇을 놓치고 있는지, 어떤 보석이 숨어 있는지도 찾아보자.

튀르키예 에스키세히르 출신이며 독학으로 소프트웨어 개발자가 되었다. 이후 워싱턴주 시애틀에 있는 마이크로소프트에서 윈도 핵심 운영 체제 부서의 엔지니어로 근무했다. 그의 소프트웨어 개발 경력은 30년에 달한다.

그는 구 유고슬라비아에서 튀르키예로 이주한 보스니아 출신 부모 사이에서 다섯 자녀 중 막내로 태어났다. ‘시큼한 사전’이라는 뜻의 세계에서 가장 인기 있는 터키어 소셜 플랫폼인 엑시 쇠즐뤽(https://eksisozluk.com)을 설립했다. 1990년대에는 코드로 생성한 그래픽이나 음악 프레젠테이션을 만들기 위한 국제 디지털 예술 커뮤니티인 튀르키예의 데모씬에서 활동했으며, 트위터(@esesci) 또는 프로그래밍 블로그(https://ssg.dev)에서 만날 수 있다.

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 요약