안녕하세요.  머무는여행입니다.   제가 ‘개발자 세상’ 메뉴에 글을 쓰게 되는 날도 다 있네요^^ 

저희 알티베이스 품질관리팀 김성재님의 특별 기고를 받았다고나 할까요? ㅎㅎ 사실은 다른 커뮤니티에 올리신 글을 보고 내용이 좋은 것 같아 퍼오고 싶다고 하니, 직접 새로 다듬어 주신 거랍니다.  성재님 넘 감사해요~~^^

그럼, 프로그래머의 준비물… 궁금하시죠?  이제 소개합니다.

——————————————————————————————————————————-

초등학교 시절에 연필을 안들고 가면 선생님이 늘 하던 말씀이 있다.  군인은 전쟁하는데 총을 들고 가는데 학생이 공부하는데 연필을 안들고 오면 어떡하냐?
그럼 프로그래머의 준비물은 무었일까요?  “컴파일러와 notepad 만 있으면 돼” 하는 하는 영웅들의 이야기가 아닙니다.
평범하고 우리 주변에 흔히 볼수 있는 프로그래머들을 위한 준비물을 알아 봅시다.

1장 개발 산출물 관리도구

개발시에 나오는 산출물을 관리하는 도구들을 알아봅니다.

1-1. 코드 관리툴

다른 말로는 형상관리툴이라고도 합니다.
간단하게 말하면 “우리가 작년에 코딩한 코드를 알고 있는 도구 입니다.”
코드 관리 툴을 사용하면 임요환이 마린 컨트롤 하듯이 코드를 컨트롤 할수 있습니다.

다른 사람과의 코드교환이나 코드 통합, 특정 시점에 발생한 버그 추적등을 간단히 할수 있습니다.
코드 관리툴은 간단한 코멘트를 저장할수 있지만 이것만으로는 부족하므로 다음에 설명한 버그관리툴과의 연동이 필수적입니다.

무엇을 사용할것인가? svn 추천합니다. 요즘 대부분 svn 을 사용하는듯 합니다.
또한 svn 은 커맨드 기반이므로 GUI 로 편리하게 쓸수 있는 도구를 사용합시다.
viewcc 등을 사용하면 웹에서 코드를 볼수 있는 기능을 제공합니다.

1-2. 버그 관리툴
예전에는 버그 관리툴이라고 불렀는데 요즘은 이슈관리툴이라고 합니다.

이슈는 버그보다 확장된 개념으로 기능추가나 고객이 제기한 버그가 아닌 문 제들까지 포함하는 개념입니다.
버그 관리툴에는 어떠한 논의가 있었고 어떻게 추적했으며 어떻게 수정했는지 를 기록합니다.
버그 관리툴을 도입하면 생산성을 저하시킨다라는 이유로 반발이 심합니다.
맞습니다 생산성이 저하됩니다. 하지만 버그 관리툴을 사용하면 시간이 지날 수록 빛을 발휘 합니다.
개떡이라는 단어가 있습니다. 우리 주변에서 흔히 볼수 있죠. 생각나십니까?
바로 당신이 보고 있는 코드죠.
개떡에도 삶의 이유가 있을진데 우리는 그것을 보고 같은 코드를 작성하면 안 되겠죠.
버그 관리툴은 신입교육에도 좋습니다. 신입 교육은 분명이 비용이 많이들고 그래서 경력같은 신입을 원하죠. 하지만 그런 사람은 없습니다.
경력자의 버그 추적 방법이나 수정 방법, 생각의 방식등이 버그 관리툴에 녹 아 있습니다. 신입은 그것을 읽기만해도 내공이 상승합니다.

무엇을 사용할것인가? 멘티스나 trac, 버그질라을 추천합니다.
코드 관리툴과의 연동방법을 제공하고 다양한 노하우가 녹아져 있습니다.
간단히 설명하면 svn ci -m “BUG-1000″ 을 수행하면 버그 관리툴의 BUG-1000 이란 게시물에서 제가 수정한 내용을 볼수가 있습니다.
버그의 히스토리까지 같이 볼수 있다는 장점이 있습니다.

1-3. 문서 관리툴
프로그램 개발을 하게 되면 코드와 버그만 생성해 내지 않습니다. 문서도 만 들어 내죠. 그래서 문서 관리툴이 필요합니다.
일반적으로 2가지 방법을 사용합니다.
첫째는 문서도 코드처럼 관리하는 방법입니다. 코드 관리툴에 저장을 하고 버 그 관리툴로 히스토리를 관리하는 방법입니다.
강력한 문서 편집툴을 사용할수 있는 장점이 있지만 검색이 안되고 버젼간 변 경사항을 보기 힘들다는 단점이 있습니다.
둘째는 wiki 를 이용하는 방법입니다. wiki 를 구성하여 접근성이 편리하게 문서를 생성하는 방법입니다.
wiki 문법을 익혀야 하고 편집이 강력하지 못하지만 접근성이 편리하고 문서 히스토리 관리가 편리하다는 장점이 있습니다.

2장 개발 시스템

1장에서는 개발과정에서 나오는 산출물에 대해서 설명했다면 2장은 개발하는 행위에 관한 내용입니다.

2-1. 코딩 규칙

우리 주변에서 흔히 볼수 있는 그런 프로그래머들이 이해할수 있는 산출물을 만들도록 노력해야 합니다.
그래서 규칙을 정하고 일정 시간을 들여서 규칙을 가르칩니다. 이것은 코드뿐 만이 아니라 모든 산출물에 대해서 적용되어야 합니다.
이러한 규칙을 통해서 모든 개발자들이 한눈에 산출물을 이해하고 바로 업무 에 투입한다는것은 환상에 가깝습니다.
하지만 그 기간을 충분히 단축시킬수 있습니다.

2-2. 리뷰 시스템
산출물를 수정하고 나서 다른 개발자와 검토해야 합니다. 산출물의 수정사항 을 보면서 토론을 하는것입니다.
참여자는 산출물의 수정량이나 중요도에 차등 적용하는것이 좋습니다. 코드 1 줄 고치는데 모든 팀원을 모으는것은 잘못된 것이죠 리뷰는 잘못하면 형식적으로 흐르기 쉽습니다. 관리자의 의지가 중요합니다.

2-3. 빌드 검증 시스템
개발자가 확인하고 코드를 반영해도 파일을 몇개 빼먹는다던가 하는 실수는
자주 일어납니다.
따라서 코드 관리도구에 코드가 반영될때마다 컴파일이 제대로 되었는지 확인 을 하는 시스템을 구축하면 좋습니다.
추가적으로 간결한 테스트를 자동으로 진행하면 좋습니다.
예를 들면 컴파일은 잘되었지만 실행이 안될수 있습니다. 실행은 되지만 아주 기본적인 기능이 동작하지 않을수 있습니다.
코드 관리도구의 기능을 사용하면 자동으로 컴파일하고 테스트를 수행하도록
할수 있습니다.