반응형
대략 10년이 넘은것 같은데, 영풍문고에 들렸다가 제목에 끌리고, 내용도 괜찮은것 같아서 구매를 해서 봤던 책이였다.
내용은 가물가물.. 아니 거의 기억이 안나지만, 유명한 프로그래머들의 이야기와 뒷편에는 그들의 코딩스타일도 보여준다.
빌게이츠를 비롯해서 당시 유명했던 로터스나 디베이스같은 프로그래머들의 이야기..
몇일전에 에자일블로그에서 서평을 보고 생각이 나서 나도 정리해서 올림... 책표지는 안보여서 한장 찍고...
<도서 정보>제 목 : 천재프로그래머 컴퓨터 소프트웨어의 창시자들
저 자 : 마이크로스프트 프레스 편/ 노한주 옮김
출판사 : 신어림
출판일 : 1993년 3월
<책속으로>
찰스 시모니 - 멀티플랜과 엑셀
존 워녹 - 포스트스크립트
게리 킬달 - 콘트롤 프로그램/마이크로 컴퓨터
빌 게이츠 - 베이직
C. 웨인 래틀리프 - 디베이스
조나단 삭스 - 로터스 1-2-3
레이 오지이 - 심포니
보브 카아 - 프레임워크
제프 래스킨 - 매킨토시 프로젝트
앤디 헤르츠펠드 - 매킨토시 오퍼레이팅 시스템
이와타니 토오루 - 컴퓨터 게임 팩맨
마이클 호레이 - 사운드 드로이용 소프트웨어
부록 프로그래머들이 작성한 스케치, 소스 코드 - 찰스 시모니, 게리 킬달, 빌 게이츠, 보브 카아, 앤디 헤르츠펠드, 마이클 호레이
찰스 시모니
- 프로그래밍의 제 1단계는 상상력을 발휘하는 것입니다. 그리고 나서 머릿속에서 구체화 시키는 것입니다. 그 다음 단계에서는 종이와 연필을 사용합니다. 낙서하기 위해서지요. 아직 코드는 쓰지 않습니다. 박스와 화살표는 몇개나 그렸는지 모르지만, 그건 대부분이 정말 낙서입니다. 진짜 설계도는 머릿속에 있으니까요. 머릿속에서 구조를 구성하는게 좋습니다. 코드화 하고 싶다고 생각하는 실물의 상징이 구조를 말이에요. 머릿속에서 구조가 명확해지면 그 때 코드 작성에 착수합니다.
존 워녹
- 무슨일을 하더라도 충분히 생각합니다. 무슨 일을 할 때 버려야 할 것은 과감하게 버립니다. 재미 없는 책을 읽을 때처럼 코드도 주저하지 않고 휴지통에 버릴 수 있는 용기가 프로그래머에게는 필요합니다. 한 가지 생각에만 너무 집착하지 말고, 필요하다면 버리고 가는 것. 프로그래머의 자세란 그래야 합니다. 그리고 자시만 알고 있다고 생각하면 곤란합니다. 머리가 더 좋은 사람도 얼마든지 있으니까요. 갑자기 누군가가 나타나서 자신보다 뛰어난 알고리즘을 만들어 낸다든가 더 간단한 방법을 생각해 낼 수도 있죠. 이 장사의 비결은 말이죠 정보를 보다 빠르게 입수하는 겁니다. 다른 사람의 아이디어는 뭐든지 즉각 입수해야 합니다. 그리고 그걸 자기 나름대로 실행할 때는 <내 발명이 아니다>라는 사실 따위는 신경 쓰지 말고 그걸 활용해야 한다는 것입니다.
- 우수한 컴퓨터 프로그래머가 되는 비결은 프로그램끼리 조합하는 방법에 달려 있습니다.
게리 킬달
- 코멘트는 좀처럼 쓰지 않습니다. 절차상 첫 부분, 그것도 데이터 구조에 관한 설명문만 쓸 뿐 코드, 그 자체에 대한 코멘트는 붙이지 않습니다. 적당한 방법으로 만들어진 코드는 알기 쉬울 테니까요.
- 프로그래머로서 자기 자신만의 스타일을 만들기 위해서는 다른 사람의 작품을 연구해야 합니다. 문제 해결에 접근하는 방법이나 사용하고 있는 툴 등을 연구하면 자기 자신의 작품을 새로운 눈으로 볼 수 있게 됩니다.
빌 게이츠
- 당장 코딩부터 시작하는 사람이 있는가 하면 차분하게 앉아서 충분히 생각한 다음에 시작하는 사람도 있습니다만, 그 차이는 메모 노트가 있느냐 없느냐 하는 차이일 뿐입니다. 그것보다 중요한 것은 그 사람의 머릿속에 떠오른 내용입니다. 우리가 알고 있는 탁월한 프로그래머들은 차를 운전하고 있을 때나 음식을 먹을때나 항상 프로그램에 대해 생각합니다. 그러려면 대단한 정신력이 필요하죠
- 설계 단계에서 우선 프로그램 전체를 개략적으로 생각한 다음에 자리잡고 코드를 작성합니다. 코드 작성이 모두 끝난 다음에는 다시 처음으로 되돌아가서 다시 한번 전체를 검토합니다. 프로그램을 작성할 때 가장 중요한 점은 데이타 구조의 설계입니다. 두번째로 중요한것은 다양한 코드를 분류하는 일입니다. 그것들을 완벽하게 하지 않고는 공통의 서브루틴을 어느 것으로 해야 할지 예리한 감각이 길러지지 않기 때문입니다.
- 처음 3, 4년만 지나면 좋은 프로그래머인지가 아닌지가 분명히 가려집니다.
- 프로그래밍의 능력을 시험하는 가장 좋은 방법은 프로그래머에게 30페이지의 코드를 건네 주고 그가 어느 정도 속도로 그것을 읽어 내고 어느 정도 이해할 수 있는지를 조사해 보는 것이라고 생각합니다.
- 프로그래밍은 재능입니다. IQ와 같은 것이겟지요 코드를 읽을 때는 자신의 프로그램 경험을 바탕으로 코드에 온 신경을 집중 시킵니다. 보통 사람들은 이렇게 말하겟지요 '이것을 읽으려면 며칠 밤이 필요합니다.' 하지만 정말로 우수한 프로그래머라면 이렇게 말하겠지요 '집에 가지고 가서 오늘밤 한시간만 집중해서 전부 훑어보겠습니다.' 그 능력의 차이는 굉장히 큰 겁니다.
- 프로그래머가 되기위한 가장좋은 방법은 실제로 직접 프로그램을 작성해보는 것이고 다음은 다른 사람이 작성한 프로그램을 연구하는 것입니다.
- 자발적으로 자신의 프로그램을 세계의 탑 클라스 프로그래들에게 자신의 프로그램이 어디가 틀렸는지 묻지 않으면 안됩니다. 그리고 피드백을 얻을때는 조금이 나마 자신의 특이성을 집어 넣어야 합니다.
- 퍼스널 컴퓨터 방면에 정말로 관심을 갖고 있는 사람이라면 그러한 제품을 모조리 사용해 볼 것이라고 생각됩니다. 그러다 보면 그러한 제품을 모조리 사용해 볼 것이라고 생각됩니다. 그러다 보면 그 패키지보다 더 좋은 제품을 만들어 낼 수 있죠.
C. 웨인 래틀리프
- 프로그램의 UI등의 디자인시에 직관적으로 뒤로 물러서서 '사용자는 무엇을 원하고 있는가, 이것을 어떻게 이용하려고 할 것인가, 그것은 어떠한 이익을 줄 수 있을 것인가' 에 대해 생각합니다. 어떻게 하면 최고의 프로그램을 만들까 하는 생각에만 골몰하게 되면 현실적인 시장이라는 관점이 머리에서 빠지게 되지요
- 이상적인 모듈을 만들고자 한다면 1페이정도의 길이로 만들어야 됩니다. 만약 1페이지가 넘을 것 같으면 다시 생각해야 합니다. 여기에서 하려는 것이 과연 무엇이었을까, 그것을 따로따로의 모듈로 분해하는 쪽이 좋을 것인가 등을 말입니다.
- 코멘트가 필요하다고 하다는 것은 프로그램이 명확하지 못하며 어딘가 이상한 부분이 있기 때문이라고 생각합니다. 코멘트가 필요하지 않는 프로그램이 좋은 프로그램이지요 프로그램은 그 자체가 코멘트여야 합니다.
- 각 모듈은 비교적 작아야 합니다 만일 1페이지를 초과하면 어딘가 이상한것입니다. 물론 각 모듈에 한 줄 정도의 코멘트가 필요한 것은 확실합니다.
- <의욕>만 있다면 프로그램은 좀 더 쉬워집니다. <의욕>이 없다면 아무리 덤벼도 어렵죠, 아마도 환멸을 느끼는 것으로 끝날지도 모릅니다. 한마디로 말하자면 <자신이 정말로 하고 싶은 것을 하십시오>라고 말해주고 싶습니다.
- 디버깅이나 디자인이라든가 그 밖의 여러가지 분야에서 달인도 얼마든지 있습니다. 저는 그들에게 배우며, 경쟁하는 것이 좋습니다.
조나단 삭스
- 정해진 코멘트 스타일은 한가지 있습니다. 대개의 경우 프로그램을 꽤 작은 모듈로 분해해서 그 모듈과 입,출력에 관한 내용으로 다량의 코멘트를 다는 것이지요 코멘트는 그것 만합니다. 각 모듈의 내부 구조 까지 자세하게 적는것은 의미가 없으니까요 코드는 다른 프로그래머가 보고도 한눈에 알아볼 수 잇게 되어 있습니다.
- 적절한 인텐테이션이 매우 중요하다고 생각합니다. 그리고 나서 변수에는 가장 적절한 이름을 붙이는 겁니다. 정말로 정확하게 잘 짜여진 프로그램에는 일종의 간결함과 조화가 있습니다.
레이 오지이
- 프로그램을 만들때는 치밀한 구조를 중요하게 생각합니다. 모순 없이 깔끔하게 만들죠 그리고 모듈방식을 많이 써서 각 부분을 층층이 겹쳐 쌓아 넣고 화일과 디렉토리 번호는 자유자재로 씁니다.
- 프로그램 하나를 여러 사람이 만들 때는 프로젝트 초기 단계에서 전체적인 에러 처리 방법, 개개인의 의견에 대한 검토, 서브 루틴의 이름 등을 미리 정해 두는 것이 중요합니다. 간혹 이런 일을 싫어하는 사람들도 있지만 명령어 쓰는 법, 브레스 사용법, 인텐테이션하는 법 등을 반드시 지시해 두어야 합니다.
- 프로젝트의 착상은 대부분이 끊임없는 모방과 개성을 통해 만들어집니다.
- 젊은 프로그래머들 중에는 시간을 잘못 계산하기가 일쑤거든요 하지만 경험이 쌓이면 자신의 습관이나 그때 그때의 마음가짐을 기초로 해서, 독자적인 <시간 계산>을 정확하게 할 수 있게 됩니다.
- 여러가지 경험이 쌓인 프로그래머와 일을 하고 싶습니다. 경험이 충분하다는 말은 여러 가지 일을 해봤다는 뜻이지요 즉 대학을 졸업해서 1, 2년 동안은 한눈 안팔고 어떤일을 해본후 컴퓨터공학내에서도 전혀 다른 분야로 옮겨 다니는 것이 좋다고 생각합니다.
- 사용자가 필요로 하는 프로그램을 개발할 때는 제품의 예상 구매자에 대한 프로필을 작성합니다. 그 다음 모든 사용자의 몇 퍼센트가 각각의 기능을 이용할지 예측합니다. 그렇게 하면 어떤 기능이 가장 많이 이용될지 예측할 수 있기 때문이지요.
- '만일 나는 프로그래밍에 빠져 헤어날 수 없다. 어쩔 수 없이 프로그램을 쓸 수 밖에 없다라는 사람이 있다면 마음을 편히 가지십시오 가능한 많은 프로그램을 작성하십시오. 그리고 가능한 여러 가지 프로젝트에 관계 하십시오. 또한 많은 시간 동안 컴퓨터를 사용하십시오. 그러나 자신의 체력 한계를 정확히 판단할 수 있어야 합니다. 그리고 사람들로부터 이상한 놈이라는 소리를 들어도 신경 쓰지 마십시오.
앤디 헤르츠펠드
- 기술자와 예술가의 역활을 동시에 할 수 있는 일은 프로그래밍 이외에는 없다고 생각합니다.
반응형