난이도 : 초급 Teodor Zlatanov, 프로그래머, Gold Software Systems
2001 년 11 월 01 일 소프트웨어 프로그래밍 그룹의 성패는 팀의 공조가 얼마나 잘 이루어지는 지에 상당부분 좌우된다. 관리자부터 멤버까지 각 부분의 조화가 필요하다. Teodor는 조화롭고 힘이 집중된 프로젝트 그룹을 만들 수 있는 방안을 제시한다. 첫 번째 시리즈에서 Teodor는 그가 집필한 책을 소개하고 새로운 관점의 코딩 가이드라인을 제안한다.
펄 프로그램을 시작하는 초보자부터 숙련된 펄 프로그래머들 까지, 모두 유용한 정보를 얻을 수 있을 것이다. Part 1의
팁에서부터 Part II의 프로젝트 관리 툴 그리고 Part III의 Parse::RecDescentsource
코드 분석에 이르기까지 다양하고 유용한 정보가 많다.
프로그램(program)과 스크립트(script)는 같은 의미로 사용된다. 특히 펄에서는 두 가지
의미가 훨씬 더 유사하다. 프로그램은 정말로 많은 스크립트들로 구성될 수 있고 스크립트는 많은 프로그램들을 포함하고 있다. 한
개의 스크립트 파일은 단지 하나의 프로그램을 포함하고 있다는 이해를 바탕으로 두 개의 용어를 사용하겠다.
책을 쓴 목적
Part I 에는 펄 기술력을 향상시킬 수 있는 팁이 많다. 최상의 프로그래밍 예제를 비롯하여 코드 디버깅 까지
다루었다. 이 글에서는 펄 프로그래밍을 가르치지는 않는다. 그러한 용도에 맞는 책은 많이있다. 하지만 명료성이나 완성도에 초점을
맞추었다.
Part III 에서는 소스코드를 분석하고 팀 관리를 보다 효율적으로 할 수 있는 툴을 개발한다. (펄과 C
예제가 개발될 것이다). 소스 코드의 분석은 아직까지는 추상적이다. 명백하고 관련성이 덜한 "코드 라인" 메트릭스에서
함수 포인트로 이런 것들로 프로그래머의 생각까지 이해할 수는 없다. (참고자료).
프로그래머의 생각을 이해하는 것은 Part III의 목적이다.
완벽한 프로그래밍이란 것은 없다. 단지 그것을 추구할 뿐이다. 좋은 프로그래머는 항상 새로운 것을 배우고 지속적으로 기술을
개발해 나간다. 경직과 완고함은 창조의 영원한 적이다.
완벽 추구
프로그래머가 저지르는 가장 일반적인 실수는 프로그램의 버그 리스트에 있는 것이 아니다. 프로그래머의 나이나 선택한 언어도 아니다.
프로그래머의 능력이 완벽해서 더 이상 발전할 여지가 없다는 착각이다.
이같은 생각은 인간 본성이기도 하다. 하지만 인간 본성에는 지식과 발전을 향한 끊임없는 탐구정신도 있다. 교만함과 잘못 되었다는
판정에 대한 두려움이 우리를 뒤로 물러서게 한다. 이러한 두려움과 교만과 싸움으로서 보다 나은 프로그래머가 될 수 있고 더 나아가서
"훌륭한 인격"까지 갖추게 된다.
상호 교류와 사람들 각자의 자질이 성공적인 소프트웨어 팀을 만드는 요소이다. 프로그래머 기술의 지속적인 개발과 비판을 받아들일
수 있는 능력이 소프트웨어 팀 멤버에게 필요한 기본 요소이다.
여러분의 스타일을 바꾸었던 때가 언제인가? 그것이 여러분이 배운 새로운 알고리즘인가 아니면 주석 스타일인가 아니면 새로운 변수
네이밍 방식인가? 어떤 것이든 간에, 이것들은 단계의 일부이지 완벽한 코드의 최종 단계는 아니다.
프로그래머가 코드 가이드라인 그대로를 따라갈 필요는 없다; 작업을 수행하는데 있어 그러한 가이드라인을 바로 적용할 필요도 없다.
오케스트라를 생각하는 것이 좋을 것이다. 정적이고 영혼이 없는 연주가나 즉흥 연주의 대가가 되지 말아야 한다는 의미다. 수동적인
연주가는 노력이나 영혼을 음악에 집어넣지 않은 채 악보를 따라 그저 연주할 뿐이고 즉흥연주가는 자신만의 멜로디를 따라 잘못된
연주를 하게 될 것이기 때문이다.
조화된 화음으로
오케스트라에는 지휘자가 있기는 하지만 모든 연주가들에게 연주 방법을 알려주지는 않는다. 지휘자는 전체 하모니를 만든다. 음악은
프로그래밍 기술보다 훨씬 오래된 분야이기 때문에 음악에 비유된 교훈은 귀담아 들을 만하다. 소프트웨어 프로젝트 관리자는 고릴라도
격리된 죄수도 아니다. 그도 다른 사람과 마찬가지로 팀의 일원이다.
이 시리즈를 통해 제시될 가이드라인을 공식적인 코딩 정책에 무조건 적용해서는 안된다. 각 프로젝트의 코딩 표준은 고유한 영역이다.
프로그래머에게 엄격하게 정확한 일을 할 것을 강요하지 말라. 이것은 불신과 두려움을 조성할 수 있다.
대신 가이드라인을 제시하고 사람들이 어떻게 반응하는지를 살펴보아라. 여러분이 좋아하는 주석 포맷을 어느 누구도 받아들이지 않는다면
포맷이 그다지 좋지 않은 것일 수 있다. 모든 사람들이 사용하고 있다고 생각했던 디버거가 먼지 쌓인 방에 방치되어있다면 Whizzo
Debugger 3.4의 필요성을 재고해야 한다. 어떤 이유에서는 Acme Debugger 1.0이 모든 사람에게 더 나을 수도
있다.
물론 프로그래머는 아무런 이유없이 고집스러울 때가 있다. 때로는 변화를 꺼려한다. 20년의 경력을 통해서 그들 나름대로 쌓아온
철학이 왜 없겠는가? 다른 한편으로는 대학을 졸업한지 얼마되지 않은 사람들에게는 자신감이 부족하다. 그러한 특징을 인정하고 받아들이라.
고집스러운 숙련자들에게는 그들이 도움을 받을 수 있다고 느낄만한 아이디어를 제공하라. 학교를 졸업한 사회 초년생에게는 그들이
자신의 날개로 날 수 있을 때까지 지원하도록 한다.
코딩 가이드라인 만이 전부는 아니다!
코딩 가이드라인은 소프트웨어 팀에게는 기본적인 것이다. 음악에 있어서 지휘와 하모니가 그런 것처럼. 이것은 일관성과 일치성에
기여한다. Ye olde 팀 멤버는 새로 오는 사람들을 좀 더 적극적으로 받아들일 것이다.
속도만이 프로그램의 코드에서 향상도의 측정 대상이 아니다. 테스트의 용이성, 문서, 장기적인 관점에서 특히 중요한 유지관리
등도 측정 대상이 될 수 있다. 펄 처럼 유연한 언어는 소프트웨어 프로젝트의 모든 단계마다 좋은 코딩 방식을 제공한다. 이 책은
펄에 초점을 맞췄지만 대부분의 원리들은 C, C++, Java, Python 등에도 적용할 수 있다.
마지막으로 혁신가가 되길 바란다. 팀에서의 위치가 어떻든 간에 항상 새로운 아이디어를 찾고 행동으로 옮겨라. 완벽하게 되는
것은 불가능하다. 하지만 가치있는 목표이다. 혁신가는 팀의 진정한 강자이다. 그들 없이는 멜로디는 진부해지기 마련이다. 동료들과
항상 교류하라. 그들에게서 새로운 것을 계속해서 배우라. Usenet (참고자료)은
아이디어를 교환할 수 있는 적합한 장소이다. 서로 배우고 가르치라. 발전의 여지는 항상 있음을 기억하라. 무엇보다도 즐거운 마음으로
음악을 시작하라.
참고자료
필자소개  | | Teodor Zlatanov는 1999년에
보스턴 대학에서 컴퓨터 공학을 전공했다. 졸업 후 Perl, Java, C, C++를 사용하여 프로그램을 개발하였다. |
기사에 대한 평가
| 
