엘키의 주절 주절

이전에 임백준씨의 책들을 감명깊게 읽었던지라 이번책도 큰 기대를 품고 읽게 되었습니다. 그의 철학에 녹아있는 이야기들은, 자신에 철학과 글에 대한 믿음이 절로 이해가 되는 책들이라 매우 와닿았었죠. 이번책의 내용은 소프트웨어 방법론에 대한 이야기였는데, UML, 리팩토링, XP, 디자인 패턴등 다양한 방법론에 대한 이야기를 듣고 관련 서적을 접해보았지만, 딱히 와닿지는 않았던게 사실입니다. 설계가 잘 되어진 프로그램이 더 좋게 나올것이라는 생각은 늘 가지고 있었지만, 과연 UML의 다이어 그램을 통해서 프로그램을 좋게 만들수 있을까? XP는? 리팩토링은?? 늘 의구심이 들었습니다. 예외로, 디자인 패턴은 그 활용 가치에 공감했지만 말이죠. 특히나 리팩토링의 경우는 더더욱이 그런 편이었는데, 임백준씨가 책..

토요일에 읽기 시작해, 일요일에 끝냈으니 매우 금방 읽은 책이다. 그만큼 재미있게 읽었다. 임백준씨의 저서는 모두 다 갖고 있고, 임백준씨의 철학에 깊은 감명을 받은지라 이번 책도 기대를 하지 않을 수 없었다. 이 책에서 가장 인상 깊었던 인물은 로버트였다. 사실 나는 실수를 잘 견디지 못한다. 내가 실수를 하고 나면 모두가 나를 원망하는 것 같고, 내 잘못이 너무 크게 느껴져 괴로움에 몸부림 치곤하니 말이다. 실수를 두려워 하는 사람은 성장할 수 없다는 본문의 내용을 보고 많은 것을 느꼈다. 내 실수를 변호하고, 옹호하려는 것이 아니라, 실수에서 얻는 것이 있다면 그 실수를 두려워 할 필요가 없는 것 아닌가? 그런 생각이 드니 내 마음이 조금은 편해지는것 같았다. 꼼꼼한점이 부족하고, 빠른 결과물을 내..

