알라딘MGG와이드바


Programmers At Work(번역서 : 컴퓨터 소프트웨어의 창시자들) 리뷰

Programmers At Work(번역서 : 컴퓨터 소프트웨어의 창시자들) 에서 재미있었던 부분들을 정리해 보았습니다. ()는 제가 따로 쓴 내용입니다. 절판된 책이기도 하고 일부 내용만 정리해서 올린 것이긴 해도, 만약 저작권에 문제가 있을 경우 적절히 조치하도록 하겠습니다.

책에는 12명(원서 19명)의 프로그래머들과 인터뷰를 한 내용을 모았는데, 다들 핵심적인 부분에서는 생각이 비슷하더군요.
  • 처음에 구조, 만들려는 것을 정확하게 해야 한다.
  • 다른 사람의 프로그램을 연구해야 한다.
  • 단순하게 만들어야 한다.
개개인의 특징이 잘 드러나는 부분도 좋고, 1989년에는 사람들이 이렇게 생각했구나가 드러나는 부분도 좋았습니다. [http]Coders At Work[http]Masterminds of Programming: Conversations with the Creators of Major Programming Languages 덕분에 이 책이 다시 주목받고 있다는 생각이 듭니다.
[http]programmersatwork.wordpress.com 에 원서 내용이 일부 공개되어 있고, 앞으로도 계속 추가 공개를 할 거 같으니, 아직 책을 못 구해 보신 분들은 이 블로그를 활용해 보셔도 좋을 거 같습니다.
[http]Programmers At Work, 22 Years Later 에는 인터뷰를 했던 개발자들의 요즘 근황을 정리한 기사를 올렸습니다. 죽은 사람들이 몇 분 있어서 맘이 아픈데, 오늘 [http]제랄드 와인버그(Gerald Weinberg) 소식을 들은터라 더욱 더 맘이 아프네요. 프로그래밍도 좋지만, 건강하게 삽시다.

  • Charles Simonyi(찰스 시모니)
    • 일을 거꾸로 하면, 까다롭던 문제가 갑자기 아주 간단해지는 경우가 있습니다.
    • 1972 년 이후에는 '헝가리안' 이라고 부르는 명명법으로 모든 코드를 짜 왔습니다.
    • 프로그램의 대부분은 사물의 명칭입니다. 헝가리안 방식은 명칭을 부여 받은 사물의 속성에서 거의 자동적으로 이름을 만들어내는 방식입니다. (헝가리안 표기법에 대해서는 [http]Joel 의 글도 읽어보자. 이 글은 '조엘 온 소프트웨어를 넘어서'에도 번역되었고, 가장 재미있게 읽은 글 중 하나다)
    • 프로그램을 만들려면 먼저 무엇을 만들고 싶은지 정확하게 알아야 합니다.
    • 프로그래밍의 1단계는 상상력을 발휘하는 것입니다. 그리고 나서 머릿속에서 충분히 구체화시킵니다. 그 다음 단계에서는종이와 연필로 낙서를 합니다. 아직 코드를 쓰지 않습니다. 머릿속에서 구조가 명확히 구체화되면 그 때 코드를 작성합니다. 핵심은머리에 있는 데이터 구조입니다.
    • 프로그래머를 관리하는 가장 좋은 방법은 직접 모범을 보이는 것, 그리고 여러 번 반복해서 코드를 검토하는 것이라고 생각합니다.
    • 젊었을 때에는 머리속에 방이 20개나 있어서 여러 개를 넣어둔 성 같았었는데...
    • 프로그래밍을 하지 않을 때는? 이집트의 상형 문자도 좀 보고... 개인용 헬리콥터 조종사 면허도 있습니다.
  • John Warnock (존 워녹)
    • 코드 작성 방법 : 무슨 일을 해도 우선 충분히 생각합니다. 한 가지 생각에만 너무 집착하지 않고 코드도 필요하면주저하지 않고 버릴 수 있는 용기가 필요합니다. 자신만 알고 있다고 생각하면 곤란합니다. 이 장사의 비결은 정보를 보다 빠르게입수하는 겁니다. '내 발명이 아니다(not-invented-here)' 따외는 신경쓰지 말고 그걸 활용해야 합니다.
    • 좋은 프로그램을 만드는 것은 균형입니다.
    • 좋은/나쁜 프로그래머를 구별하기란 어렵습니다. 작가를 고용하는 것과 마찬가지입니다... 하지만 문학상을 이미 몇 번 받은 사람이라면 매우 높이 평가됩니다... 대게 세상의 평판으로 고용 여부를 정합니다.
    • 수학, 국어, 기초 과학의 기본을 확실히 다져둔 다음에 컴퓨터 공부를 시작하는 게 좋다고 생각합니다.
    • 성공 비결 : 여러 기술을 지닌 재능이 뛰어난 사람들과 함께 있어야 합니다.
    • 중간 결과를 얻을 수 없고, 2년 이상 걸리는 개발은 손대지 않아야 합니다. 2 개월마다 결과를 내야 합니다. 그렇게 하면 그걸 평가하고 재편성하여 다시 시작할 수 있을 겁니다.(오... 애자일)
    • 특별히 좋아하는 언어는 없습니다. 우선 5, 6 개 정도 익히고 나면 다음에 5, 6개를 외우는 건 그다지 어렵지 않습니다.
  • Gary Kildall(게리 킬달)
    • 어려줘서 해결할 수 없을 거 같다고 생각될 때 일이 시작됩니다. 그리고 나서 이를 더 작은 부분으로 나눕니다.
    • 코드 자체에 대한 주석은 붙이지 않습니다.
    • 단순성을 밝혀내면 쉬워집니다.
    • 프로그래머로서 자신만의 스타일을 만들려면? 다른 사람의 작품을 연구해야 합니다.
  • Bill Gates(빌 게이츠)
    • 프로그래밍에서 가장 어려운 점은? 알고리즘을 결정하고, 이를 최대한 단순화시키는 겁니다. 더 이상 단순화할 수 없을때까지 최대한 단순화시키는 것은 대단히 어려운 일이죠. 프로그램의 기능을 어떻게 할 것인가에 대한 시뮬레이션을 머릿속으로그려야만 합니다.
    • 프리마돈나 같은 프로그래머는 신뢰하지 않습니다.
    • 마이크로소프트에서 프로그래머가 아니면서 프로그래밍 프로젝트를 관리하는 사람은 한 명도 없습니다.
    • 벌써 프로그램 속도의 한계를 얘기하는 사람은 게으르고 나태하기 때문이라고 생각합니다. 사용자는 정확히는 몰라도 정말 빠른 프로그램이 무엇인지를 알기 때문입니다.
    • 팀 관리 방법 : 그룹을 소규모로 유지, 똑똑한 사람으로만 구성, 훌륭한 툴 준비, 공통 용어 사용, 그룹 외부에 언제라도 조언해 줄 수 있는 초베테랑팀을 둘 것.
    • 시간이 많이 걸려도 기초를 튼튼히 한 후, 즐긴다는 기분으로 코딩을 하고, 실행해 봅니다. 제일 맛있는 음식을 가장 마지막까지 남겨두는 것과 같은 거지요.
    • 프로그래머의 능력을 시험하는 가장 좋은 방법은 프로그래머에게 30페이지의 코드를 건네주고 그가 어느 정도 속도를 그것을 읽고, 얼마나 이해하는지 알아보는 거라고 생각합니다.
    • 좋은 프로그래머가 되려면, 많이 만들어보고, 다른 사람의 프로그램을 연구해야 합니다.
  • C. Wayne Ratliff(C.웨인 래틀리프)
    • 무슨 일이든 순서대로 해야지
    • 프로그래밍에서 가장 즐거운 순간은 한 발만 더 나가면 완성되는 단계에 왔을 때입니다. 우선 해 보고, 실패하고, 몇 번이고 실패하다가 100번째에 그런대로 쓸 만한 상태에 이르렀을 때 기분이 최고가 됩니다.
  • Jonathan Sachs(조나단 삭스)
    • 요즘은 이미 일이 세분화되어 버려서 폭 넓게 경험할 기회가 부족합니다.
    • 다른 사람의 프로그램을 보면서 여러 가지를 배웠습니다.
  • Ray Ozzie(레이 오지이)
    • 여러 경험을 쌓은 프로그래머와 일하고 싶다. 컴퓨터공학 내에서도 전혀 다른 분야로 옮겨 다니는 것이 좋다고 생각합니다.
  • Bob Carr(보브 카아)
    • 법칙을 발견하는 것
    • 아키텍처는 균일해야 합니다. 즉, 예외가 없어야 합니다.
    • 소프트웨어에 익숙해지기만 하면, 사용자가 일 외에는 생각할 필요가 없는 프로그램이 되어야 합니다.
  • Jef Raskin(제프 래스킨)
    • 저는 메타 프로그래머일 뿐입니다.
    • 잡스는 처음 2년 동안은 이 프로젝트(매킨토시)가 갖는 의미를 전혀 이해할 수 없었던지 프로젝트를 무산시킬려고 생각했던 거죠.
    • 잡스는 다른 사람이 담당한 일까지 자신의 공으로 돌리려고 했습니다.
    • 세탁기 사용자 그룹이 없는 이유는, (사용법이 너무 쉽기 때문에) 세탁기를 사용하는 데 동호회 따위가 필요하지 않기 때문입니다.
    • 유감스럽게도 지금의 사회란 돈을 벌면 벌수록 그쪽의 말에 귀를 기울리는 사람도 늘어납니다.
    • 프로젝트 참가자 모두에게 특허권을 주고 있습니다.
    • 시스템에서 모드를 없애야 합니다.
    • 한 가지 행동으로 한 가지 일을 할 때 목표에 도달하는 길이 오직 한 가지 뿐일 때 고민할 필요가 없어지는데 이를 저는 단순함이라고 부릅니다.
  • Andy Hertzfeld(앤디 헤르츠펠드)
    • 지금 하고 있는 일이 재미있으며, 흥미를 잃게 되면 다른 일을 찾을 것이라고 했다.
    • 프로그래밍 배우기는 자전거처럼 실제로 해 봐야 합니다.
    • 애플사는 애플 II 가 무엇인지도 모르는 사람조차 전부 다 끌어들였습니다.
    • 한심하게도 가장 회사에 공헌을 많이 한 사람이 아닌, 주식 취득을 가장 열심히 한 사람이 돈을 가장 많이 벌었습니다.
    • 잡지사들이 관리자들과 인터뷰했기 때문에 리자를 개발한 것이 관리자 자신들이라고 착각합니다.
  • Toru Iwatani(이와타니 토오루. 岩谷徹)
    • 그 무렵 컴퓨터 게임은 전부 난폭한 것 뿐이었습니다. 여성도 즐길 수 있는 게임을 만들고 싶었습니다. (이 당시에도 벌써 이런 생각을?)
    • 피자를 주문한 후 V자형의 피자를 한 조각 집었을 때 남은 피자 모양이 재미있어 보여서 팩맨의 모양으로 만들었습니다.
    • 괴물의 알고리즘이 가장 어려웠습니다. 빨간 괴물은 바로 뒤에서 팩맨을 추적합니다. 두 번째 녀석은 팩맨의 전방을수비합니다. 즉, A, B 가 팩맨을 샌드위치 시킵니다. 다른 괴물들은 불규칙적으로 움직입니다. 하지만, 사람이 이렇게 쫓기기만하면 전의를 상실할 것이기 때문에, 공,수를 반복하게 했습니다.
    • 아이디어에서 제품까지 1년 5개월 걸렸습니다. 기능을 철저하게 시험하면서 일을 진행했기 때문에 상당히 오래 걸렸습니다.
    • 게임 디자이너는 먼저 인간의 마음을 이해할 수 있어야 합니다.
  • Michael Hawley(마이클 홀리, 마이클 호레이)
    • 워드프로세서로 작성한 문장은 꼴라쥬처럼 보입니다.
    • 음악이 어디서 생겼는지 보다, 음악을 만드는 과정이 중요합니다.

