출처 : 데브피아(조휘경님 글)
소프트웨어 공학의 주된 주제다. 학자들이 먹고 살자고 구조적 프로그래밍, 객체지향 프로그래밍, 최근에 UML, CBD(콤포넌트 기반) 프로그래밍 말이 바꿔가며 머리 아프게 하지만, 목적은 효과적인 개발이 무엇인가에 대한 고민일 것이다.
학교서 공부도 하고, 서적도 뒤적여 보고 눈을 크게 뜨고 변화의 흐름을 읽어야 할 것이다. 그런데, 문제는 실무에서 정작 중요한 것은 학문적으로 다뤄지지 않는다는 것이다. 왜냐하면 그건 논문으로 발표할 수 있는 주제가 아니지 않은가 ? 그것들이 무엇일까 ?
1. 문서를 잘 만드는 사람이 프로그래밍을 잘한다.
길지 않은 문장으로 쉽게 이해시킬 수 있는 능력, 남들이 쉽게 알아볼수록 문장을 잘 정리하는 능력, 눈에 띄게 문서를 만들 줄 아는 능력 등을 지닌 사람들이 프로그래밍을 잘한다. 결국엔 프로그램은 타이핑의 부산물이기 때문이다.
처음 코딩량이 적을 때는 쉽게 알 수 있지만 늘어나면 자기 자신도 못 알아보는게 다반사이다. 헝가리안 표기법을 반드시 지키며, 깔끔하고 알아보기 쉽게 만드는 것은 결국 미래의 자기 자신을 위해서다.
또 하나 중요한 것은 문서들을 잘 정리정돈 하는 것이다. 각 주제별로 잘 정리하는 시간을 절대 아까워해서는 안된다. 특히, 같은 문서는 중복되서 존재하지 않게 유지하는 것이 중요하다. DLL, LIB 파일들이 중복되어 난무해서 헤매게 되는 경우를 숫하게 봐왔기 때문이다.
2. 대부분의 문제는 누군가 고민했던 문제이다.
프로그래밍을 하다 보면 수많은 문제에 직면하게 된다. 그러한 문제 중 대다수는 이미 과거에 누군가 고민했던 문제이다. 따라서, 당면한 문제의 크기에 관계없이 혼자 삽질하지 말고 미리 찾아봐야 한다.
문제를 정확하게 파악하고 요구되는 사항을 분석하며 관련 자료를 개발하기 앞서 미리 수집해야 한다. 간과해서는 절대 안되는 것은 여기까지 즉, 자료 수집까지가 전부이다.
혹자는 그것이 문제를 해결해 줄 것처럼 착각한다. 후임에게 문제를 맡겼을 때 가장 깝깝한 대답이 인터넷에서 찾아봤는데 방법이 없다는 것이다. 온갖 다른 사람들이 고민한 흔적이 있는 자료는 삽질하지 않기 위한 참고일 뿐이다. 그 다음부터는 자신의 몫인 것이다.
3. 효율적인 프로그래밍 작업 환경을 구축한다.
다음 주제로 다뤄질 부분으로 하루 이틀 코딩할 것도 아닌데 미래를 위해 항상 가장 효율적이라고 생각되는 작업 환경을 구축해 놓아야 한다는 것이다. 참고로, 나의 Visual Studio 에는 툴바가 없다. 툴바는 시간을 빼앗는 가장 큰 적이다. 따라서, 모두 핫키 처리해야 한다. 또한, 스튜디오에서 제공하는 편리한 기능들, 디버그 기능들은 미리 숙지 해야 하고, 에디터도 자신이 좋아하는 스타일로 미리 바꿔 놓아야 한다.
프로젝트별로 각 기능별로 파일들을 분류하는 것도 중요하다. 예를 들어 헤더 파일은 include 폴더에, 라이브러리 파일은 lib 폴더에, 프로젝트를 위한 툴을 담은 구현파일들은 Tool 이라는 폴더에 위치시켜 척 보면 무엇을 위한 파일들인지 가늠되어야 한다. 특히 라이브러리에 관련된 위치는 분명하게 하여 라이브러리 소스를 변경해도 실행 파일에는 반영되지 않아 헤매는 일은 없어야 한다.
4. 잦은 컴파일과 실행을 통한 문제해결로 결코 문제는 해결되지 않는다.
개발자는 타이핑의 수고스러움을 결코 아껴서는 안된다.
가장 바보스러운 코딩은 클래스 뷰에서 멤버변수 만들고, 함수 만들고, 클래스 위자드에 있지 않은 메시지나 오버로드 함수 아니면 없다고 믿는 것이다. 개발자의 길을 걷겠다고 결심했다면 처음 해야 할 것은 개발자를 바보 만들기 위해 존재하는 스튜디오의 위자드 없이 조그마한 것이라도 직접 타이핑으로 작성해 보는 것이다.
다음으로 어떤 문제에 부딛히면 수없이 많은 컴파일과 실행을 남발하여 문제를 해결하려 해서는 안된다는 것이다. 변수 값을 하나 하나 바꿔가며 컴파일해서 문제를 해결했다면, 다음에 같은 문제에 부딛히게 되면 그 해결 방법은 컴파일뿐이다. 즉, 그 문제에 대한 해답을 모르는 것이다. 철저히 분석하고 원인을 규명하여 내 것으로 소화하고자 하는 노력이 요구되는 부분이다. 너무나 당연한 것이지만 어렵게 얻은 것은 결코 쉽게 잊혀지지 않는다.
5. 미래 지향적인 프로그래머가 되자.
프로그래밍의 기본 규칙 중에 하나가 “만들때는 어렵게, 사용할때는 쉽게” 이다. 어떤 기능을 수행하는 함수를 만들 때 이 함수를 사용하기 편리하게끔 만들어야 한다. 그냥 귀찮아서 코딩한 결과는 고스란히 다시 찾아와 더 귀찮게 만든다. 함수를 세분화 하고 명료화하는데 귀찮아해서는 안된다.
그리고 함수나, 클래스, 구조체, 프로토콜 등을 정의할 때 항상 미래를 염두에 두어야 한다. MS 의 코드들을 살펴보면 예약된 변수가 난무한다. 이러한 대비는 미래에 아주 유용하게 사용된다.
다음으로 굳이 성능에 연연할 필요가 없다는 점이다. 성능을 상당히 요구하는 복잡한 알고리즘이나 프로세스를 개발하지 않는 한 별로 신경 쓸 일이 아니다. 오히려 그 노력을 코드의 명료성, 확장성, 재사용성 등에 투자하는 것이 현명하다. 예전 도스시절 레지스터 변수, 재귀함수, GOTO문, 포인터에 포인터 등 온갖 알기 어렵게 구현해야 코딩 잘하는 사람으로 취급 받던 시절이 있었다. 하드웨어의 발전속도는 소프트웨어보다 월등히 빠르다. 그런 문제는 하드웨어가 해결해 줄 것이다.
이상으로 제가 개인적으로 실무에서 느끼는 점을 정리해 보았습니다. ^^
틀린 부분이나 개발 생산성과 관련된 여러가지 의견들 마구 마구 리플 달아주세요. 좋은 생각이나 경험은 서로 공유할 때 배가 됩니다. ^^*
다음엔 제가 알고 있는 효율적인 프로그래밍 환경 셋팅 방법에 대해 알아보겠습니다…
소프트웨어 공학의 주된 주제다. 학자들이 먹고 살자고 구조적 프로그래밍, 객체지향 프로그래밍, 최근에 UML, CBD(콤포넌트 기반) 프로그래밍 말이 바꿔가며 머리 아프게 하지만, 목적은 효과적인 개발이 무엇인가에 대한 고민일 것이다.
학교서 공부도 하고, 서적도 뒤적여 보고 눈을 크게 뜨고 변화의 흐름을 읽어야 할 것이다. 그런데, 문제는 실무에서 정작 중요한 것은 학문적으로 다뤄지지 않는다는 것이다. 왜냐하면 그건 논문으로 발표할 수 있는 주제가 아니지 않은가 ? 그것들이 무엇일까 ?
1. 문서를 잘 만드는 사람이 프로그래밍을 잘한다.
길지 않은 문장으로 쉽게 이해시킬 수 있는 능력, 남들이 쉽게 알아볼수록 문장을 잘 정리하는 능력, 눈에 띄게 문서를 만들 줄 아는 능력 등을 지닌 사람들이 프로그래밍을 잘한다. 결국엔 프로그램은 타이핑의 부산물이기 때문이다.
처음 코딩량이 적을 때는 쉽게 알 수 있지만 늘어나면 자기 자신도 못 알아보는게 다반사이다. 헝가리안 표기법을 반드시 지키며, 깔끔하고 알아보기 쉽게 만드는 것은 결국 미래의 자기 자신을 위해서다.
또 하나 중요한 것은 문서들을 잘 정리정돈 하는 것이다. 각 주제별로 잘 정리하는 시간을 절대 아까워해서는 안된다. 특히, 같은 문서는 중복되서 존재하지 않게 유지하는 것이 중요하다. DLL, LIB 파일들이 중복되어 난무해서 헤매게 되는 경우를 숫하게 봐왔기 때문이다.
2. 대부분의 문제는 누군가 고민했던 문제이다.
프로그래밍을 하다 보면 수많은 문제에 직면하게 된다. 그러한 문제 중 대다수는 이미 과거에 누군가 고민했던 문제이다. 따라서, 당면한 문제의 크기에 관계없이 혼자 삽질하지 말고 미리 찾아봐야 한다.
문제를 정확하게 파악하고 요구되는 사항을 분석하며 관련 자료를 개발하기 앞서 미리 수집해야 한다. 간과해서는 절대 안되는 것은 여기까지 즉, 자료 수집까지가 전부이다.
혹자는 그것이 문제를 해결해 줄 것처럼 착각한다. 후임에게 문제를 맡겼을 때 가장 깝깝한 대답이 인터넷에서 찾아봤는데 방법이 없다는 것이다. 온갖 다른 사람들이 고민한 흔적이 있는 자료는 삽질하지 않기 위한 참고일 뿐이다. 그 다음부터는 자신의 몫인 것이다.
3. 효율적인 프로그래밍 작업 환경을 구축한다.
다음 주제로 다뤄질 부분으로 하루 이틀 코딩할 것도 아닌데 미래를 위해 항상 가장 효율적이라고 생각되는 작업 환경을 구축해 놓아야 한다는 것이다. 참고로, 나의 Visual Studio 에는 툴바가 없다. 툴바는 시간을 빼앗는 가장 큰 적이다. 따라서, 모두 핫키 처리해야 한다. 또한, 스튜디오에서 제공하는 편리한 기능들, 디버그 기능들은 미리 숙지 해야 하고, 에디터도 자신이 좋아하는 스타일로 미리 바꿔 놓아야 한다.
프로젝트별로 각 기능별로 파일들을 분류하는 것도 중요하다. 예를 들어 헤더 파일은 include 폴더에, 라이브러리 파일은 lib 폴더에, 프로젝트를 위한 툴을 담은 구현파일들은 Tool 이라는 폴더에 위치시켜 척 보면 무엇을 위한 파일들인지 가늠되어야 한다. 특히 라이브러리에 관련된 위치는 분명하게 하여 라이브러리 소스를 변경해도 실행 파일에는 반영되지 않아 헤매는 일은 없어야 한다.
4. 잦은 컴파일과 실행을 통한 문제해결로 결코 문제는 해결되지 않는다.
개발자는 타이핑의 수고스러움을 결코 아껴서는 안된다.
가장 바보스러운 코딩은 클래스 뷰에서 멤버변수 만들고, 함수 만들고, 클래스 위자드에 있지 않은 메시지나 오버로드 함수 아니면 없다고 믿는 것이다. 개발자의 길을 걷겠다고 결심했다면 처음 해야 할 것은 개발자를 바보 만들기 위해 존재하는 스튜디오의 위자드 없이 조그마한 것이라도 직접 타이핑으로 작성해 보는 것이다.
다음으로 어떤 문제에 부딛히면 수없이 많은 컴파일과 실행을 남발하여 문제를 해결하려 해서는 안된다는 것이다. 변수 값을 하나 하나 바꿔가며 컴파일해서 문제를 해결했다면, 다음에 같은 문제에 부딛히게 되면 그 해결 방법은 컴파일뿐이다. 즉, 그 문제에 대한 해답을 모르는 것이다. 철저히 분석하고 원인을 규명하여 내 것으로 소화하고자 하는 노력이 요구되는 부분이다. 너무나 당연한 것이지만 어렵게 얻은 것은 결코 쉽게 잊혀지지 않는다.
5. 미래 지향적인 프로그래머가 되자.
프로그래밍의 기본 규칙 중에 하나가 “만들때는 어렵게, 사용할때는 쉽게” 이다. 어떤 기능을 수행하는 함수를 만들 때 이 함수를 사용하기 편리하게끔 만들어야 한다. 그냥 귀찮아서 코딩한 결과는 고스란히 다시 찾아와 더 귀찮게 만든다. 함수를 세분화 하고 명료화하는데 귀찮아해서는 안된다.
그리고 함수나, 클래스, 구조체, 프로토콜 등을 정의할 때 항상 미래를 염두에 두어야 한다. MS 의 코드들을 살펴보면 예약된 변수가 난무한다. 이러한 대비는 미래에 아주 유용하게 사용된다.
다음으로 굳이 성능에 연연할 필요가 없다는 점이다. 성능을 상당히 요구하는 복잡한 알고리즘이나 프로세스를 개발하지 않는 한 별로 신경 쓸 일이 아니다. 오히려 그 노력을 코드의 명료성, 확장성, 재사용성 등에 투자하는 것이 현명하다. 예전 도스시절 레지스터 변수, 재귀함수, GOTO문, 포인터에 포인터 등 온갖 알기 어렵게 구현해야 코딩 잘하는 사람으로 취급 받던 시절이 있었다. 하드웨어의 발전속도는 소프트웨어보다 월등히 빠르다. 그런 문제는 하드웨어가 해결해 줄 것이다.
이상으로 제가 개인적으로 실무에서 느끼는 점을 정리해 보았습니다. ^^
틀린 부분이나 개발 생산성과 관련된 여러가지 의견들 마구 마구 리플 달아주세요. 좋은 생각이나 경험은 서로 공유할 때 배가 됩니다. ^^*
다음엔 제가 알고 있는 효율적인 프로그래밍 환경 셋팅 방법에 대해 알아보겠습니다…
'볼거리, 읽을거리, 놀거리' 카테고리의 다른 글
| 캐럿보이넷 :: DirecDraw (0) | 2004.11.30 |
|---|---|
| 캐럿보이넷 :: 개발-넷) 자신만의 클래스를 정의하자. (0) | 2004.10.29 |
| 캐럿보이넷 :: [리눅스] 네트웍/인터넷 관련 툴 사용법 (0) | 2004.10.23 |
| 캐럿보이넷 :: 진정으로 잘 사는 도시인 10계명 (0) | 2004.10.22 |
| 캐럿보이넷 :: Visual C++ 단축키(퍼옴) (0) | 2004.10.22 |