다른 개발자분 블로그를 보다가 정리해 놓으면 좋을 것 같아서 작성한다.
원문 출처는 맨 아래에 있으며, 여기에 내 짧은 생각도 조금 추가했다.
출처 블로그에 있던 문구와 조금 다르게 쓰기도 했는데 내가 평소에 쓰던대로 쓴거고 다른 의도는 없다.
1. 함수 시작 후에 BEGIN LOG, 함수 리턴하기 직전에 END LOG를 찍는다.
: 어떤 효과가 있을까? Crash나 Lock 문제 분석용. 혹은 어떤 함수가 호출이 되었는지 여부를 알 수 있다. 함수명을 붙여주어야 BEGIN LOG와 END LOG를 쌍으로 확인하면서 CALL STACK을 유추할 수 있다. 함수 내부에 리턴이 여러개일때는 구분할 수 있는 표시(라인넘버)를 해둘 수 도 있다.
2. 함수 시작시 전달받은 파라미터를 조사하고 비정상 값일 때는 리턴하기 전에 ERROR LOG를 찍는다. 잘못된 값을 보정해가면서 억지로 동작시키지 않는다.
: 어떤 효과가 있을까? 호출한 쪽의 문제를 발견할 수 있다. 개발 기간에 반드시 고쳐야 하는 버그라면 ASSERT를 쓰기도 한다.
3. 다른 라이브러리를 호출하기전에 ENTER LOG를 찍고, 끝난 후에는 LEAVE LOG를 찍는다.
: 어떤 효과가 있을까? Crash나 Lock문제 분석용. 혹은 어떤 라이브러리가 호출이 되었는지 여부를 알 수 있다. 라이브러리로부터 전달받는 값이 있다면, 마찬가지로 파라미터값을 조사하고 비정상 값일 때는 리턴하기 전에 ERROR LOG를 찍는다.
4. 플로우 차트대로 동작하는지 체크하기 위해 TRACE LOG를 찍어준다.
: 어떤 효과가 있을까? 순서대로 동작하는지 알 수 있다. 혹은 함수 내부에서 Crash나 Lock문제가 있을 경우에도 활용할 수 있다.
특정 시점에 변수값을 확인하고 싶을 때에도 TRACE LOG를 활용해서 찍을 수 있다.
5. 함수가 파라미터를 리턴하거나, 다른 라이브러리에 파라미터를 전달하기 전에 값을 찍는다. 리턴할 때는 END LOG에 같이 찍고, 다른 라이브러리에 진입할 때는 ENTER LOG에 같이 찍는다.
: 어떤 효과가 있을까? 내 함수에서 전달한 값이 문제가 있는지 확인하는 용도로 쓴다. 다른 함수를 호출할때도 마찬가지로 값을 찍어볼 수 도 있다. 필수적인 로그는 아니라서 낮은 레벨을 설정해서 숨기기도 한다.
6. 조건문에 의해 분기될 경우 TRACE LOG를 찍어준다.
: 어떤 효과가 있을까? 특정 시점에 어떤 분기를 탔는지 체크할 수 있다. 조건문이 참이 아닌 경우라도 TRACE LOG를 같이 남겨준다면 적절한 분기를 타지 못한 경우를 찾아낼 수 있다.
7. 적당히 찍도록 하자.
: 많이 찍으면 어떤 문제가 있을까? 로그를 너무 많이 찍으면 프로그램 성능에 영향을 주기도 한다. 로그 때문에 타이밍 이슈를 못찾는 경우도 간혹 있다. 가독성이 떨어져서 분석하기 힘들다. 로그 용량이 커질 경우 외부에서 전달 받기 힘들 수 있다. 그러니 적당히 찍고, 켜고 끄는 기능을 넣자. 하지만 피도눈물도 없는 일회성 Crash 이슈를 잡기 위해서는... 어쩔 수 없이 로그를 많이 심기도 한다. (가능하다면 원격 디버깅이나 시스템에서 만들어주는 crash 로그를 활용하자)
8. LOG 작성 방식은 회사나 팀에서 문서화해서 통일해서 사용한다.
: 어떤 효과가 있을까? 다른 사람이 버그 분석하기 편하다. 다른사람이 유지보수하게 되었을때 덜 불려가려면 팀단위 혹은 적어도 그 프로그램 내에서는 통일해서 사용하자.
원글의 출처는 다음과 같다.
다른 좋은 내용도 많으니 시간나면 꼭 가보자.
출처 : tikifr.egloos.com/4383635