[chap 1~10] 좋은 프로그래밍 습관 요약

[ 001 ] - 모듈 ∙ 인터페이스 등을 확실하게 정의한 후 시작하자.

프로그래밍을 시작하기 전에 프로젝트에 참여하는 다른 프로그래머들과 충분히 의논하고 인터페이스를 확인하는 작업을 반드시 거쳐야 합니다.

 

[ 002 ] - 상태별로 제어하는 습관을 기르자.

실제 기업체나 연구소에서 상태 제어 프로그래밍 방법을 이용하여 실무가 이루어지고 있으므로 상태별로 제어하는 습관을 기르는 것이 중요합니다. 대부분의 프로그램은 여러 상태(status)로 이루어져 있고 각각의 상태를 제어하는 것은 일반적인 프로그래밍 방법 가운데 하나입니다.

 

[ 003 ] - 일어날 수 있는 모든 입출력을 점검하자.

프로그램을 설계할 때에는 일어날 수 있는 모든 입출력을 점검해야 합니다. 전체 몇 가지의 경우의 수가 일어날 수 있는지 확인하고, 어떤 경우에만 해당하는 사항인지 아니면 모든 경우에 대해서 대응해야 하는지 점검해야 합니다.

 

[ 004 ] - 프로젝트의 단계를 하나씩 밟자.

① 전체적인 구조 파악 ② 세부적인 알고리즘 검토 ③ 실제 구현 ④ 디버깅과 수정   각 단계 가운데 어느 하나라도 그냥 지나치지 않아야 하며, 앞으로 일어날 수 있는 문제가 무엇인지 예측하고 미리 보완하는 습관을 가져야 합니다.

 

[ 005 ] - 필요하면 개발 환경을 직접 만들 수 있어야 한다.

어디에도 현재 진행하는 프로젝트에 최적화된 개발 환경은 없습니다. 프로젝트를 진행하면서 필요에 따라 프로그램을 테스트하거나 검증할 수 있는 도구를 직접 만들 수 있다면 이것은 전체적인 생산성을 높여 줄 것입니다.

 

[ 006 ] - 프로그램은 결과도 중요하지만 과정도 중요하다.

초보 프로그래머가 쉽게 범하는 실수 가운데 하나는 프로그램은 결과가 중요하다고 생각하는 것입니다. 물론 원하는 결과가 제대로 나오는 것도 중요하지만 결과가 제대로 나오더라도 프로그램이 엄청나게 많은 메모리를 차지하거나 프로그램의 실행 시간이 밥 한 끼를 먹어도 충분할 만큼 길다면 결코 좋은 프로그램을 만들었다고 볼 수 없습니다. 따라서 프로그램은 결과도 중요하지만 다음과 같은 중간 과정도 중요합니다.   ① 코드의 최적화 메모리, CPU의 시간과 같은 리소스(resource)를 낭비하지 않고 적절하게 사용하는 최적화 ② 코드의 재사용성 다른 사람이 자신의 코드를 사용할 때 별다른 수정 없이 사용할 수 있도록 구성하는 모듈화 ③ 코드의 가독성 다른 사람이 소스 코드를 쉽게 이해할 수 있게 하는 가독성

 

[ 007 ] - if 문과 case 문을 적절하게 섞어서 사용하자.

if 문과 case 문은 서로 비슷한 기능을 하지만 사용하다 보면 서로 다른 기능을 할 때가 있습니다. 특히 수십 개의 if 문이 필요할 때에는 오히려 case 문이 더 적합한 경우가 있기 때문에 프로그램의 효율성을 위해서 프로그램 코드에서 if 문과 case 문을 섞어서 사용하는 습관을 갖는 것이 좋습니다.

 

[ 008 ] - 헤더 파일을 한 번만 인클루드하는 노하우를 익히자.

여러 사람이 공동으로 하나의 프로젝트를 진행하다 보면 헤더 파일을 인클루드하는 문제가 자주 생깁니다. 따라서 다음의 두 가지 방법 가운데 하나를 이용하면 인클루드 문제 때문에 일어나는 링크 에러를 막을 수 있습니다.   ① #ifndef ~ #ifdef ~ #endif 방법 ② #pragma once 방법   위의 두 방법 가운데 첫 번째 방법을 이용하면 컴파일러에 상관없이 어느 개발 환경에도 적용할 수 있기 때문에 나중에 다른 플랫폼에 소스 코드를 쉽게 이식할 수 있습니다.

 

[ 009 ] - 당근과 채찍을 두루 사용하는 프로젝트 매니저가 되자.

프로젝트 매니저는 근태 관리나 하고 아랫사람의 납기를 다그치기만 하는 군대의 고참과 같은 존재가 결코 아닙니다. 프로젝트에서 각각의 담당자들이 맡고 있는 분야 전체를 꿰뚫고 있고, 그 프로젝트에서 생길 수 있는 문제점을 예상하고, 그에 대한 대비책을 마련해야 하는 중요한 역할을 하는 사람이 프로젝트 매니저입니다. 따라서 프로젝트 매니저는 인간관계 뿐만 아니라 기술적인 노하우도 다른 프로그래머에 비해 탁월해야 합니다. 그저 시간이 흘러서 대리가 과장이 되고, 과장이 차장이 되는 그런 직책이 절대 아닙니다. 오히려 하나의 프로젝트를 진행하면서 가장 바쁘고, 힘들게 일하는 사람이 바로 프로젝트 매니저입니다. 또 프로젝트 매니저는 하나의 프로젝트를 성공적으로 끝내기 위해서 각 담당자들 개개인의 역량을 파악한 다음 업무를 진행시켜야 하며 그와 함께 적절한 칭찬을 해주어야 합니다. 실제 엔지니어들이 업무에서 갖는 가장 큰 불만은 칭찬에 인색한 프로젝트 매니저라고 합니다. 업무의 결과에 대해 정확한 당근과 채찍은 필수입니다. 채찍만 휘둘러 대는 프로젝트 매니저의 업무 습관은 프로젝트가 실패로 향하는 지름길입니다.

 

[ 010 ] - 주석은 필요한 정보만 간단하게 서술하자.

음식도 질에 상관없이 양만 많으면 언젠가는 탈이 나게 마련이듯이 프로그래밍도 마찬가지입니다. 쓸데없이 양만 많은 주석은 오히려 소스 코드의 이해에 방해를 줄 뿐만 아니라 소스 코드를 수정할 때에도 많은 주석을 함께 수정해야 하므로 번거롭기만 합니다. 소스 코드의 신빙성과 효율성을 위해서 보여주기만을 위한 소설식 주석보다 좀더 기능에 치중해서 간결하게 설명하는 것이 좋습니다. 주석을 작성할 때 다음과 같은 정보만 전달하는 것이 가장 효과적입니다. - 현재 작업하고 있는 모듈 이름 - 모듈의 인터페이스(매개변수, 반환 타입 등) - 모듈의 최초 작성자 - 모듈의 마지막 수정자 - 모듈의 작성 날짜와 가장 최근의 수정 날짜 그 밖에 소스 코드 안에서 코드 옆에 붙이는 주석은 필요한 경우에 함수 호출 부분에서 그 함수의 기능을 간단하게 나타낼 수도 있으며 특별히 중요한 변수인 경우에는 주의를 요한다는 설명을 곁들일 수 있습니다.