코딩 호러의 이펙티브 프로그래밍

▣ [1부] 들어가며

결국 프로그래머가 되고 싶은 거로군
프로그래머의 여덟 단계
쓰지 않으면서 쓰기

▣ [2부] 엉터리 같은 일을 마무리하는 기술

거대하고 끝없는 바다
톱날 갈기
저 길로 가라. 총알처럼.
멀티태스킹이라는 미신

▣ [3부] 좋은 프로그래밍의 원리

프로그래밍의 첫 번째 원리: 그것은 언제나 당신의 잘못이다.
최선의 코드는 아무 코드도 없는 것이다.
주석 없이 코딩하기
루크, 소스를 읽는 법을 배우게
고무오리 문제 해결법
아이디어가 아니라 팀을 경작하라
당신의 팀은 엘리베이터 테스트를 통과할 수 있는가?
성능은 기능이다

▣ [4부] 프로그래머를 제대로 채용하는 법

프로그래머가 어째서 프로그래밍을 못하는 걸까?
프로그래머를 채용하는 방법
전화 인터뷰로 걸러내는 과정을 올바로 수행하기
몇 년이나 경험했는가, 라는 질문에 담긴 미신
프로그래머를 대상으로 인터뷰하기
인터뷰 역사상 가장 어려운 질문

▣ [5부] 팀이 함께 일하도록 만들기

그들이 어떤 말을 하든 그것은 결국 사람과 관련된 문제다
예를 통해 리드하기
뱀파이어 프로그래머 대 베어울프 시스템 관리자
짝 프로그래밍 대 코드 리뷰
회의: 일이 죽으러 가는 장소
썩은 사과를 다루는 방법
썩은 사과: 그룹 전체의 독4
원격근무에 대해

▣ [6부] 당신의 박쥐동굴: 프로그래머를 위한 효율적인 작업 공간

프로그래머 권리 장전
컴퓨터 워크스테이션 인체공학
하나 이상의 모니터를 사용하면 생산성이 향상되는가?
품질 좋은 프로그래밍용 의자에 투자하기
배경 조명

▣ [7부] 사용자를 염두에 두고 설계하기

당신은 결코 충분한 치즈를 갖지 못할 것이다
애플리케이션은 결국, 작은 디테일의 모음이다
사용자 인터페이스가 애플리케이션이다
UI를 우선시하는 소프트웨어 개발
쪽수매기기의 종말
사용자의 좁은 시야 다루기
폴드 다시 살펴보기
피츠의 법칙과 무한한 넓이
궁극적인 단위 테스트 실패
버전 1은 엉망이야, 하지만 어쨌든 출시하라고

▣ [8부] 보안의 기초: 사용자의 데이터를 보호하라

웹 트래픽 전체를 암호화해야 하는가?
사전 공격 기초
빠른 해싱
웹 비밀번호를 둘러싼 불편한 진실

▣ [9부] 코드를 테스트해서 그것이 필요 이상으로 엉망이 되지 않게 만들기

고객의 고통을 공유하기
무질서한 원숭이와 함께 일하기
코드 리뷰: 그냥 하라
무식한 방식의 테스트
나는 단위 테스트를 작성하지 않는 바보들에게 동정을 보낸다
단위 테스트 대 베타 테스트
싸구려 사용성 테스트
크래쉬보다 더 나쁜 것은 무엇인가?

▣ [10부] 커뮤니티를 만들고, 관리하고, 커뮤니티로부터 이익 얻기

커뮤니티의 의견을 들어라, 하지만 그들이 당신이 어떻게 할지 말하게 하지 마라.
반복한다: 사용자의 말을 듣지 마라
게임화
정지, 금지 혹은 완전금지?

▣ [11부] 마케팅 사기꾼들, 그리고 어떻게 그런 사람이 되지 않을 수 있는가

마케팅 사기꾼들이 당신을 속이려고 하는 9가지 방법
인터넷 광고에서 하지 말아야 할 일
그라운드호그 데이, 혹은 A/B 테스트의 문제
기업처럼 보인다면, 그것을 변화시켜라.
소프트웨어 가격 책정: 우리는 그것을 잘못 하고 있는가?

▣ [12부] 우선순위를 제대로 관리하기

행복을 구매하기
빠르게 살고, 일찍 죽고, 지친 육신을 남기고

소프트웨어 개발자로서의 당신은, 자기 자신의 가장 큰 적이다. 이 사실을 일찍 깨달을수록 더 훌륭한 프로그래머가 될 수 있다.

