화요일, 4월 16, 2013

[독서광] 코딩 호러의 이펙티브 프로그래밍

위키북스에서 행운의 상자(?)를 보내주셨기에 잽싸게 개봉했는데 '코딩 호러의 이펙티브 프로그래밍'이라는 책이 들어 있었다. 코딩 호러는 젯프 앳우드가 운영하는 IT 기술 관련 블로그인데, 여기 실린 글 중에서 재미있는 내용을 선별해 책으로 묶은 형태다. IT 업계를 강타했던 '조엘 온 소프트웨어'을 시작으로 블로그를 토대로 만들어진 다양한 책이 선보였는데, 다들 '형만한 아우'가 되지 못했다. 하지만 '코딩 호러...'는 매트릭스 2편에서 네오가 에이전트 스미스를 만나 격투하는 도중 '업그레이드?'라고 외치는 장면을 연상하게 만들었다. 젯프 앳우드는 스택 오버플로우를 만들면서 겪은 다양한 경험을 재미있게 풀어쓰고 있으므로 프로그래밍, 팀 구축, 사용자 편의성, 보안, 테스트와 관련해 여러 가지 생각할 거리를 던져준다.

이 책은 블로그를 옮겨놓은 특성으로 인해 호흡이 짧지만 그렇다고 수필집처럼 마냥 빨리 페이지를 뒤적거리기는 힘들 것이다. 첫 페이지부터 끝 페이지까지 (소프트웨어 개발에 종사하는) 독자들이 처한 환경과 상황을 다시 한번 돌아보게 만드는 좋은 주제와 소재거리로 넘쳐나므로 책을 읽으면서 병렬로 문제를 풀거나 고민을 해야하기 때문이다. 예를 들어, "프로그래머를 채용하는 방법"에 나오는 전화 인터뷰에 사용할 질문을 한번 볼까?

  1. 그 자리에서 곧바로 코딩을 하는 질문 약간. 예를 들어 "배열 안에 있는 정수 값 중에서 가장 큰 값을 찾아라."
  2. 간단한 설계 약간. "HTML을 모델링하기 위한 표현 방식을 생각해보라."
  3. 스크립트 작성과 정규 표현식. "디렉터리 내에서 특정 형식의 전화번호가 저장된 텍스트 파일의 목록을 만들어보라."
  4. 자료 구조. "어떤 경우에 배열 대신 해시테이블을 사용할 것인가?"
  5. 비트와 바이트. "프로그래머에게 10월 31일과 12월 25일이 같은지 묻는 것이 왜 우스운 일인가?"

아마 열정과 호기심 넘치는 프로그래머라면 이 부분을 읽는 즉시 머리 속에서 스레드가 하나 떠서 배경 작업으로 문제를 풀고 있으리라. 10월 31일과 12월 25일 문제는 처음 봤음에도 불구하고 의도를 바로 파악하고 한참 웃었다(힌트: 각 월을 대표하는 영어 단어! 그래도 감이 안 오시는 분들은 댓글 다시면 친절하게 설명해드리겠다.).

단순히 문제 풀이에 끝나지 않고 일상에서 부딪힐만한 고민 거리도 던져준다. "그들이 어떤 말을 하든 그것은 결국 사람과 관련된 문제다"에 나오는 프로젝트 성공 유무를 예측하는 리트머스 시험지를 볼까?

  1. 당신의 팀이 얼마나 많은 줄의 코드를 작성할 것인가?
  2. 어떤 종류의 소프트웨어를 만드는가?
  3. 동료 프로그래머를 좋아하는가?

3번 '동료 프로그래머를 좋아하는가?'라는 항목에서 무릎을 탁 쳤다. 실제로 회사는 성인의 삶에 있어 가장 오랜 시간을 보내는 장소다(특히 대한민국... 음...). 그런데 배우자와 자녀보다 더 많이 시간을 같이 보내는 동료 프로그래머들과 불협화음을 만들어내고 서로 못 죽여 안 달이고 물고 뜯고 싸우는 환경에서 일이 제대로 될리 만무하다. 하지만 대부분 형편없는 아키텍쳐, 돈은 적게 주면서 최대한 많이 얻어내려고 드는 깐깐한 갑, 원저자는 어디론가 사라져서 도저히 해독 불가능한 레거시 코드, ... 등과 같은 외부 요인만 탓하며 내부 사람 문제에 대해서는 눈가리고 아웅하니 땅이 꺼지라 한숨만 나올 뿐이다.

여기서 그냥 끝내기가 너무 아쉬우므로 마지막으로 정말 뜨끔했던 예를 하나 더 소개하겠다.

(동료 프로그래머들의) 신뢰와 존경을 얻는 최선의 방법은 엄청난 노력과 실질적인 결과를 보여주는 것뿐이다. 모든 사람에게 좋은 개발 방법론을 이메일로 전송하거나, 어떤 기술을 이용하면 훌륭한 결과를 낳을 것이라는 식의 조언을 보내닌 식의 값싸고 피상적인 대체물은 동일한 결과를 낳지 못하며, 설령 그렇다고 해도 효과가 지속되지 못한다.
행동은 말보다 설득력이 있다. 팀블로그나 위키, 새로운 소스코드 관리 메커니즘, 혹은 새로운 기술에 대해 말하는 것은 값싼 일이다. 누군가 힘든 노력을 통해 그런 것들을 실제로 구현했을 때 당신은 그저 그 아이디어에 대한 소유권을 주장하려고 하고 있을 뿐이라는 사실을 다른 사람들은 이미 잘 알고 있다. 뭔가를 제안하고자 한다면 제안을 뒷받침하는 노력을 실제로 기울려야 한다.

어디서나 마찬가지지만 지행합일: 아니 말보다 행동이다!

요약: 2013년 상반기 현재 가장 눈에 띄는 추천 서적으로 평가한다!

EOB

댓글 4개:

  1. 오!!! 꼭 봐야 겠네요.
    언제나 좋은 책 추천 감사합니다. :)

    답글삭제
  2. // whiterock님

    성원 늘 감사드립니다. ;)

    - jrogue

    답글삭제
  3. 하필 Oct 31와 Dec 25인가 했더니 할로윈데이와 성탄절을 엮어 이중으로 비튼 긱스러운 농담이었군요 ㅋ ( 전 역시나 한 번에 눈치 채지 못하고 ... )

    답글삭제
  4. // tzara님

    변종 문제: "Why do programmers confuse Halloween and Christmas?"

    서양 친구들 긱스러움은 짱구도 손발 다 든다니까요. ㅋㅋ

    - jrogue

    답글삭제