아름다운 네트웍 세상 since 1996.

올바른 코딩 습관에 대한 메모.   2006.04.17 From Xevious7
http://www.xevious7.com

프로그래밍이란 것을 공부하면서 프로그래머로써
시간을 보내면서 수많은 책을 읽었습니다. 스스로 깨달은 것 그리고
선배들의 조언 교수님의 조언 그리고 후배들의 생각들
그리고 그루(guru)들의 생각들  통신상의 생각(opinions) 등등...

첫번째로 그리고  나 스스로도 동의했던 가장 올바른 코딩 습관은
어떤 기능의 모듈을 직접 코딩을 하기전에 며칠이고 충분히 고민해서
즉 큰 디자인을 먼저하고 작은 것을 만들라는 것이었습니다.
그렇게 하지 않으면 그 코드는 금새 수없이 고쳐야 할것이고
나중에는 너덜너덜한 복잡한 코드가 된다는 것이었습니다.

프로그래밍 과제가 나온 시점에 이미 코드의 라직은 머리속에 들어가있었지만
이런 훈련을 하기 위해서 과제를 내기 3시간 전까지도 코드를 생각했었습니다.

그러한 코딩 습관은 졸업후에도 계속 되었고 그것은 때때로 사람들의
많은 오해를 불러일으켰습니다. 10일 생각하고 3시간 타이핑 하는 사람을
학교가 아닌 직장에서 이해하기는 힘든일이니깐 말입니다.

그래서 나는 코딩을 하지 않는 시간에도 비주얼 스튜디오를 일부러
띄어놓고 있어야 하였습니다. 이렇게 말하니 내가 마치 무슨 천재가 된것
같이 보일수 있겠지만 다만 습관일 따름입니다.

한 5개월 생각하고 1개월 코딩하고 5개월 테스팅 하면 1년안에 할
프로젝트를  1개월마다 코딩 진행상황 체크하고 2개월 마다
프로토타입을 만들고 3월마다 데모를 보여주니 이거원 1년에 끝낼
프로젝트를 3-4년을 끌고 가더군요.

최고 관리자한테 직접 말하기도 하면서 설득을 하여보았지만
현장 이라는 말 한마디로 묵살이 되더군요. 1년이면 거의 완벽한
프로그램이 나올텐데  3-4년이 지나도 버그 고치기 급급한
프로그램을 보면서 아연 실색할 수 밖에 없었습니다. 학교에서
배우고 읽었고 해왔던거와는 너무나 틀렸었거든요.

그래서 지금은? 하지만 지금도 안타깝게도 저는 머리속으로 열심히
디자인 하면서 SSH 셀을 뛰워놓고 코딩하고 있는척 해야 됩니다.

게다가 회사의 반절은 회의입니다. 그리고 또 그 반절은 관리작업을 해야됩니다.
하지만 회의와 관리작업만으로도 월급을 받는다고 위로 해보기도 합니다만
가끔은 코드를 집어넣으면 돈이나오는 자판기가 있으면 하는 생각을
해봅니다. 그렇게 하면서도 회사는 멋찌고 잘 돌아가는 프로그램을
원합니다.

블로그 글에서도 밝혔지만 '학이시습지' 복습은 학습에서 가장중요한
것중에 하나입니다. 그리고 멋찐일이죠.

어찌되었든 내가 생각했던 그런 코딩습관 즉 큰 디자인후에 세세한 코딩은
저 뿐만 아니라 다른 많은 책에서 그리고 선배들이 그리고 후배들이 주장하는
코딩방법입니다.

1999년 9월에 한때는 99년 9월은 멸망을 할 달이라고 했었지만 전 그때
이런책을 공부하고 있었군요.

Real Time Strategy programming using Direct X 6.0
이책은 앙상블스튜디오 (에이지오브 엠파이어 시리즈를 만든 회사)의 프로그래머
미키 카윅(Mickey Kawick)이 쓴 책이었습니다.
인터넷 쇼핑으로 아마존닷컴에서 신용카드로 나오자 마자 샀던 책이었습니다.
그당시에 아마존닷컴에서 물건사면 약 8주정도 걸렸습니다. ㅠ.ㅠ
거의 2달이지만 현재와 같은 인터넷 시대가 아니었습니다. 쇼핑몰 태동기였으니깐요.

그책에서 이런 글귀를 보고 힘을 얻었었습니다. 역시 나랑 같은 생각을 하는사람들이
이렇게 있지 않는가 말이지요.

Do not create code that you'll need to change often ;
Stick to the C++ ideal of centralizing code.

여러분이 자주 바꿀 코드를 만들지 말라. 집중적 코드의 C++이상을 고수하라!

Create function to do a whole bunch of things rather than recoding that
functionality every time you need it.

필요할때 마다 새로 코딩을 하는 대신 전체적인 일을 처리할 수 있는 함수를
만들어라.

Centralizing code is key to writing less code and having less volatile code.
집중적 코드는 적게 코드를 작성하고 필요없는 코드를 적게 가질 수 있는
해법이다.

Data-driven code is harder to write but well worth the effort.
데이타중심 코드는 작성하기는 매우 어렵지만 노력한 만큼 가치가 있다.

마지막 줄의 말은 그전까지의 절차적 논리만을 더 많이 사용했던 저에게
상당히 많은 코딩습관을 변하게 했습니다. 그 이후로 약 5년 정도는
데이타흐름 중심을 가지고 코딩을 하였기 때문입니다.

한가지 더 말씀 드리고 싶은 것은  이러한 코딩방법 즉 많이 생각하고 충분히
고려해서 제대로 된 설계를 한 후에 작성하는 프로그래밍 방법은
참 좋은 방법이지만 한 방법일 뿐입니다. (물론 저는 이 방법을 선호하는 사람입니다.)

타이밍 그리고 속도 또는 선점이 중요하다고 생각하는 경우라면
일단 프로토타입을 만들고 계속 수정해가는 형태의 방법도 가끔은 필요합니다.
하지만 어디를 손대야 될지 모를정도로 진행되었을때는 정말 곤란해집니다.

이 문제에 대해서는 아직도 많은 프로그래머사이에 논쟁 거리에 있다는 사실을
알아두시기 바랍니다.
어느쪽에 서는냐를 생각하시는분도 있을지 모르겠지만 어느쪽에 서는냐가 중요한
것이 아니라 생각합니다.  

이런방법도 있다라는 것이지요.

From Xevious7