프로그램 설계 관련
글쓴이: icabord / 작성시간: 수, 2009/02/11 - 12:03오후
안녕하세요.
질문 하나 올립니다.
개발을 하시다보면, 프로그램 작성후에 기능이 추가된다거나 하는 상황, 혹은 제품의 경우 UI 의 버전(모양이 변경되는)이 변경되는 상황이 생길 수 있습니다.
제가 주변에서 경험하기로 이러한 처리를 보통
= 전역 config.h =
#define UI_VER_1
//#define UI_VER_1
= 각각의 파일들에서의 사용 =
#ifdef UI_VER_1
// to do
#elif UI_VER_2
// to do
#endif
이와 같이 하는 것을 봤습니다.
아주 편리한 방법입니다. 전역에서 옵션처럼 define 에 따라 그에 해당하는 소스만 컴파일이 됩니다.
그런데 문제는 이와 같은 방법은 옵션이 늘어날수록 소스가 난해해 진다는 점입니다. #ifdef 의 depth 처리를 제대로 하지 않는 경우라면 depth 당 스트레스의 증가율은 제곱에 가까워 집니다.
그래서 궁금한 점은 다른 분들은 위와 같은 상황일 때 어떻게 처리하는가 입니다.
후배에게 물어보니, 저 방법 말고는 없지않냐고, 보통 저렇게 하지 않는가 라고 반문을 하더군요;;;
다른 분들도 그렇게 생각하시는지요.
조언 부탁드립니다.
Forums:
가지(branch) 치면
가지(branch) 치면 될듯합니다만...
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
예전에 동일 제품을
예전에 동일 제품을 고객사에 따라 다른 UI, 다른 수행 순서를 만들어야 했습니다.
처음에는 위처럼 조건 컴파일, 또는 다른 소스브랜치를 관리 했는데,
그것도 변수가 늘어나니 머리가 아파지더군요.
그때는 MFC로 윈도우즈용 프로그램을 만들던 시절이었습니다.
제가 추가로 한 방법은 다이얼로그 등의 리소스를 별도의 DLL로 만들어
고객사별 배포판을 만들때 그 DLL만 바꿔치기 하도록 한 것입니다.
리소스 DLL의 다이얼로그 리소스의 경우 Form의 초기값등의 정보도 있는데,
원래의 MFC코드로는 이 초기데이터 로드가 안되서 MFC코어중 일부를 변경해서
컴파일 했던 기억이 납니다.
요즘은 더 쉬워졌겠죠. .Net의 경우는 satellite assemblies 로 너무 간단해 졌구요.
결국 decorator패턴의 바이너리 구현이라고도 볼 수 있을 것 같군요.
-------------------------------------------------
$yes 4 8 15 16 23 42
-------------------------------------------------
$yes 4 8 15 16 23 42
엔진과 UI 를 분리할
엔진과 UI 를 분리할 후 버전별로 가지치기(branch) 합니다.
물론 로그를 아주 열심히 남겨서 헷갈리지 않아야 겠지요.
========================
조직 : E.L.D(Embedded Linux Developer/Designer)
블로그 : poplinux@tistory.com
카페 : cafe.naver.com/poplinux
임베디드 리눅스 관련 프리렌서 지향
답변감사합니다.
답변 감사드립니다.
가지치기(branch) 는 SVN 를 말씀하시는것 같은데 맞나요?
이경우 제가 하는 프로젝트는 SVN 을 사용하지 않습니다;;;
질문 올리고도 쭉 생각해 봤는데, 설계가 제일 중요한 거네요. 결국은
댓글 달기