프로그래밍(코딩)을 잘하고 싶다면 (나만의 개발자 십계명+1) - 2004/7/9

0. 웬만하면 코딩부터 시작하지 말 것. 종이나 워드프로세서에 설계를 먼저하자. (UML 툴을 이용해도 좋다. 하지만 적당히...) 설계에 시간 투자를 하지 않고 코딩부터 시작하면 그만큼의 후회가 늘어간다.  돌이킬 수도 없다.

 

1. 객체 지향 기반과 비객체 지향 기반을 섞어서 잘 활용하라. 하지만, 자신이 없다면 무조건 객체지향으로 프로그래밍하는 것이 낫다.

 

2. 함수 하나가 200줄을 넘지 않게 해라. 웬만하면 100줄 정도 선에서 끝내길 권한다.

 

4. Visual C++에서 말이다. 자신이 라이브러리처럼 가져다 쓸 코드라면 절대로 stdafx.h를 인클루드하지 말아라. 플랫폼에 종속되지 않는 당신이야 말로 진정한 프로그래머다.

 

5. 함수나 클래스, 변수들의 이름을 지을 때는 웬만해서 그 이름만으로도 의미가 전달되도록 짓는다. 예를 들어 'CheckToDemandModeling(), AzimuthCompressor' 등과 같이 이름이 아무리 길어도 상관 없으니 의미 전달을 확실하게 하도록 한다. 너무 길면 프로그래밍하기 힘들다고? 우리에게는 최강의 개발 툴이 있다. 걱정은 접어두어도 좋다.

 

6. 위의 몇가지 방법대로 프로그래밍을 했다면 웬만해선 주석을 달지 말 것. 어셈블리어나 기계어 코드가 아닌 이상, 주석을 많이 다는 것이 이젠 더이상 미덕이 되지 못한다.

 

7. 내가 생각하는 최상의 주석 달기는 비율을 따진다면 1000줄에 2줄 정도다. (구문에 따라서 유연하게 대응하는 것이 가장 좋겠지....) 주석 다는데 정력을 소비하지 마라.

 

8. 이론보다 실습이 더 중요하다? 아주 허튼 소리다. 이론과 실습의 portion은 딱 50:50이다. 프로그래밍 이론이나, 프로그래밍 언어의 매뉴얼을 완전히 자기 것으로 소화하기 바란다.

 

9. 남에게 묻거나, 자료를 찾거나, 남의 소스를 가져다 쓰는 것을 절대 부끄러워하지 말자.

 

10. 자신의 코드를 다른 사람이 넘겨 받았을 때, 분석이 용이하도록 노력을 하는 것이 좋다. 항상 인수인계를 염두에 두고 개발을 한다면 결국 본인에게 가장 큰 도움이 될 것이다.

 

네이버 블로그와 통합한 글

 

- First 2004. 7 .9 

  . 겁 없던 시절, 혀(손?)에 칼을 품고 내질렀던 나의 개발 원칙 (이 리비전은 사라짐 :)

 

- Revision 2012. 3. 27 

  . 문체와 내용을 조금 다듬었다. 너무 철없을 때 쓴 글이라 7년이 지난 지금 다시 봐도 꽤 의미 있는 내용임에도 불구하고, 너무 공격적이고 냉소적인 문체 때문에 본인에게도 설득력이 떨어져 보였다.

 

- Review 2020. 1. 30 

  . 2004년에 최초 작성하였으니, 15년이 넘게 되었다. 오랜 시간이 흐른 지금 다시 읽어봐도 위화감이 없는 것으로 보아 프로그래밍 철학만큼은 오래 전에 정립이 되었다는 생각이 들어 아주 약간의 자부심이 생겼다.