물론 당신이 좋은 의도를 가지고 있다는 사실은 이해한다. 누구나 다 그렇다. 우리는 모두 소프트웨어 개발자다. 우리는 코드를 작성하는 사람들이다. 그것이 우리가 하는 일이다. 실력이 뛰어난 프로그래머인 우리는 약간의 이사용 테이프, 옷걸이, 그리고 바로 코드를 이용해서 해결할 수 없는 문제를 만난 적이 없다. 하지만 윌 쉬플리(Will Shipley)는 너무 많은 코드를 작성하고자 하는 우리의 자연스러운 내적 경향을 억제해야 한다고 주장한다.

*****

코딩의 근본적인 속성에 따르면 프로그래머인 우리가 내리는 모든 결정에는 그 자체로 장점과 단점이 동시에 포함돼 있다. 프로그래밍의 진정한 장인이 되는 길은 바로 그러한 장단점의 본질을 잘 이해하고, 우리가 작성하는 모든 코드의 구석구석에서 언제나 그러한 사실을 잊지 않는 데 있다.
코드를 평가할 때 우리가 취할 수 있는 측정 방법으로는 여러 가지가 있다.

o 코드의 간결함
o 기능의 풍부함
o 실행 속도
o 코드 작성에 걸린 시간
o 안정성
o 유연성

기억할 것은 이러한 측면들이 모두 각자 반대되는 방향으로 뻗어나간다는 사실이다. 예를 들어 당신은 정말로 아름답고 빠르게 동작하는 코드를 장장 삼일에 걸쳐 작성할 수 있다. 이 경우 두 개의 차원은 상승하는 방향으로 움직이지만, 코드를 너무 오랫동안 작성했으므로 하나의 차원은 완전히 하락하는 방향으로 움직인다.

그렇다면 어떤 상황에서 어떤 것에 가치를 둬야 할지 어떻게 알 수 있는가? 그러한 결정을 어떻게 내리는가? 이러한 질문에 대한 대답은 너무나 당연하고 간단하기 때문에 아무도 들으려고 하지 않는다. 대답은 바로 간결함에서 시작하라는 것이다. 테스트를 수행하는 과정에서 다른 차원으로 나아갈 필요가 있다고 생각되면 필요한 내용을 그때 추가해도 늦지 않다.

*****

나는 이러한 주장에 전적으로 동의한다. 개발자들에게 더 적은 코드(Code Smaller)를 작성하길 권장할 때 이와 비슷한 주장을 펼친 바 있다. 이것은 단지 코드의 물리적인 분량을 최소로 만들기 위해 우리가 아는 온갖 기법들을 총동원해야 한다는 식의, 귀류법에 대한 이야기를 하고 있는 것이 아니다. 어떤 프로그래머 개인이 읽고 이해해야 하는 프로그램 코드의 분량을 최소한으로 줄이기 위한 실질적이고 타당한 감소 전략에 대해 말하고 있는 것이다. 내가 말하고자 하는 바를 설명하기 위한 예를 살펴보자.

if (s == String.Empty) if(s == "")

이 두 if 구문 중에서 나는 두 번째 if가 더 낫다고 본다. 더 짧기 때문이다. 그렇지만 나는 String.Empty라는 장황한 표현이 컴파일러에게는 더 효율적이라는 주장에 목숨을 걸 정도로 확신하는 개발자를 만나게 되리라는 사실을 잘 알고 있다. 마치 그런 주장에 내가 관심이 있기라도 한 것처럼. 혹은 그런 주장에 관심을 갖는 사람이 마치 있기라도 한 것처럼 말이다!

그와 같은 극단적인 주장을 인정하는 것은 대부분의 프로그래머에게 괴로운 일일 것이다. 그들은 코딩이라는 행위를 너무나 사랑하기 때문이다. 하지만 최선의 코드는 아예 코드가 없는 것이다. 당신이 세상 안으로 끌어들이려고 애쓰는 코드는 모든 줄마다 반드시 디버깅해야 하고, 누군가 읽고 이해해야 하며, 유지보수해야 한다. 당신이 새로운 코드를 한 줄 작성할 때마다 이러한 일들을 반드시 수행해야 한다. 다른 선택의 여지가 없기 때문이다. 코드가 우리의 적인 이유는 결국 우리 프로그래머들이 터무니없을 정도로 많은 코드를 작성하기 때문이다. 그렇지만 아예 코드를 작성하지 않는 것은 말이 되지 않는다. 그렇다면 차선책은 바로 간결함에서 시작하는 것이다.

코드를 작성하는 것을 사랑한다면, 그러니까 진짜로 코딩을 사랑한다면 가급적 적은 분량의 코드를 작성하는 것조차 충분히 사랑할 수 있을 것이다.