누군가 나에게 프로그래머로써 최고의 책을 꼽으라면 무엇을 꼽겠냐고 물어본다면, 난 주저 않고 이 책을 거론한다. 아쉽게도 현재는 절판중 (http://www.yes24.com/24/Goods/1512651?Acode=101) 사실 이런 류의 서적에는 Code Complete 가 있다. Code Complete도 아주 좋은 내용을 담고 있는 책이고, 실제로 더 유명하고 많은 사람에게 교훈을 준 책이지만, 실용주의 프로그래머는 더 좋은 책이다. 무엇보다 실용주의 프로그래머는 좀 더 간결하다. 페이지 수가 더 적다는 의미가 아니다. 지나치게 친절한 과잉 설명도 없이 짧고 적절한 비유를 하고 있으며, 그로 인해 더 즐겁기 때문이다. (더 잘 읽히고, 더 잘 와닿게끔 쓰여있다는 얘기다) 내가 이 책을 Best o..

사실 프로그래밍에 경험이 생긴다고 모두 다 좋은 코드를 작성하는 것은 아닙니다. 가독성은 물론이며, 속도나 메모리상의 이점을 가진 코드도 많은 경험에서 얻어질 가능성이 높은 것이지 자연스레 얻어지는 것은 아니라고 확신합니다. 이 책은 저자가 경험했거나, 적절하다 생각하는 예제를 놓고 다양한 방법으로 해결을 논합니다. 물론 저자가 거론한 방법이 최선은 아닙니다. 저자도 그렇게 얘기하진 않구요. 효율이란 어느 한 가지 관점에서 이루어져야 하는 것이 아닙니다. 주변 상황에 따라 중요시 여겨야 하는 가치가 달라지므로 그에 맞는 적절한 합의점을 찾아야 한다는 류의 이야기는 이런 류의 책에서 자주 보지만, 진부하다 싶은 감은 있어도 너무 당연한 이야기라 이견의 여지가 없더군요. 알고리즘의 선택에서의 팁이 특히 흥미..

리팩토링이란 좋지 않은 구조의 코드를 좋은 구조로 바꾸는 작업을 말합니다. 돌아가기만 하면 되지 구조가 뭐가 중요하냐고 생각하시는 분들은 아마 유지보수의 악몽을 경험해보시지 않은 분들일 것입니다. 실용주의 프로그래머란 책을 읽어보면 깨진 창문 법칙이란 얘기가 나옵니다. 창문이 하나 깨지고 나면 다른 창문이 깨지는걸 대수롭지 않게 여기게 되어, 결국 모든 창문은 깨지게 된단 이야기입니다. 프로그램 코드도 마찬가지입니다. 지금 당장은 이렇게 하는게 문제 해결에 빨라. 우선 이렇게 해놓고 보자. 돌아가니까 내버려두자라고 생각해 대충 처리한 것들은 언제고 문제를 일으키기 마련입니다. 책서 언급한 리팩토링이 필요한 코드의 법칙에는 우리가 개발과정에서 느껴온 실수의 여지를 줄이는 방법이 있습니다. 우리의 머리는 대..

사실 프로그램 작성 만큼이나, 아니 더 중요할 수도 있는 과정이 디버깅입니다. 보통 버그는 논리적인 오류나 실수에서 자주 발생합니다. 그 코드가 영향을 끼치는 다른 코드에서 세웠던 가정이 깨졌다거나 하는 경우에 발생하기도 하죠. 이 책은 그런 부분의 이야기보다, 실서비스 되기전에 테스트를 어떻게 하면 버그를 잘 찾을 수 있을까, 또 이미 문제가 발생했다면 어떻게 찾을것인가에 대한 내용이 더 빈도있게 다뤄지고 있습니다. 이 책은 체계적인 디버깅 방법을 다양하게 다루고 있습니다. 로그, 버그 DB, 버그 트레이스, 테스트, 문제 재현, 추론 같은 방법들 말이죠. 저 같은 경우는 게임 서버를 맡고 있는데, 서버 유지보수 과정에서 겪은 문제들의 해결책이 이 책에 다 나와있었습니다. 제가 그 상황을 겪기전에 이 ..

나는 공격하는 자보다는 방어하는 자의 입장이다. 그런데 왜 보안 서적이 아닌 해킹 관련 서적을 보냐고? 보안이란 이미 알려진 취약점을 틀어 막는다고 되는 것이 아니기 때문이다. 해킹이란 단순히 뛰어난 컴퓨터 지식을 기반으로한 공격 기술만을 말하는 것이 아니다. 책의 내용중 해커들이 파고 들 수 있는 시스템 취약점이 많다는 사실은 새삼 놀랠만한 내용은 아니었다. 뭐 당연한 것이겠지. 프로그래머가 실수를 했을 수도 있고, 악용될 여지의 취약점을 모두 고려한다는 건 쉬운 일이 아니기 때문이다. 이 책에서 설명한 공격 코드가 시스템의 어떤 취약점을 파고 들었고, 어떠한 생각을 가지고 다른 빈틈을 찾아나가는지에 대해 이해하는 것은 크나큰 소득이었다. 막연히 이렇게 해야 한다 라고 알고 있는 것보다, 어떤 취약점이..

윈도우 개발 스토리? 저는 매우 궁금했습니다. 맥이나 리눅스에 비해 윈도우가 압도적인 점유율을 갖고 있지만 그만한 인정은 못받고 있지만, 저는 윈도우가 매우 뛰어나고 M$라 불릴만큼 악덕 기업은 아니라고 생각하기 때문입니다. 그들은 비주얼 스튜디오 만으로도 존경 받을만하죠. (MS만세~) 레이몬드 첸씨의 이름을 달고 나온 책인 만큼 그가 누구인지 매우 궁금했는데, 윈도우 개발에 수석 프로그래머 이셨더군요. 부럽습니다! 이 책은 주로 윈도우를 개발하며 겪은 에피소드와 왜 윈도우가 이렇게 돌아가는 지에 대한 항변(?)을 하는 식으로 이루어져 있습니다. 윈도우는 대부분 사용자 편의에 큰 가치를 두고 있고, 그 대표적인 방침중 하나가 하위 호환이라 할 수 있습니다. 하위 호환을 위해 유지해야 했던 문제 되는 함..