복잡한 프로젝트 어떻게 관리하면서 작업하시나요?

무의미합니다..
왜냐하면 플젝은 진행하면서 기획부터 바뀌거든요.

일단 가이드라인 만들고
작업하면서
가이드라인에 변경만 잡은다음
부분별로 가지치기하면서 작업중입니다.
실시간으로 유지되는 문서라고는 javadoc(이것도 문서냣)과 erd밖에 없네요.
서로 작업하는 소스가 svn에 올릴때 나는 충돌방지를 처리하는것만해도
하루에 시간이 1시간 이상은 가는거같습니다.
다 졸속플젝이 낳은 결과라고나 할까요...-.-;

-----새벽녘의 흡혈양파-----

CppUnit도 있는 것으로 압니다.
구버전이라 유닛테스트 툴이 없는 환경이라면 간단한거 하나 만들어서 붙이세요.

프로젝트 초기에는 테스트를 손으로 하는게 빨라보이겠지만, 후반부로 갈수록 자동화된 테스트가 비교할 수 없을 정도로 빠릅니다.

만라인정도의 프로그램은 기본적인 문서화(메뉴얼, 주석)와 잘 정리된 테스트셋만 있어도 크게 지장 없을듯합니다만...

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

저도 아래 과정을 곧이 곧대로 따르는 건 아니지만, 좀 막힌다 싶으면 다음과 같은 과정 비슷하게 한번씩 정리 해주면 도움이 되더군요. (프로젝트를 top-down 방식의 프로그램 개발이라고 이해하고 적겠습니다.)

1. 프로그램이 어떤 입력을 받아 어떤 결과물을 내놓는 것인지 정의합니다. 중간 프로세스는 아직 생각할 필요없고, 대신 입출력 대상의 기준을 명확하게 세웁니다. (이 단계에서 입출력 내용을 구체적으로 정의할 필요는 없으나, 이것이 입력 또는 출력에 포함되는 내용인지 아닌지, 어디에서 입력받는 지, 어디로 출력하는 지는 명확하게 가려낼 수 있어야 합니다. 이 프로젝트가 뭐하는 프로젝트인지 정의하는 단계라고 할 수 있겠네요.)

2. 위에서 정의된 입력에서 출력을 얻기까지 취하는 action들을 도출해 냅니다. 대충 데이터의 입력, 출력, 변환, 시스템간 전송과 같은 큰 범주의 개념으로 action을 끄집어냅니다. (sub-system으로 나누는 과정이라 보시면 됩니다.)

1,2에서 나온 내용에 data 흐름을 연결시켜 주면 첫번째 DFD가 나옵니다. 그 이후의 단계는 사실, 각 action들의 I/O를 정확하게 정의해 주고 독립적인 개념으로 분리하여 모듈화한 다음 1,2의 과정을 반복해 나가는 것이긴 한데, 문제는, 쪼개나가다가 모듈 수가 많아지면 모듈간 dependency, 개념의 중복성, data 정합성 등등 생각이 여러 곳에 분산되서 머리가 복잡해지는 경향이 있더군요. 때문에, 어느 정도 쪼개져서 각 action의 개념이 명확해졌다 싶으면 쫙 펼쳐놓고 재조립하는 3번 이후의 과정을 거칩니다.

3. 위에서 나온 모든 개념들을 생각나는 데로 주욱 나열합니다. 이 단계에선 일단 중복은 고려하지 말고, 내용이 빠지지 않게 다 적어내는 것이 중요합니다.

4. 적은 내용들은 data와 action으로 분리해냅니다.

5. Data 영역부터 정제해 나갑니다. 중복된 data는 하나로 합치고, 여러 개의 개념이 하나로 묶인 data일 경우 개별로 분리할 지 아닐지 결정하며, data가 entity인지 relation인지 attribute인지 구분해 냅니다. 정리된 데이터의 관계를 연결해 주면 ERD가 완성이 됩니다.

6. Action을 정리하는 과정은 결국 모듈화해나가는 과정입니다. 쪼개 나갈 때는, 쪼개는 기준과 모듈의 인터페이스(I/O)를 명확하게 정의하는게 관건입니다. 이것만 확실하면 문제가 생기더라도 그 모듈 버리고 연결된 모듈들 인터페이스만 바꿔주면 되니까요.

7. 시스템의 상태를 나타내는 parameter를 찾습니다. 예를 들어, 중간 결과물의 현재 상태, 프로그램 실행 환경, 외부 관련 시스템의 상태와 같이, 프로그램의 작업 분기를 결정하는 요소을 찾는 과정입니다. 물론 각 세부 모듈마다 체크해야할 시스템 상태는 각각 존재합니다만, 프로그램 전체를 하나의 큰 모듈로 보고 global하게 적용되는 시스템 상태를 미리 도출해 놓으면 전체 그림도 쉽게 파악되고, 나중에 고민할 일도 줄어들더군요.

8. 이정도까지 하면 global name space의 모양이 대략 잡힙니다. 5,6번 내용으로 data structure하고 function prototype이 결정될테고, 7번 내용으로 global 변수나오고, 6,7번 내용으로 automata와 flow chart도 그릴 수 있겠죠. (실제로 flow chart를 그리는 일은 아직 없었습니다만...)

해보면, 결국 위에 내용이 업무 파악하는 것이더군요. 현실에서 사람 손으로 뭘 어떻게 해야할지 정확히 안다면 코딩은 단지 컴퓨터가 알아먹게 정확하게 번역해 주는 일인거 같아요. (물론 성능 향상을 위한 알고리즘 개발은 프로그래머의 몫이긴 합니다만...) 기술적으로 막히는 경우가 아니라면, 프로젝트가 뭘 하는 프로젝트인지 정의를 다시 한번 내려보면 머리속에서 정리가 될 지도 모릅니다.

문서는 프로젝트가 커지면 꼭 필요합니다. 그렇다고 문서가 하나부터 열까지 내용을 다 담고 있을 필요는 없습니다. 문서의 목적은 전달이 주 목적이고 기록으로 남기는 것이 부가적인 목적이라고 생각되는데, 일일이 다 적지 않아도 문서들고 적절한 수준의 이해를 가진 사람에게 적절한 시간안에 부가설명으로 내용 전달만 할 수 있으면 된다고 봅니다. 무슨 무슨 diagram 종류가 많은 것도, 그거 들고 설명하기가 좋거든요. 그리고, 꼭 싱크가 맞아야 될 필요도 없어요. 변경 내역과 일자만 잘 정리해두고, 그 이후 변경 사항은 직접 설명이나 짧은 메모로 대신할 수도 있으니까요. 문서는 안만들어서 문제지, 어떻게든 적어 놓으면 다 도움이 될꺼에요. 제 경우엔 cvs 코멘트 좀 신경 써주면 cvs diff가 최고 문서인거 같더군요.

문서화 툴은, 소스 코멘트 착실하게 적는 편이시라면 doxygen(http://www.doxygen.org/) 추천합니다.