졸릴 때마다 이 노래를 듣습니다...
오늘은 베이직반에서 디버깅을 알려주신다고 해서 들으러 갔습니다.
그렇기 때문에, 오늘 들었던 심화 주차 강의 내용도 포함해서 같이 작성해보겠습니다.
게임을 하다 보면, 버그라는 개념이 자연스럽게 머릿속으로 들어오게 됩니다.

위처럼 재밌어 보이는 버그도 있지만,

위처럼 버그로 인해 망해버린, 유명했던 게임 회사도 있습니다.
이렇듯 소프트웨어의 버그는 가볍게 넘길 문제는 아닙니다.
디버깅이라는 용어의 유래는 1940년대에 하버드 대학에서 근무했던 Grace Hopper 제독 시절로 거슬러 올라갑니다. 그녀의 동료 중 한 명이 대학의 컴퓨터 작동을 방해하는 나방을 발견하자, 그녀는 동료들에게 ‘시스템을 디버깅하고 있구나’라고 말했습니다.
디버깅은 말 그대로 버그를 잡는 작업입니다.
버그를 잡지 않고 놔두게 되면, 소프트웨어 품질과 사용자 경험이 나빠질 수 있습니다.
그렇기 때문에, 개발자라면 당연히 버그를 잡는 것이 중요합니다.
그럼 이런 버그를 일으키는 오류의 종류에는 어떤 게 있을까요? 일반적으로 다음과 같은 오류가 있습니다.
ex) 지정한 타입과 초기값 타입의 불일치
val abc: Int = "hi"
ex) .. 또는 until 사용 방법 부적절
// 원하는 값 5 출력값 4
var a = 0
for(i in 1 until 5) { a++ }
return a
ex) NullPointerException
val a: Int? = null
println(10 - a!!)
이런 오류들이 발생하면, 개발자는 오류를 수정하여, 앱의 성능과 사용자 경험을 높여야 합니다.
다만 오류를 그냥 해결하기란 쉽지 않습니다.
구문 오류는 앱 개발 환경에서 개발자에게 표시를 해주고,
런타임 오류는 적어도 Logcat을 통해 어느 정도 해결할 수 있지만,
논리 오류는 개발자가 직접 어느 부분이 틀렸는지 Log를 사용하는 식으로 해결해줘야 한다는 번거로움이 생깁니다.
깊이가 짧고, 간단한 로직이라면 쉽게 해결될 수 있겠지만, 수천 글자의 코드라면 어떨까요?

논리 오류를 찾기가 쉽지만은 않을 겁니다.
그럼 저희는 24시간 365일동안 논리 오류를 찾기 위해, 하나 하나 Log를 찍어가며 밤을 새야 할까요?
다행히도 안드로이드 스튜디오에서는 까다로운 오류들을 해결하기 위해 디버깅 모드가 존재합니다.
디버깅 모드를 사용 방법은 다음과 같습니다.
1. break point를 설정한다.
안드로이드 스튜디오에서 코드 왼쪽의 숫자 부분을 클릭하면 설정할 수 있습니다.
2. 디버그 모드를 실행한다.
3. 평소처럼 실행하다가 break point에서 멈추면 아래에 있는 Debug 창을 확인한다.
위처럼 현재 해당 위치의 변수가 어떤 값을 갖고 있는지 확인할 수 있습니다.
Debug 창에서는
이런 버튼들이 존재합니다. 하나씩 설명해보겠습니다.
Resume Program : break point를 벗어나고 다음 break point 전까지 Debug 모드를 종료하는 버튼입니다.
Pause Program : 실행 중인 앱을 일시 정지하고, Debug 모드로 들어가는 버튼입니다.
Step Over : break point의 다음 줄로 이동하는 버튼입니다.
Step Into : 메소드 안으로 이동하는 버튼입니다. Step Over는 줄 단위로 이동하지만, Step Into는 메소드 단위로 움직입니다.
Step Out : Step Into와 반대로, 메소드 밖으로 이동하는 버튼입니다.
디버깅 모드를 잘 사용하면, 흐름과 변수의 값을 확인할 수 있기에, 잘 사용하면 오류를 쉽게 해결할 수 있습니다.
저도 평소에 그냥 Log를 무작정 찍어보는 편이어서, 코드 이곳저곳에 한 줄씩 로그 코드가 적혀 있는데
앞으로는 디버깅 모드를 써봐야겠습니다...
내일은 Retrofit을 정리하고, 코루틴 공부를 해볼 생각입니다.
앞으로 TIL을 조금 늦게 내더라도 이렇게 정리하면서 해보면 어떨까 싶습니다.
끝.