nobody

음.. 근데 회사에서 몇 년 프로그램 짜다보니 느낀 것은..
어리고 경험 없는 초짜 프로그래머는 “프로그램 짜는 것은 금방인데 디버그가 진짜 짜증나고 그때부터가 시작이죠” 라곤 하고.
관록있고 통찰력 있는 존경스러운 프로그래머는 “처음에 어떻게 짤지를 설계하는 것에 가장 시간이 많이 들고 실제 프로그램을 입력하는 것은 타이핑 수준의 일이고, 버그 역시 설계를 잘 할수록 적게 발생하고, 좋은 설계에서는 디버그도 쉽다” 라곤 하더라.
그리고 그 위의 정말정말 뛰어난 프로그래머는 다른 사람의 코드를 탓하는 법이 없더라. 왜냐면 어떻게 하면 가장 쉽게 다른 사람의 코드를 탄탄하게 바꿔놓을지까지 알게 되는 듯.
단지 라이브러리를 사용할 줄 알고, 새로운 기술을 해봤고 하는 것보다는 flexible 하고 general 한 library 를 만들 수 있고 platform 을 설계할 수 있는 것이 보다 뛰어난 능력인 듯.
뭐 어쨌거나 나는 디버그 이야기는 별로던데 쩝. :$

1. 설계의 논의에대해서
이쪽은 어떤식의 프로그래밍을 지향하고 어떤식의 프로그래밍을 지양하는가에 따른 거 같아요.

1.1. 설계에 대한 관점의 차이
‘설계가 중요한가’에 대해서도 ‘초기의 설계가 중요하다’라는 의견부터 ‘CRC 카드’식 접근방법을 취하는 사람들도 있겠죠. 오히려 이쪽으로 몰려드는 사람이 많다는 것에 대해서는 아시죠?

1.2. 프로그래밍은 타이핑?
두번째의 이슈인 ‘프로그램을 입력하는 것은 타이핑 수준의 일이다’에서는, 내가 생각하는대로 코딩을 할 수 있는가 – 다시 말해, 내가 완전히 코딩 머신인가 – 의 문제가 걸릴텐데요. 정말 관록있는 코더라는건 자신이 사용하는 언어에서만큼은 완전한 머신이 될 수 있겠죠. 그때는 완전히 코딩 수준의 일이겠지만, 자신이 사용하는 언어의 모든 것을 알고 있지 않는한 완벽한 프로그래밍을 하기 힘들죠.

멀티쓰레드 프로그램의 예를 들자면, 가령 ‘C/C++에서의 volatile의 의미’를 보자면, 해당 언어의 설계 기반인 단일 쓰레드 추상 머신에서의 포인트 개념’이라는 것, 또한 ‘non-volatile 변수와는 reordering이 허가된다는 점’을 모르고서는 제대로 프로그래밍 하기 힘들겠죠. 자바의 예를들어보자면, ‘String 객체는 멀티쓰레드 환경에서 mutable할 수 있다’라는 사실을 알고 있어야겠죠? (순식간에 뻥! 하고 터져버리는 보안버그를 만들 수 있는, 자바 String의 문제점 알고있는 사람 극히 드물 것임.) 데이터베이스 코딩을 한다면 ‘prepared statement의 경우 쉽게 SQL injection을 막을 수 있지만 그렇지 않은 경우 어렵게 될 수 있다’는 것을 알고 있어야겠죠.

코딩을 잘한다는 건, 이런 문제점들에대한 생각이 풍부한 것을 말하죠…

대가의 코드는, 설계 뿐만 아니라 이런 점들에 대해서도 고려를 하는 것을 말하겠죠. 제가 최근에 보는 코드는 심지어 배열을 메모리상에 배치할때도 locality를 생각해서 행/열을 정하고 접근하기도 하던데.. 물론 이런 이슈는 왠만하면 다들알고 있지만, 실천에 옮기기는 어려운 문제죠.

한가지 기교로, 이런 예는 어떤가요. (serene님이 알려주신거)
C/C++에서는 ‘=’와 ‘==’가 쉽게 헷갈리며 실수할 경우 프로그램이 오동작할 수 있음을 해결하기 위해,

bool var;
if (var = false) { … } // Possible Bug!

를

bool var;
if (false = var) { … } // Must be detected in compile-time

와 같이 기술하는 방법으로 에러를 피해버리죠.
간단해보이지만, 꾸준히 생각하지 않으면 하기가 힘들겠죠..

1.3. 설계 기법에서의 저의 지향점
저는 기본적으로 TDD와 XP를 지향합니다. ^^
성격상에도 그렇구요.

적당한 초기설계후 계속 진화하는 식.

2. 라이브러리와 플래폼의 설계 능력이 궁극적 지향점?
그럼 과연 프로그래머/컴퓨터과학자로서 가져야할 문제 의식이 무엇일까가 문제이죠.. 그런데

Computer Science is no more about computers than astronomy is about telescopes.
— E. W. Dijkstra

라는 말이 있죠.. 하지만 라이브러리/플래폼의 의미는 사실 컴퓨터에 국한된 이야기이겠죠. 사실은 저의 관점에서는, 컴퓨터를 공부한다는 것은 문제를 해결하기 위한 다양한 방법에 대한 연구입니다. 즉, 알고리즘 itself 라는 것이죠…

이쪽은 사람마다 의견이 다를 수 있다고 봐요. 개인마다 경험이 다르니까.

——-

근데 커멘트 준 이 아저씨 your affection 쥔장님 아닌가…? ㅋㅋ
이 아저씨는 똑똑하고 다 좋은데, 산업체 경험이 너무 많아요.. 공부를 하시기엔.
가끔 그렇게 생각하고 있음. 그런 경험이, 자신의 범위를 가둘 수 있다고 생각
하고 있고, no offense, 그 단적인 예가 자신의 지향점을 라이브러리와 플래폼의
설계능력으로 한정지워지는 거라고 생각이 들어..

나의 능력이 라이브러리 설계를 잘하는 것이다를 궁극점 지향점으로 만들지말고,
‘나는 알고리즘을 생각하면 코딩은 애들이 한다’와 같이 생각하는게 지향점으로
더 맞지 않을까?

슈퍼스타 – 빌게이츠, 토발즈 등 – 이 라이브러리 설계능력으로 유명해진건
절대로 아니며, 비젼과 문제 해결에 있었음을 생각해야할 거 같아.

그리고 어듬션 오면 쏘는거 잊지마라. 나 무척 수고했다. ㅋㅋ 알지?