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

스택오버플로우 공동 창립자가 알려주는 소프트웨어 개발의 비밀

코딩 호러 블로그의 운영자이자 스택 오버플로우 공동 창업자가 알려주는 소프트웨어 개발의 비밀!

소프트웨어 개발 분야에서 가장 영향력 있는 블로그를 손에 꼽으라면 분명 코딩 호러(http://www.codinghorror.com)가 포함될 것이다. 코딩 호러는 하루 약 100,000명이 방문하는 블로그로서, 소프트웨어 개발과 관한 참신하고 독특한 식견과 재치 있는 입담으로 정평이 나 있다. 더불어 코딩 호러 운영자가 만든 스택 오버플로우(http://stackoverflow.com/)는 소프트웨어 개발 과정에서 문제가 생기거나 궁금한 점이 있으면 언제든지 달려가서 조언을 구할 수 있는 곳으로서, 자신의 소프트웨어 개발 능력을 한 단계 향상시킬 기회가 무궁무진한 곳이다.

이 책에서는 이 두 사이트를 탄생시킨 저자의 소프트웨어 개발과 관련된 지혜와 조언이 가감 없이 담겨 있다. 저자가 전해주는 소프트웨어 개발에 관한 깊이 있는 연구 내용과 조언들은 비단 프로그래머뿐 아니라 소프트웨어 개발을 둘러싼 이해관계자에게 모두 도움될 것이다. 그동안 코딩 호러에 실린 글 중에서 엄선한 글만 실린 이 책은 소프트웨어 개발에 관한 저자의 통찰력과 실질적인 조언을 통해 여러분의 소프트웨어 개발 프로젝트가 성공하기 위한 밑거름이 되어 줄 것이다.

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

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

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

코드를 평가할 때 우리가 취할 수 있는 측정 방법으로는 여러 가지가 있다.

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

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

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

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

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

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

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

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

제프 앳우드(Jeff Atwood)

제프 앳우드는 캘리포니아 버클리에서 아내, 두 마리 고양이, 세 명의 아이들, 그리고 여러 대의 컴퓨터와 함께 살고 있다. 그는 80년대 자신의 첫 번째 마이크로컴퓨터였던 텍사스 인스트루먼트의 TI-99/4a를 이용해 다양한 마이크로소프트 베이직 프로그램을 구현하면서 소프트웨어 개발자의 길을 걷기 시작했다. 90년대 초반까지 계속 PC상에서 비주얼 베이직 3.0과 윈도우 3.1을 사용했고, 델파이의 최초 버전을 이용해 파스칼 코드도 많이 작성했다. 현재는 대소문자에 민감한 사악한 속성에도 불구하고 VB.NET 혹은 C# 프로그래밍에 익숙하다. 지금은 루비를 배우고 있다.

앳우드는 개발자가 읽어야 할 도서 목록에서 밝힌 것처럼 스스로를 소프트웨어 개발 과정에 존재하는 인간적인 측면에 특별히 관심이 있는, 상당히 경험이 풍부한 윈도웹(Windowsweb) 소프트웨어 개발자라고 생각한다. 그가 주장하는 바에 따르면 컴퓨터는 놀라운 기계이지만 사실상 그것을 사용하는 사람을 단순히 반영하는 기계에 불과하며, 소프트웨어 개발의 기술적인 측면은 코드를 학습하는 것만으로는 충족되지 않고 소프트웨어의 배후에 존재하는 사람도 함께 연구해야 한다.

임백준([email protected])

서울대학교에서 수학을 전공하고, 인디애나 주립대학에서 컴퓨터 사이언스를 공부했다. 삼성SDS, 뉴저지 소재 루슨트테크놀로지스에서 근무했고, 지금은 월스트리트에서 금융 소프트웨어를 개발하고 있다. 뉴저지에서 아내와 두 딸과 함께 살고 있다. 《누워서 읽는 퍼즐북》(2010), <프로그래밍은 상상이다》(2008), 《뉴욕의 프로그래머》(2007), 《소프트웨어 산책》(2005), 《나는 프로그래머다》(2004), 《누워서 읽는 알고리즘》(2003), 《행복한 프로그래밍》(2003, 이상 한빛미디어), 《프로그래머 그 다음 이야기》(2011, 로드북)을 집필했고, 다수의 책을 번역했다.

  • 107쪽, 밑에서 11번째 줄

    능숙하지(그리고 어떤 일에 서툰지)

    ==>

    능숙한지(그리고 어떤 일에 서툰지)

  • 163쪽, 3번째 줄

    초보 프로그래 혹은

    ==>

    초보 프로그래머 혹은

  • 207쪽, 첫 번째 줄(닫는 괄호 추가)

    “배달은 쉽지 않아1(하지만 누군가 그걸 해야만 해2”라는

    ==>

    “배달은 쉽지 않아1(하지만 누군가 그걸 해야만 해)2”라는

  • 243쪽, 2번째 줄

    시간을 보는 대신,

    ==>

    시간을 보내는 대신,

  • 274쪽, 밑에서 7번째 줄

    개밥 먹기dogfood3, 개밥 먹기란 자사 제품이나 자신이 직접 만든 제품(옮긴이 _ 특히 소프트웨어를 사용하는 행위를 말한다.)는 어려운 일이다.

    ==>

    개밥 먹기dogfood4(옮긴이 _ 개밥 먹기란 자사 제품이나 자신이 직접 만든 제품, 특히 소프트웨어를 사용하는 행위를 말한다)는 어려운 일이다.