xkcd debugging

 

나는 PS하면서도 디버깅은 제대로 해본적이 없다…. 웬만하면 출력이나 반환같은것으로 끝냈는데, 웹개발하면서는 그게 안되겠더라. 너무 모르는게 많고 로직도 규모가 커서 이런 원시적인것보다 더 편한 툴을 사용해야 될 듯 했다.


나는 에디터로 Visual Studio Code를 쓴다, 요즘 상당히 인기를 얻고 있는 에디터인것으로 알고 있는데, 실제로 써보니 Atom보다 빠르고, Sublime보다 UI가 깔끔하고 extension도 많다. 꽤 좋은 듯 해서 웹개발용으로는 이걸 쓰고 있다.

다행히 디버깅도 지원한다. 거의 그냥 깔고 따라하면 된다 식으로 편하게 설정할 수 있는데, 나는 여기를 보면서 따라했다. 원래는 Firefox를 쓰는데 따로 세팅하기 귀찮아서 Chrome을 깔았다. 나중에 여유가 생기면 Firefox도 세팅해야겠다.


당연히 조약돌을 위한 세팅이고, 그래서 Meteor에 대해서만 나와 있다. 근데 Meteor도 문서가 있을 정도면, 다른 웬만한 것들도 있지 않으려나 싶다.

설치법 요약은 대략 다음과 같다. 당연히 원래 링크에 더 자세히 설명되어 있다.

  1. VS Code에 Debugger for Chrome 이라는 extension을 설치한다
  2. 내가 디버깅할 프로젝트의 packages.json 파일을 편집해서 debug 스크립트를 만든다. 이건 ‘내가 디버깅할떄 앱을 실행시키기 위해서 어떤 명령어를 쳐야 하는지’를 세팅하는 것이다.
  3. 디버깅의 launch.json 파일을 새로 만들어서 ‘디버깅할때 node가 어떻게 실행될 것인지’ 와 ‘Chrome이 어떻게 실행된 것인지’에 대한 설명을 추가하고, 이 두개를 동시에 하는 compound를 만든다.
  4. 디버깅한다. YAY!

그냥 따라만 하면 딱히 거슬릴것 없이 잘 작동한다.


앞서 말했듯이 나는 디버깅 경험이 거의 없는데, 그래서 어떻게 하는건지 모른다. 딱히 복잡하지는 않다. 나는 여기서 알았다. 다른 곳은 모르겠지만, VS Code에서 디버깅할때은 다음의 기능을 사용할 수 있다.

  • Step Into:  지금 보고 있는 줄에 함수(또는 메소드)를 호출하는 게 있었다면, 그 함수 안으로 ‘들어간다’. 즉 그 함수가 있는 곳으로 커서(?)가 이동한다.
  • Step Over: 지금 보고 있는 줄을 실행하고 다음 줄로 넘어간다. Step Into처럼 어디로 들어가는 것은 하지 않는다.
  • Step Out: 지금 보고 있는 줄에서 ‘빠져나온다’. 즉 현재 줄에서 쭉 내려가면서 return이 나올때까지 다 실행시키고, return해서 자신을 호출한 함수의 위치로 간다.
  • 디버깅 전에 breakpoint를 설정할 수 있다. 코드가 돌아가다가 Breakpoint가 나오면 커서가 거기에 멈추고, 유저의 판단을 기다린다.
  • Continue: 다음 breakpoint까지 논스탑으로 진행한다.
  • Watch: 현재 커서가 있는 위치에서 해당 expression의 값을 보여준다. 이거 개좋음
  • Variables: this를 포함해서, 현재 커서 위치가 있는 위치의 scope에 있는 변수와 그 값들을 모두 보여준다. 이것도 좋음
  • Variables 하고 Watch가 다른점이라면 Variables는 변수만 보여주는데 Watch는 그 변수를 적당히 조절해서 내가 원하는 값만 볼수도 있다. 예를 들어서, Posts라는 컬렉션이 있는데 Posts변수만 봐서는 그 내용물을 알수가 없지만, Posts.find().fetch()를 Watch하면 그 내용을 전부 볼수 있게 된다.

이렇게 하면 된다.


제대로 된 디버깅은 필수인것 같다. Console.log 쓰지 마세요 글을 읽었었는데, 이거 보니까 디버깅을 해야할것 같더라. 나중에 PS에서도 디버깅을 세팅해봐야겠다.