티스토리 뷰



조엘 온 소프트웨어 (http://elky.tistory.com/52를 너무나도 재밌게 읽고, 2010년초에 사서 읽었지만 이제서야 서평을 남기게 되네요.


서평을 올리지만 않았다뿐, 요즘도 책은 나름 꾸준히 읽고 있었습니다.


롤하다 닷지하고 주로 읽었....쿨럭!



여하튼, MS에서 프로그램 매니저로 일했고, 포그 크릭을 운영중인 그의 시야는 여전히 놀라웠습니다.

유독 와닿는 몇가지 컬럼이 있었는데요, 


자바만 가르치는 위험한 대학과, 예일 대학 강연, 틀린 코드를 틀리게 보이도록 만들기가 바로 그것이었습니다.,



8. 자바만 가르치는 위험한 대학

우리나라 커리큘럼도 이렇게 변해가고 있다는 사실이 저는 매우 걱정됩니다.

자바가 좋은 언어냐 아니냐는 논점을 흐리기 때문에 배제한다고 봤을 때, 조엘씨가 얘기하신 "자바는 뛰어난 프로그래머와 고만고만한 프로그래머를 구별할 만큼 어려운 언어가 아니란 점이 문제라고 얘기하신 점에 공감합니다.

저는 분명히 C언어를 고르지 않았다면 자료구조를 직접 만들어내지 못했을 겁니다.


"이봐, 자바를 쓴다면, 자료구조를 직접 만들어낼 필요가 없다구"

라고 얘기하신다 해도, 저는 포인터와 재귀를 이해하지 못한다면, 이해 못할 분야가 너무나 많아 진다고 생각합니다.


프로그래밍을 중도 포기하는 사람이 너무 많아서 모두를 하향 평준화하려는건 아닐까요?

분명, C와 자바를 동시에 가르치던 시기에 프로그래밍을 포기하는 비율이 높았다는 것은 알고 있습니다.

그렇다고해서, 더 많은 것을 이해할 수 있는 기본이 될 C언어를 학교에서 가르치지 않는다면 어디에서 배우게 될까요?


모두가 자바에서 제공되는 것 이상은 무엇도 할 수 없는 현실이 되는 것은 누구도 원치 않을텐데 말이죠.



9. 예일 대학 강연

MS에서 일하셨던 분 답게, 윈도우에 대한 이야기를 꽤나 많이 하시는 편입니다.


The Art of unix Programming에 나올 법한 내용들과, 윈도우 개발 282 스토리에 나올법한 내용들을 많이 얘기하시는 편인데요,


역시나 윈도우의 개발 문화에 대한 단점 지적 부분은 들을 떄마다 큰 공감이 됩니다.


C언어를 배우며 모두가 거치는 코스인 CLI 프로그램에서, GUI 기반 프로그래밍을 접하고 난 뒤 겪는 혼돈, 그리고  그 문화가 낳은 재앙(?)들에 대해서 말이죠.

저도 아주 여실히 깨닳고 있습니다. 명령행 프로그램 (CLI)위에 GUI를 얹는 구조가 아닌, GUI 기반 프로그래밍이라니요...


이렇게 배워온 많은 것들이, 코드 재사용, 기능 재사용등을 막는 제약이 되고 있다는 사실이 안타깝습니다.

게다가, Run and fix나, 조작 순서가 조금만 달라져도 돌지 않는 프로그램 따위를 양산했기 떄문입니다.


물론 좋은 프로그래머인 여러분들은 그렇지 않으실거란건 알고 있습니다.


또 자동화된 테스트만으로 좋은 사용성과 버그를 모두 제거할 수 없다는 사실에 대한 얘기도 흥미롭습니다.
품질은 단순히 기술에 치우치지 않는다라... 저도 동의합니다. 이 의견에 동의하면서도 건망증이라도 걸린건지,  종종, 아니 꽤나 자주 품질=기술이란 의미로서 생각하곤 하지만 말이죠.


몇몇 분들이 울컥하실수도 있는 일이지만, 사내 소프트웨어 개발자가 되면 안되는 이유에 대해서도 공감합니다.

기업의 주력 업무에 일하지 못한다면 좋은 대우를 받기 어렵기 떄문이지요.



23. 틀린 코드를 틀리게 보이기


이건 그냥 조엘씨 의견 거의 그대로 붙여 쓰겠습니다.


일반 규칙 

* 함수를 짧게 유지하라

* 변수는 쓰기 직전에 정의하라.

* 매크로를 남발하여 자기만 아는 프로그래밍 언어를 만들지 마라.

* goto를 쓰지 마라.

* 중괄호로 묶이는 블록은 한 화면에 다 보이게 하라.


아무래도 C언어를 예로 든 만큼, 크게 와닿는군요.

매크로...음 국지적 사용만 하는데도 곤욕을 겪을때가 많아 공감합니다.


앱스 헝가리안과 시스템 헝가리안

잘못 퍼진 헝가리안 표기법에 대한 오해를 풀어주고 계십니다.

요새 자주 보게 되는 코드가 boost나, linux쪽 코드라 그런지 헝가리안 표기법이 별로 없는데,
일정 부분 헝가리안 표기법을 축소해서 사용하고 있는 중인지라, 잘못알고 있던 헝가리안 표기법에 대한 이해를 도와준 점이 좋더군요.


예외 때려부수기

예외가 정확히 프로그램이 원하는 동작을 보장할 거라는 확신을 갖기 어렵게 만든다는 이야기군요.

물론 저는 MS에서 일해본적은 없지만, 진입점마다 예외 처리 구문을 넣고 단순 실수를 잡는 식으로 커버리지를 높이는 방법으로 사용하고 있고,

return값 만으로 알리기 어려운 상황에서 코드의 흐름을 멈추는 용도로 쓰고 있다보니, 조엘씨가 얘기하시는 예외처리가 갖게되는 문제에 대해서 100% 공감할 순 없었습니다.


조각 코드만으로 이 코드가 완전 무결할 것이라는 확신을 갖기 어렵다는 점에서는 공감합니다.




이외에도 책에 실린 내용 하나하나가 내공과 통찰에서 뿜어 나오는 좋은 교훈이나, 때론 논쟁거리가 많습니다.

현재 운영중이신 포그 크릭이 얼마나 좋은 회사인지, 그리고 좋은 프로그램 회사의 오너가 왜 프로그래머여야 하는지 등 여러가지를 느낄 수 있게 해주는 분이라고 생각합니다.


전반적으로 언어의 제약이 없이, 좋은 내용이 가득합니다.

꼭 읽어보세요. 가능하다면, More Joel no Software보다, Joel on software 부터요.

댓글