생각하고 기록하고 코딩하기.

생각을 정리하는 데 종이와 연필만한 것은 없는 것 같습니다.

마인드 맵도 상당히 쓸만합니다만, 마우스와 키보드가 연필만큼 빠르게 생각의 기록을 해내진 못합니다. (마우스가 원래 만들어진 목적이 사용자 입력을 지연시키는 것이었으니 어찌보면 당연하지요.)

연필은 순서도, 클래스 다이어그램, 시퀀스 다이어그램, ER다이어그램 등 그리지 못하는 것이 없습니다. 아주 똑똑하고 숙련된 개발자는 PC 앞에서 슥슥 그려서 모든 설계를 끝내기도 하지만, 저는 이 싸고 좋은 도구를 선호하는 편입니다(물론 팀에 배포할 때는 비지오와 워드를 이용해서 정리를 합니다!).

OMCS 증후군으로 아십니까? OMCS는 One More Compile Syndrom, "한번만 더 컴파일! 증후군"입니다. 코드를 작성하고 나서 컴파일해서 실행해 보고, 컴파일해서 실행해 보는 방식으로 프로그램을 만드는 프로그래머들을 본 적이 있다면, 이 병에 걸려있다고 보시면 됩니다(뜨끔?).

자신이 작성해야 하는 로직을 완벽하게 설계를 해놓지 않고(설계가 필수적인 것은 아닙니다. 당신의 두뇌가 기억을 잃지 않는 비휘발성이라면 말이죠.), 또는 이해가 불충분한 상태에서 프로그래밍을 하게 되면 프로그램은 "당연히" 원하는 결과를 내놓지 않습니다. 설사 운 좋게 원하는 결과가 나온다 하더라도 조금만 파라미터를 달리 주면 엉뚱하게 동작하는 경우가 대부분이죠.

이제 컴파일과 링크가 끝나고 최초의 실행 파일(또는 웹페이지)이 생겼습니다. 프로그래머는 이 프로그램에 입력값을 바꿔 주어가며 테스트를 합니다. 당연히 에러가 나고 프로그램이 죽기도 합니다. 그리고 각 입력값에 대해 If 문으로 예외 처리를 하기 시작합니다. 테스트가 진행되면 진행될 수록 if를 이용한 예외 처리가 늘어납니다. 상황은 악화되어서, 어느 순간부터는 앞에 작성한 코드를 왜 그렇게 만들어 놨는지 기억이 나지 않습니다. 그렇다고 코드를 간소화 하자니 답이 안 나옵니다. (이런 코드는 여러 사람의 만수무강에 지장을 줍니다.)

연필을 이용해서 로직을 설계 해봤다면 어땠을까요? 해당 로직이 가질 수 있는 경계값(최소/최대) 파라미터, 일으킬 수 있는 예외, 호출자가 해당 로직으로부터 알고 싶어할 결과 등등을 노트에 차근차근 기록했다면 말입니다.

사람은 완벽하지 않습니다. "완벽하지 않다"보다 오히려 "실수 투성이다"라는 표현이 더 어울리지요. 따라서 설계에도 실수가 있을 수 있습니다. 하지만 코딩하고 컴파일을 반복하는 횟수(그 절반만이라도)만큼만 설계에 공을 들인다면 설계의 완성도는 올라가고, 코딩의 고통(?)은 훨씬 줄어들 것입니다.

연필이 마음에 안든다고요? 도구는 상관없습니다. 저는 펜보다 HWP가 더 자유로운 행정병 출신 프로그래머들도 여럿 봤습니다(키보드 만으로 사무실 책상 배치도를 그리는 모습을 봤는데, 경악스럽더군요.). 생각하고 코딩하라는 이야기를 보통 많이들 합니다만. 저는 이 말에 뭔가 빠졌다고 생각합니다.

생각은 휘발성이기 때문에 코딩하면서는 그 수많은 생각들이 4차원 세계로 날아가버리지요. 종이든, 파일이든, 또는 양쪽이든, 생각을 기록한 후에 코딩을 시작해 보세요. 매 프로젝트가 끝날 대마다, 여러분은 고민과 사유 과정이 담긴 노트를 하나씩 얻게 될 것입니다.

07.9.17 19:10 추가.
- (거창한)소프트웨어의 설계에 대한 실용성에 의심을 하고 계신 분이나, 거창하게 UML 툴을 열어놓고 고민하는 시간이 많다면, 이 방법을 적극 추천해 드립니다.

- 이 노트는 제가 전에 다니던 회사의 팀장님께 배운(?) 겁니다. 팀장님께서는 항상 노트(이렇게 설계가 담긴 노트를 애지중지 하셨더랬죠. ㅋㅋ)에 소프트웨어 설계를 하셨는데(공유해야 하는 내용은 항상 전자 문서화해서 배포하셨습니다.), 팀장님께서 작성하신 코드는 버그가 드물었던 기억이 납니다. (물론 안전하고 성능이 좋은 코드를 위한 장치를 라이브러리 레벨에서 많이 준비해 놓으신 이유도 한 몫 했을 겁니다.)