핑백

덧글

  • 펑키보이 2009/11/11 10:59 # 삭제 답글

    항상 좋은글 감사합니다~ 저는 프로그래머가 아니지만 꼭 책들은 읽어봐야겠어요~ 즐거운 빼빼로데이되세요~
  • 박PD 2009/11/11 23:06 #

    프로그래머가 아니면 재미가 덜 할지도 모르겠네요. 지금은 헌책도 구하기 힘들고. 좋은 하루 되세요. :)
  • cuverin 2009/11/12 16:06 # 삭제 답글

    단지 프로그래머에 한정할 만한 글은 아니네요. 다른 분야의 분들도 읽어 봤으면 합니다.
  • 박PD 2009/11/13 21:32 #

    경지에 도달한 사람에게는 그 사람의 영역이 아닌 다른 사람들도 배울 수 있는 지혜를 들을 수 있는 거 같습니다.
  • cybaek 2010/02/02 12:35 # 삭제 답글

    글 재밌게 읽었습니다. 11월에 리뷰하신 것 같은데 아직 책은 나오지 않았나요? ^^
  • 박PD 2010/02/02 12:40 #

    이 책... 은 재판은 안 될 거 같구요, 헌책방을 뒤져보셔야 겠지만 저도 못 찾겠더군요. :)
댓글 입력 영역


Yes24위대한게임의탄생3

위대한 게임의 탄생 3
예스24 | 애드온2