프로그래밍시 어떻게 하면 시스템 load를 줄일 수 있을까요?
글쓴이: yonglimlee / 작성시간: 수, 2014/04/23 - 9:58오전
안녕하세요.
현재 MFC로 프로그램을 개발하고 있습니다.
아직 프로그래머를 직업으로한지 일년이 채 안되기 때문에 그 전까지는
코딩할때 그냥 되는대로 짰던것 같습니다. 허허;;
우선 돌아가기만 되면 되겠지 라는 생각으로요
그런데 테스트 중에는 죽지 않던 프로그램이 갑작스레 시현해야할 자리에서 죽는다던가 하는일이 종종
발생하더군요. 사수의 말에 의하면 '테스트때 죽어라 테스트해도 발견 안되던 버그가 시현될때는 발생하는 법이다' 라고 하더라구요. 어쨌든 그때그때 고치고 있긴 합니다.
근데 요즘 드는 생각은 어떻게 하면 프로그램 변수부터 함수를 짜는 것, 구조를 어떻게 만드는것 등등 어떤 방법이
프로그램에 load를 조금이나마 적게 걸리게 할까 입니다.
가량 0이상의 정수로 나온다면 unsigned를 쓴다거나 소수점이 필요없는 나눗셈(2진수)에 대해선 쉬프트 연산을 한다던가...
이런 방법은 어떻게 검색해야 나오는걸까요? 그냥 프로그램을 짜다보면 자연스레 체득하게 될까요?
Forums:
일단..
- 물론 불가피한 이유가 있으시겠지만.. 개인적 의견을 드리면, 가급적이면 MFC는 피하세요. QT라든지 닷넷이라든지 대안이 많습니다. MFC도 장점이 없는 것은 아니지만 요새 유행하는 것들과 경쟁하기엔 생산성이 떨어지고 디버깅에 너무 많은 시간이 소요됩니다.
- 모듈별로 유닛 테스트를 충실히 구현하시고 매 빌드마다 자동으로 수행되게 하면 코드 변화에 따른 부작용을 최소화할 수 있습니다.
- 유닛 테스트뿐만 아니라, 실제 프로그램을 돌릴 때 스크립팅을 하는 방식으로 런타임 테스트도 자동화하는 게 좋습니다. 사람이 컨트롤하는 것과 최대한 가깝게 말이죠.
- 시연을 할 때에는 말씀하신 불상사를 최소화하기 위해, 주요 기능의 데모가 녹화된 동영상을 먼저 보여주시고, 질문을 받는다든지 기타 불가피한 상황에서만 직접 프로그램을 돌리는 방법도 있습니다.
- 죽었다 해서 그냥 넘기지 마시고 전역 예외핸들러를 구현한다든지 디버거를 붙여두든지 어떤 방법으로든 꼭 덤프를 받아놓으세요. 그리고 덤프파일별로 추가 디버깅..
- 죽었다 해서 당황하지 마시고 그냥 다음 기능으로 넘어가면 됩니다. 버그는 고치면 되는 것이고, 데모에서 중요한 것은 기대했던 기능이 구현되었는가를 보여주는 것입니다.
- 말씀하신 부분은 지금 단계에서 크게 중요하지 않다 생각합니다. 불필요한 연산 그 자체를 줄이는 정도면 충분하고, 동일 동작을 좀더 빠르게 하는 것은 나중에.. 명백히 더 편하고 간단한 방법이 있을 경우 코드 리뷰 단계에서 걸러지게 되니 크게 걱정 안 하셔도 됩니다. 코드리뷰를 통해 다른 개발자의 의견을 들어볼 수 있고 그걸 반복하면서 점점 배우는거죠.
--
궁금한게 있는데요.
MFC가 닷넷보다 생산성이 떨어진다는 말을 지난번에 어디선가 얼핏들었는데
정확히 여기서 말하는 생산성이 어떤 의미인지 모르겠습니다.
한수 알려주세요~!
*********************************
막 먹게 되면 막 생활하게 되더라.
*********************************
생산성이라 함은
간단히 표현하면 개발자가 프로그램을 완성하는 퍼포먼스입니다. (프로그램 자체의 퍼포먼스가 아님에 주의.)
비슷한 난이도의 프로그램을 MFC와 자바(또는 닷넷 등)로 반복해서 구현해보시면 금방 느끼게 됩니다.
--
갑자기 튀어나오는 문제 잡으려면 먼저 MFC부터
갑자기 튀어나오는 문제 잡으려면 먼저 MFC부터 포기하세요
라이브러리 소스도 없는데 나오는 문제 잡을 방법 없습니다.
load부분은 작은 부분을 신경쓰기보다는, 생산성을 우선시 한다음에 프로파일링을 통해서 줄이세요.
3d, 비디오 코덱, 복잡한 계산 같은 분야가 아닌다음에야 함수 하나하나 최적화 해봤자 전체적으로 성능이 그렇게 나아지지 않아요.
저희 회사 자체가 MFC만 사용하네요 ㅠㅠ
근데 진짜 MFC는 점점 사장되가고 있는 언어일까요 ? 흑
*********************************
막 먹게 되면 막 생활하게 되더라.
*********************************
MFC는 언어가 아닙니다.
개인적인 조언을 드리자면..
- 기존 제품 유지보수라면 어쩔 수 없지만, 새 기능 추가에는 MFC를 이용하지 않거나 다른 기술(닷넷 등)의 접목을 강력하게 주장하세요.
- 새 제품에는 가급적이면 MFC를 쓰지 않는 것이 좋습니다.
이 두 가지가 관철되지 않는다면 틈틈이 다른 회사를 알아보시는 게 좋을 것 같습니다.
--
흠.. 그런가요?
제가 예전에 MFC의 미래에 대한 어떤 포스팅을 보고 사수에게 어떻게 생각하냐고 물었더니
(그때는 자바랑만 비교를 하셨어요.) 자바보다 훨씬 빠르게 돌아가고 MFC로 못할것은 없다고 하며 정말 못하는게 없이 잘 하셨드랬죠.
그래서 그때부터 MFC를 열심히 해야겠다라는 생각을 했는데....
닷넷을 배워야 하는건지...
강력히 닷넷이나 자바를 주장하는 이유가 있으신가요?? 전 댓글에서 달아주신 생산성 때문인가요?
*********************************
막 먹게 되면 막 생활하게 되더라.
*********************************
댓글 달기