{
이 항목은 몸에 와 닿지 않는다. 아무래도 이런 개발 프로세스를 사용해 본적이 한번도 없기 때문이다. 회사에서 로그를 남기는 것으로 처리 하는게 아마도 이런 개발 프로세스 인것 같다.

이것이 왜 중요한가?
 보통은 안써도 크게 무리 없지만 프로젝트의 규모가 커지거나, 프로젝트에 붙는 사람들의 숫자가 많아 질 수록 프로젝트의 관리도 더불어 힘들어 진다. 그러면서 디버깅은 점점 힘들어 진다. 만약 오류의 처리 방식, 보고 방식, 표현 방식이 정해져 있다면 좀 더 편할 것이다.

책에서는 모라고 하는가?
 개발 초기에 먼저 정하고 개발하라고 한다.

어떻게 정하는가?
 오류를 우선 식별하는 기준을 정한다. 예를 들어 babo_num > 30 이면 오류이다. 라고 정한다.

그리고 오류의 수준을 정한다. babo_num > 30 이면 최강 오류다. 라는 식인데, 우리 프로젝트에선 오류의 수준을 FATAL, ERROR, WARN 등으로 나눈다.

그리고 오류를 보고 하는데, 보통 파일로 남기거나, DB에 밀어 넣는다.  언제 어디서 어떻게 났는지를 말이다.

그리고 오류를 처리 한다. FATAL 이면 프로그램 종료 ERROR 면 예외처리 WARN 이면 경고.. 식으로 수준에 맞게 처리 한다.

마지막으로 책에선 오류를 전달한다면, 어떻게 전달할지를 정하라고 한다. 예를 들어 C API 에 오류를 전달하고자 한다면 catch(...) 를 사용하라고 가변인자 함수를 만들어서 거기로 넘기라는 것인가? 크... 모르겠다.

분명한건 오류라는 입력을 연산하여 출력 하는 과정을 확실히 명시하라는 이야기이다.

}

  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 라이프코리아트위터 공유하기
  • shared
  • 카카오스토리 공유하기

댓글을 달아 주세요

">