미리 협박해 두기 --------
예전 글에서 넘버2원칙을 설명한 적이 있었는데, 이는 나만의 신조어이다. 이번에 설명할 삽질지수도 오로지 나의 생각에 의한 발명품이다. 후일, 넘버2원칙이든 삽질지수이든, 이 개념을 자신이 발명한 것이라고 우기는 나쁜 인간들이 등장한다면, 세일러문을 불러서 정의의 이름으로 용서하지 않을 것임을 미리 밝혀 두겠다. 이 용어를 사용할 때 나에게 저작료를 낼 필요는 없지만, 본인이 만든 것이라고 거짓뿌렁을 일삼지는 말아 주기를 미리 부탁드린다.
미리 협박해 두기 끝 ------
경제관련 지수 중에서 엥겔 지수라는 것이 있다. 엥겔 지수란 한 가정의 총수입에서 식비 비율을 말한다. 식비란 먹는 것을 구입하는 비용이다. 신선이 아닌 한 굶고 살지는 못할 것이므로, 식비는 삶을 영위하는 최소한의 기본 경비이다. 따라서 엥겔지수가 높다 즉 총수입에서 식비 비율이 높다는 것은 가난한 가정임을 의미한다.
그런데, 프로그램 개발에서도 이 엥겔 지수 비슷한 개념이 있다. 나는 이 지수를 삽질 지수라고 한다. 삽질 지수의 정의는 다음과 같다.
삽질 지수 == 총 코딩 시간 / 총 개발시간 == 총 개발시간 중에서 직접 코딩하는 시간의 비율.
삽질 지수가 높을 수록, 즉 직접 코딩 시간 비율이 높을 수록 하수이다. 그 반대 즉 삽질 지수가 낮을 수록, 직접 코딩 시간 비율이 낮을 수록 고수라는 말이 된다. 왜 그럴까?
하수일수록, 클래스를 어떻게 설계하고 메서드를 어떻게 구현할지 구상(디자인)하기 보다는, 키보드 앞에서 직접 두들기기(코딩)를 좋아한다는 것이다. 고수일수록 클래스와 메서드를 미리 치밀하게 설계하고 코딩에 임하기 때문에 실제 코딩하는 시간의 비율이 적다는 것이다.
이와 비슷한 맥락으로, 코드 컴플리트란 책을 보면, 컴파일을 너무 서두르지 말라, 즉 한줄 바꿔보고 바로 컴파일하고 실행하는 성급함을 버리라는 글이 있다. 컴파일 하기 전에 작성한 코드를 머리속으로 돌려보고, 원래 디자인(설계)한 것과 일치하는지 점검해 보라는 것이다.
C, C++계열의 컴파일러들은 컴파일 속도가 상당히 느리므로 자주 성급하게 컴파일하면 개발 시간을 매우 낭비할 수 있지만, 델파이처럼 컴파일 속도가 무지 빠른 개발툴은 빈번한 컴파일 때문에 개발 시간을 낭비하는 비율은 적다고 할 수 있다. 그러나 코드 컴플리트에서 말하는 철학을 어느 정도 따를 필요는 있다. 코드 컴플리트의 컴파일을 너무 성급하게 하지 말라는 의미인즉, 코드 작성에 대해서 신중하란 것이다.
고수와 하수의 코드를 비교해보면 코드 작성에서 얼마나 신중했는지 얼마나 깊은 설계 철학이 들어가 있는지 확연히 드러난다. 명칭 작성의 원칙, 인덴트의 원칙, 알고리즘 구현시 단순명료함, 소스 파일 분리의 원칙, 결합과 분리의 원칙 등등 모든 면에서 고수의 코드와 하수의 소스 코드는 풍기는 냄새가 확연히 다르다.
같은 이유로 인해서 하수와 고수의 디버깅 방법은 사뭇 다르다. 훈민정음을 보면, "나랏 말쌈이 즁국과 사맏지 아니할새"라는 글이 있는데, 중국과 한국어 차이 이상으로 고수와 하수의 디버깅 방법은 확연한 차이가 있다.
디버깅시 여러 차이점이 있지만, 대부분의 경우 고수들은 신중히 코드를 분석한 다음 고쳐야할 곳에만 신중히 수정하는 반면에, 하수들은 소스의 이곳저곳에 마구 코드를 끼워넣고 삭제하길 반복하다가 우연히 버그가 사라지면 디버깅이 되었다고 믿어 버린다. 이말인즉 하수는 고쳐놓고도 왜 고쳐졌는지 이유를 모른다는 것이다.
귀하의 삽질지수는 얼마나 되는가? 생각해보니 나의 삽질 지수도 상당하여 빈곤한 개발자, 즉 하수에 속함을 굳이 부인하지는 않겠다.
|
개발시간에서 코딩이 차지 하는 비중을 가지고 고수와 하수로 구분한다 의미의 개념을 주정섭님이 발명한 것이라고 하시는것은 좀 문제가 있다고 생각합니다.
어느정도 수준이 되는 개발자라면 누구나 그런 생각을 가지고 있습니다. 즉 그런 개념은 대부분의 개발자가 이미 다 알고 있는 상황이란것이죠.