프로그래밍 심리학 - 프로그래밍은 사람이 한다
프로그래밍은 엄연히 인간 행동의 한 형태임에도 그런 관점에서 프로그래밍을 연구한 사람은 거의 없다. 그렇다면 프로그래밍을 인간 행위로 조명하지 않은 이유가 있었던 건 아닐까? 아마도 프로그래밍은 연구 대상으로 삼기에 너무나 복잡한 행위이기 때문에 커다란 불가사의로 남을 수밖에 없었을 것이다.
고전 중의 고전이다. 1971년에 초판이 발행되었으니 거의 40년이 된 책이다. 가끔 예를 들어서 설명하는 천공카드가 아니었더라면 옛날 책 인지도 몰랐을 거다. 프로그래밍은 사람이 한다. 하지만, 이 당연한 사실에 대한 인식이 책이 써진 40년 전이나 지금이나 같다. 아직도 유용하다. 참 슬프기도 하지.
프 로그래밍을 인간 행위, 사회 활동, 개인 행위로 나눠서 심리학적인 접근을 했는데, 어떤 자질이 프로그래머에게 필요할까? 필요한 지능은 어떤 게 있을까? 프로그램 팀은 어떻게 구성해야 할까? 등등. 발상 자체도 재미있고 한번 자신을 돌아보고 실천해 볼 것이 가득한 책이다. 그 중 나는 비자아적 프로그래밍이 가장 기억에 남는다.
다른 사람에게 코드 검토를 부탁하는 일은 생각보다 힘든 일이다. 논리의 오류나 지름길을 놔두고 내가 둘러간 길을 지적받기 위해서인데, 이런 지적에 마음 상하지 않기가 참 어렵다. 그래서 코드 검토를 부탁하는 일이 드문지도 모른다. 여기서 이런 문제를 명쾌하게 짚어 주는데 코드와 자신을 동일시하는 자아적 프로그래밍(ego programming) 때문에 이런 현상이 발생한다는 거다. 코드에 대한 비판을 감성적이지 않고 이성적으로 받아들일 수 있는 즉, 코드와 자신을 분리시킬 수 있는 이런 걸 비자아적 프로그래밍(egoless programming)이라 부른다.
코드를 지적받으면 왜 그렇게 방어적으로 변하는지 모르겠다. 나 자신도 또한 철저하게 코드와 자신을 동일시했나 보다. 비자아적 프로그래밍을 하려면 어떻게 해야 하나? XP(Extreme Programming)의 짝 프로그래밍(Pair Programming)과 같이 비자아적 프로그래밍을 자연스레 하는 방법을 도입해야 할까? 비자아적 프로그래밍을 하는 팀 분위기를 어떻게 조성해야 하나. 코드 검토를 부탁해볼까? 개발 규모가 커져서 다른 사람에게 코드 검토를 부탁하기조차 쉽지 않다. 일단은 비자아적 프로그래밍이란 단어를 마음에 담아둬야겠다. 그래도 담기만 하면 조금이라도 변하지 않을까?
UML, 실전에서는 이것만 쓴다. - 로버트 마틴(엉클 밥)이 썼다. 끝
UML이 한때 붐이었다. 어딜 가도 UML… 정말 UML 없으면 대규모 개발은 꿈도 못 꾸는 줄 알았다. 하지만, 어느새 잠잠해졌다. UML을 실전에서 많이 쓰냐고? 글쎄 우리도 많이 안 쓰고 다른 프로그래머 얘기를 들어봐도 많이 안 쓴다고 한다. 왜 갑자기 이렇게 됐을까?
실제 제품을 만들기 전 모델을 만들어서 설계를 검증해보는 이유는 비용이 무조건 싸기 때문이다. 하지만 UML을 사용해 설계하고 검증하는 게 과연 실제 구현을 하는 비용보다 쌀까? 글쎄다. 이 비용이 소프트웨어에서는 명확하지 않다. 그래서 어떻게든 UML을 효과적인 도구로 사용해야 하는데, 이게 실패해서 실전에서 거의 사용하지 않는다. UML을 의사소통을 위한 도구로 복잡하지 않고 간단하게만 사용하면 설계를 하고 검증하는데 효과적으로 사용할 수 있다. 도구일 뿐이지 방법이 되면 안 된다
경험으로만 얻을 수 있는 값진 지식을 잘 풀어놓았다. 복잡하게 쓰지 마라. 필요한 곳에만 써라. 칠판에 그려서 의사소통을 하고 끝나면 지워버려라. 많이 쓰려거든 차라리 쓰지 마라. 절제하라.
PS 1 : 이 책에 대한 서평들을 보면 “밥 아저씨가 썼으면 더 빨리 봤을 텐데”가 대부분이다. 나도 밥 아저씨가 썼다는 사실을 알았으면 더 빨리 봤을 것이다. 제목이 삼류 책 냄새가 나서 거들떠도 안 봤는데, 밥 아저씨 책이었다니!
PS 2 : 아꿈사에서 UML 적절하게 사용하기란 발표를 했는데, 이 책을 바탕으로 프레젠테이션을 했다.
프로그램은 왜 실패하는가? - 디버깅 이론서, 지겨울 수도 있다
프로그래머가 만든 결함(defect)에 의해 프로그램 상태가 감염(infection)되고 이 감염된 상태 때문에 실패(failure)하게 된다. 감염을 따로 격리하고 결함을 찾아서 고치는 과정을 디버깅이라 하는데, 이 책은 짜임새 있고 논리적인 접근법을 가르쳐 주는 이론서이다. 딱 대학교 교재로 쓰이면 좋을 책이다. 덕분에 중간은 좀 지루하게 느껴진다.
디버깅에 대한 이론을 바탕으로 깔고 싶었는데, 딱 원하는 내용이라서 만족한다. 보고 있으니 디버거를 만드는 데 필요한 이론을 배우는 느낌도 든다. 이 책 홈페이지가 있는데, 프레젠테이션 슬라이드도 제공한다. 게으른 교수들이 좋아하지 싶다. 흐~
아꿈사에서 스터디 교재로 사용했다. 난 7장 오류 연역을 발표했는데, 발표한 슬라이드는 여기서 볼 수 있다. 그리고 발표 자료를 아꿈사 위키에 정리해서 다른 발표자료도 볼 수 있다.
왠지 Beautiful Code에서 본 델타 디버깅에 관한 글도 이 사람이 쓴 것 같았다. 그래서 찾아보니 ‘28장 아름다운 디버깅’을 쓴 사람이 바로 이 책을 쓴 Andreas Zeller 였다. 후~ 역시 맞구나.
실용주의 프로그래머를 위한 단위 테스트 with JUnit - 테스트 가이드 라인이 굿!
처음 읽어보는 The Pragmatic Programmers 시리즈. 두께도 얇고 관심이 있는 유닛 테스트에 관련된 책이라 읽었는데, 만족스럽다. 달리 실용주의 프로그래머를 들먹이는 게 아니구나. 딱 필요한 내용으로 바로 유닛 테스트를 해보면서 어떤 건지 경험하게 해준다. C++을 주로 사용하는데, 쉽게 쓰였고 문법이 비슷해서인지 예제 코드를 읽는데 어려움은 없었다.
유닛 테스트를 시작하는 단계인지라 어떻게 테스트하면 될지. 어떤 것을 테스트하면 될지. 막막하게 느껴지는데, 가이드 라인은 제공해줘서 많은 도움이 됐다. 딱~ 기억하기 좋은 줄임말을 사용했다.
[리뷰] Google C++ Style Guide
사실 style guide가 나와서 말인데, 나는 조엘이 엄선한 소프트웨어 블로그 베스트 29선에서 본 '스타일은 언어 요소다 - 켄 아놀드'글을 완전 지지한다. 많은 언어가 무시하는 공백 문자를 언어 요소로 넣자고 주장하는데, 지겨운 스타일 논쟁을 완전 없앨 수 있고 파싱이 쉬워 IDE에서 지원할 껀덕지도 무척 많아지기 때문이다. 어딜 가나 같은 스타일... 적응할 필요도 없으니 얼마나 좋은가.
하지만, 현실로 돌아오자. 현재 게임 클라이언트를 구현하는데 C++을 버리는 게 불가능하다. 그래서 이렇게 여러 스타일이 존재하는 언어에서는 좋은 스타일을 보고 배우고 자신의 스타일을 잡아가는 게 중요하다. 좋은 코딩 스타일은 가독성을 높여주고 코딩 실수를 줄여준다. 스타일을 지키는 것도 습관이다. 물론 가장 중요한 건 정한 스타일을 잘 지키는 것이다.
나중에 시간 나면 살펴보겠다고 북마크해둔 Google C++ Style Guide를 살펴보고 괜찮겠다 싶은 것들을 요약해봤다. 후후 역시 좋다고 북마크하긴 쉬워도 시간 내서 한번 살펴보기는 어렵네.
[발표자료/실전 윈도우 디버깅] 13. 포스트모템 디버깅
windbg, ADPlus와 같은 툴을 사용해서 덤프 파일을 만들고 분석하는 방법과 포스트모템 디버거, 윈도우 오류 보고에 대한 내용을 담고 있다.
PS : 데모를 발표하면서 하기 싫어서 스크린캐스트 툴인 Jing을 사용했는데, 대만족.
[리뷰] 효과적인 3D 익스포터 디자인: 아티스트를 완전히 만족시킬 수 있는 방법
Make your tools "bullet-proof"
bullet-proof는 총알을 막는 방탄을 의미한다. 죽지 않고 잘 돌아가는 프로그램을 가리킨다. 이거 당연한 거 아냐? 다만, 여기서 추가로 생각해야 할 게 만약 디자이너가 무사히 익스포트했다면 게임 엔진에서도 알 수 없는 이유로 죽지 않고 잘 돌아가야 한다는 거다. 아티스트가 몇 시간 시도하다가 포기하면서 프로그래머에게 던져주면 디버깅 끝에 "influences가 버텍스당 4개 이하여야 합니다."라는 대답이 돌아온다면? 쏟아부은 시간을 생각하면 피눈물이 날 것이다. 당연히 죽지 않고 익스포터에서 경고를 해야 한다.
Make the tool, not the artist, do the non-artistic work.
니도 할 수 있는 쿼드를 트라이앵글로 잘라내는 일 따위를 아티스트에게 시키지 마라는 것이다. 이런 건 당연히 툴에서 지원해줘야 한다.
