웹서핑하다가 우연히 들른 사이트에서 “프로그래머가 되는 법”이라는 약간은 황당한 제목의 문서를 발견하였다. 원문은 Robert L. Read라는 사람이 썼고 위키에 번역되어 있다. 아직 모두 읽지는 않았지만(2/3정도 읽었다) 프로그래머가 한번쯤은 생각하고 넘어가야 할 것 같은 토픽들에 대해서 다루고 있어서 아는 프로그래머들에게 권하고 싶은 문서다.

이 문서에서 다루고 있는 토픽들 중 재미있는 내용이 있는데…

이런 상황이 아니면 집에가지 말라는 소리는 아니겠지? ㅋㅋ

그리고 제닉스군은 문서의 3.3.3절을 보게나 :p

Aaron Skonnard와 Grady Booch

크기가 크고 복잡한 문제를 해결하기 위한 방법으로 문제를 작은 단위로 나누어 해결하자는 것이 Divide and conquer이다. 나누어 해결한다는 원칙은 이 뿐만이 아니라 여러 문제를 동시에 해결하는 데도 유효한 원칙인 듯 하다.

여러 작업을 동시에 처리하기 위해 짧은 시간에 쉽게 처리할 수 있는 더 작은 단위의 작업으로 나누고 나누어진 작은 작업들을 우선순위를 정해 작업목록에 적당히 서로 끼워 넣어 하나씩 해결해 나가면 마치 여러가지 작업을 동시에 처리하는 것처럼 보인다. 비선점형(non-preemptive) 방식의 멀티테스킹 OS 처럼.

이 때 적당한 크기로 작업를 나누는 것이 중요하다. 너무 크게 나눠진 작업는 새로 추가된 더 작은 작업들에 의해 우선순위가 계속 밀리게 되고 나중에는 기한 내에 처리하기 어려워지는 상황이 되기 쉽다. 더 짧은 시간에 처리할 수 있는 작업이 선호되기 때문이다.

또, 동시에 진행해야 할 작업이 많을 수록 더 작은 크기로(더 짧은 시간에 처리할 수 있는 크기로) 나눠야 한다. 그래야만 여러 작업들이 동시에 진행되고 있는 것 처럼 보이게 될 것이다.

문제는 작게 나눠진 작업들을 오가며 처리할 때 생기는 문맥 변경(context change)에 따른 오버헤드이다. 작업을 더 잘게 나누게 되면 더 잦은 문맥 변경으로 이에 따르는 오버헤드 또한 증가하게 된다.

여러 작업을 동시에 처리하게 될 때 이런 오버해드를 고려해야 하는 것은 작업을 지시하는 사람이나 작업을 수행하는 사람이 염두해 두어야만 하는 것이다.

하지만 쉽게 잊게 된다. -_-;

스트래스 풀 길없는 코더에게는 이런식의 커멘팅 방식이 도움이 될거 같다.

어쩌면 코딩 생산성 향상으로 이어질 지도.. ㅋㄷ

ps) 윈도우 코딩 하면서 쌓인게 많았나? …

나와 다른 코딩 컨벤션

나와 다른 네이밍 스타일

나와 다른 플로우

나와 다른 설계 방식

…

이런 것들 때문에 남 코드 보는거 굉장히 불편하다.

남이 만든 코드를 보는게 도움이 많이 된다는 걸 알지만 서도…

어제 어찌어찌하여 코드리뷰할 기회가 있었는데…

inheritance와 composition으로 클래스와 객체가 주렁주렁 이쁘게 메달린 설계.

간략하고 깔끔한 코딩 스타일.

만든 사람의 친절한 설명.

마치 DP에 나오는 샘플 코드를 보는 듯해서 기분 좋은 코드리뷰가 될 수 있었다.