디버깅 원칙 리뷰

https://kciter.so/posts/principles-of-debugging/

디버깅 원칙

kciter님의 포스팅을 보면서 이해한 내용을 나만의 방식으로 정리한 리뷰글입니다.

 

디버깅을 할 때 한 부분에 집착하는 사고방식을 모든 것을 의심하는 사고방식으로 바꾸는 것을 권하고 있다.

나 또한 프로젝트를 하면서 디버깅을 할 때 꼬리에 꼬리를 무는 형식의 문제해결 방식으로 힘들게 학습을 했던 개발자였다. 해당 포스팅을 읽고 공감하는 부분이 많았기 때문에 집착하는 사고방식을 개선하려고 한다.

 

직관과 탐정

이 글에서는 개발자의 경험에 근거한 직감을 중요하게 생각하는데 그 직감에 근거한 추측이 디버깅 하는 것에 많은 도움을 준다는 것이다.

설명을 보태자면, 내가 아는 지식을 문제와 연결시켜 해결하는 방법을 권한다는 것이다. 그것이 문제 해결의 숏컷 역할을 해준다고 말하고 있으며, 실제로 개발자들이 의식하지 않지만 직감으로 많은 부분을 해결하고 있지 않았나 생각한다.

 

가능성을 좁혀라

이 글의 기술적 원칙을 설명하는 핵심이라고 할 수 있는 부분이다.

4단계의 원칙을 제시하는데 의심하기, 분류하기, 학습하기, 연결하기이다.

의심하기

코드, 로그, 에러메시지 등 모든 정보를 문제 해결을 위해 사용해라. (IDE 경고 무시하지 말기)

오타, 잘못된 변수, 조건문을 사용하거나 계산 실수가 있는지 생각해봐야 한다.

분류하기

체크리스트를 작성하여 정보를 수집하고 기록해라 여기서 특정 부분에 몰입(집착)하는 것을 조심해야 한다.

분류를 통해 무엇을 확인했는지 확인할 수 있다.

체크리스트를 작성하면서 잘 모르겠는 문제를 바로 지우는 것은 좋지 않다. 그런 문제는 별도의 리스트로 분류해서 재검토한다.

논리적, 의존 기술, 기반 기술, 물리적 결함 등.

결함 분류 방법은 코드를 작성 중인 당일에 버그가 발생하면 논리적 결함일 가능성이 높으며, 논리적 결함을 살핀 뒤 연관 있는 하드웨어 상태, 네트워크 상태 등을 살펴보는 것이 효율적이다.

논리적 결함이 문제가 되는 경우 요구사항의 설계가 문제인 경우도 있다.

의존 기술 결함 프레임워크 라이브러리등의 의존성 기술들의 버전이나 잘못된 사용방법의 문제는 이슈들에 관심을 가지고 기술 문서를 참고하여 해결할 수 있다. 검색을 통한 커뮤니티의 오래된 문서들을 보고 작성된 코드들이 이러한 문제를 일으킬 수 있다.

물리적 결함은 하드웨어적인 문제인 가능성 다른 장비로 테스트하거나 고장을 확인해야 한다.

학습하기

모르는 문제를 별도의 리스트로 분류했는데 이 부분에서 점수를 매기고 우선순위대로 학습하며 재검토 후 제거 여부를 판단한다.

지식 공백을 찾아 메꾸자 가장 좋은 방법은 내가 아는 것을 설명해 보는 것이다. 체크리스트에 가능성 점수를 매기자. 

연결하기

지금까지 가설을 세우고 실험을 하면서 얻은 통찰력을 통해 새로운 정보를 찾을 수 있으며 이를 바탕으로 처음부터 위 단계를 밟으며 문제 해결에 더 가까워질 수 있다. 피드백 루프 형성

 

마치며

kciter님도 문제해결을 위한 개발자의 사고방식이 얼마나 중요한지 말해주신 것 같습니다. 물론 디버깅이라는 주제로 글을 작성하셨지만 다른 개발 분야를 관통하는 주제를 다뤄주신 것 같아 많은 도움을 받은 글이 되었습니다.

많은 개발자 선배님들이 이 마인드 셋에 진심이신 것 같습니다. 기술이 계속 발전하면서 개발자란 무엇인가 생각해 볼 때가 많았는데, 마인드 셋을 재 점검 할 수 있는 기회가 되었습니다.