하나의 방식에 익숙해진다는 것은 효율성을 높여주지만 동시에 생각을 틀을 그 안에 가둬버릴 위험을 안고 있다. 요즘에 내가 짠 코드를 보고 있노라면 그런 생각은 더욱 커진다.

새로운 패러다임의 프로그래밍 언어를 공부해볼까?

그러자 갑자기 떠오르는 책 하나가 있었다.
  • MIT에서 10년이 넘게 프로그래밍 입문서로 쓰이고 있다는 책.
  • 하지만, 아마존의 서평을 보면 훌륭한 책이지만 초심자용은 아니라는 책.
  • 표지의 그림을 따서 마법사 책이라고도 불리는 바로 이 책.
Structure and Interpretation of Computer Programs

<Structure and Interpretation of Computer Programs> 말이다.

아마존 별 평점
아마존에서 사람들이 이 책에 매긴 별점 분포를 보면 참 재미있다. 다섯 개와 한 개에 극단적으로 몰려 있는 것이, 완전히 “모 아니면 도”라는 느낌이 든다.

상당히 많은 추천을 받은 서평이 있기에 쓴 사람이 누군가 하고 봤더니.. <Artificial Intelligence: A Modern Approach>의 공동저자이자 현재 구글의 Directory of Research 직을 맡고 있는 Peter Norvig이었다. 그는 자동차에 비유하면서, 이 책은 자동차의 동작 원리, 효율적이면서 믿을 수 있는 자동차를 설계하는 방법을 찾는 사람을 위한 것이라고 했다. 운전하는 방법을 가르쳐주는 책이 아니라는 얘기다. 저 정도 되는 사람이 이 책을 읽고 자신의 직업에 대한 생각이 바뀌었다고 할 정도라니... 꽤 솔깃하지 않은가.

이어지는 서평에서도 반가운(?) 이름이 보였다. <해커와 화가>의 저자 Paul Graham이었는데, 그는 Kenneth Clark의 말을 인용했다.

if a lot of smart people have liked something that you don't, you should try and figure out what they saw in it.
(그런데 저 말의 원전은 아직 못 찾았다.)

아무튼 이런 사람들이 적극적으로 나서서 변호해주는 책이라면 후회는 하지 않겠다 싶어서 냉큼 주문했다. 이른바 “프로그래밍, 처음부터 다시 배우기” 프로젝트의 시작이다.

Posted by 4four
얼마 전에 DebugView와 OutputDebugString()에 대한 글을 올리면서, 릴리즈 버전에서까지 디버그 메시지를 출력하는 프로그램에 대해 성토(!)를 한 바 있다. 그런데 사실 이것이 써드파티 소프트웨어만의 문제는 아니다. 마이크로소프트에서 직접 만든 프로그램조차도 이 DebugView의 메시지 창을 지저분하게 만든다. Visual Studio가 유력 용의자로 의심되는 아래의 메시지가 바로 대표적인 경우다.

[1024] DllCanUnloadNow called for VSA7.dll
[1024] DllCanUnloadNow returned S_FALSE

그동안 이런 메시지들 때문에 참 갑갑해 했는데, 알고 보니 매우 간단한 해결책이 있었다. DebugView의 [Edit] - [Filter/Highligh] 메뉴를 선택해서 나오는 대화상자의  Exclude 창에 필터링해버리고 싶은 문자열을 입력하기만 하면 된다. 반대로 특정 문자열 패턴이 포함된 메시지만 보고 싶다면  Include 창에 적으면 된다. 토큰 구분자는 ;

사용자 삽입 이미지

이런 기능은 충분히 있음직한 것이었는데, 어째서 지금까지 찾아볼 생각을 하지 못했을까...
Posted by 4four
최근에 버그를 양산하고, 그것을 고치는 과정에서 다시 그 수가 기하급수적으로 늘어나 결국 사태를 걷잡을 수 없이 키워버린 일이 있었다. 이에 크게 느낀 바 있어 테스트 자동화를 도입해야겠다고 생각했다.

주로 Visual Studio에서 C++을 사용하는 나에게는 CppUnit이라는 도구가 적당해 보여서 관련 문서를 읽으면서 조금씩 적용해보고 있다.

대충 아래와 같은 템플릿을 하나 만들어두고, 새로운 클래스를 만들 때마다 테스트 클래스를 하나 만들고 템플릿 코드를 적당하게 고친다.
그다음에는 main() 함수 같은 곳에 아래와 같이 테스트를 실행하는 코드를 집어넣는다. 그러면 프로그램이 실행될 때마다 먼저 테스트를 거치므로, 방금 고친 내용이 예상치 못한 부작용을 가져오는 경우 바로 알 수 있다. (물론 그것을 감지할 만큼 테스트를 잘 짰다는 가정하에 말이다.)
Posted by 4four