스트리트 코더 sprint 9 - 김종필#655
Conversation
|
우측에 있는 |
There was a problem hiding this comment.
Code Review
This pull request adds book reviews for Chapters 7, 8, and 9 of 'Street Coder', covering topics such as optimization, scalability, and debugging techniques. The reviewer provided several suggestions to correct Korean spelling, spacing, and typos in the newly added markdown files.
| ## 논의주제 | ||
|
|
||
| 여기서 언급하는 여러 디버깅 기법 중에 실제로 적용해 보고 효과를 본 사례가 있는지 얘기해 보면 좋을 것 같습니다. | ||
|
|
||
| 저는 두 가지인데 하나는 printf() 관련 내용입니다. | ||
| 저는 대학에 다닐 때도 그랬고 주니어 개발자 시절에도 printf()를 쓰기 보다는 디버거를 통해 값을 확인하고 문제를 파악하는 방법을 더 좋아했습니다. | ||
| 이건 학교 교수님이 디버거를 사용할 줄 아는 게 중요하다는 가르침 때문에 그런 것도 있습니다. | ||
| 하지만 책의 내용대로 디버거는 번거로운 부분이 있는 건 사실이고 실행의 흐름을 끊고 파악해야 하기 때문에 개발자의 집중력을 요구하는 행동인 것도 맞습니다. | ||
| 그래서 printf() (프로그래밍 언어별로 코드는 다르지만 로그 찍는 코드)를 통해 디버깅 하는 것도 좋다고 느낀 건 다른 개발자와 협업을 하면서 알게 되었습니다. | ||
|
|
||
| 다른 하나는 고무 오리 디버깅입니다. | ||
| 실제 고우 오리를 두고 대화를 하진 않았지만, 과거 디버거를 통해 디버깅을 할 때 혼잣말을 하면서 했던 버릇이 있었는데 | ||
| 이게 자신이 생각한 로직과 예외 상황을 검증하는 용으로 상당히 유용하다는 걸 많이 경험했기에, 한 번도 안해보신 분은 해보면 좋은 방법이긴 합니다. No newline at end of file |
There was a problem hiding this comment.
저같은 경우는 어느것 하나만 써서 효과를 봤다기 보다는 상황에 따라서 IDE에서 제공하는 디버거나 printf(로그 찍는 방식)을 둘다 활용하고 있습니다
이 둘을 나누는 기준은 환경인데, 로컬 환경의 경우 디버거를 활용해서, 버그 재현 및 원인 파악용도로 활용하고 있고, 개발환경 및 운영환경에서는 디버거를 붙여서 확인해보기 어렵기 때문에, 어쩔 수 없이 로그를 찍는 방식으로 디버깅을 합니다
쓰레드 덤프 같은 경우는 책을 보고 실습 정도는 해보았지만, 실제 업무환경에서 직접 해보진 않았고, 고무오리의 경우는 디버깅 방법론이라기 보다는 문제해결을 관점에서는 의도치 않게 내가 겪은 문제를 해결해보는 과정에서 자연스레 답이 나오는 것을 많이 경험해보았습니다
There was a problem hiding this comment.
저는 책에 나와있는 스택오버플로우 임시 작성글과 비슷한 방식을 사용합니다.
언뜻 고무 오리 디버깅과 유사하긴 한 것 같은데, 저의 상황을 아예 모르는 사람들에게 질문한다고 생각하면서 질문 글을 작성하다 보면 상황이 명료하게 이해되고, 해결되는 경우가 꽤 많았습니다.
There was a problem hiding this comment.
저의 경우에는 IDE 디버깅을 주로 사용하고, 로깅은 필요한 거는 info, 무시해도 되는 오류는 warn, 오류는 erro나 fatal로 하고 저자가 이야기하는 print는 debug로 찍는 경우가 많습니다. 그리고 debug의 경우에는 alpha, beta환경에서만 작동하고, real에서는 logLevel을 info부터 찍기 때문에 debug로깅은 남지 않습니다.
|
|
||
| ## 논의주제 | ||
|
|
||
| 여기서 언급하는 여러 디버깅 기법 중에 실제로 적용해 보고 효과를 본 사례가 있는지 얘기해 보면 좋을 것 같습니다. |
There was a problem hiding this comment.
최근에는 IDE의 디버거를 많이 사용하는 것 같습니다.
로컬이 아닌 k8s에 서비스를 띄어올려도 5005 포트로 Debug Remote Tomcat Server를 이용하면 로컬에서 하는 것 처럼 디버거를 사용할 수 있더라구요.
고무 오리 디버깅 같은 경우에는 다른 분에게 설명하다가도 혼잣말 하는 것과 비슷하게도 효과가 나타나서 종종 설명을 하거나 먼저 정리해보는 습관을 가졌습니다.
| ## 논의주제 | ||
|
|
||
| 여기서 언급하는 여러 디버깅 기법 중에 실제로 적용해 보고 효과를 본 사례가 있는지 얘기해 보면 좋을 것 같습니다. | ||
|
|
||
| 저는 두 가지인데 하나는 printf() 관련 내용입니다. | ||
| 저는 대학에 다닐 때도 그랬고 주니어 개발자 시절에도 printf()를 쓰기 보다는 디버거를 통해 값을 확인하고 문제를 파악하는 방법을 더 좋아했습니다. | ||
| 이건 학교 교수님이 디버거를 사용할 줄 아는 게 중요하다는 가르침 때문에 그런 것도 있습니다. | ||
| 하지만 책의 내용대로 디버거는 번거로운 부분이 있는 건 사실이고 실행의 흐름을 끊고 파악해야 하기 때문에 개발자의 집중력을 요구하는 행동인 것도 맞습니다. | ||
| 그래서 printf() (프로그래밍 언어별로 코드는 다르지만 로그 찍는 코드)를 통해 디버깅 하는 것도 좋다고 느낀 건 다른 개발자와 협업을 하면서 알게 되었습니다. | ||
|
|
||
| 다른 하나는 고무 오리 디버깅입니다. | ||
| 실제 고우 오리를 두고 대화를 하진 않았지만, 과거 디버거를 통해 디버깅을 할 때 혼잣말을 하면서 했던 버릇이 있었는데 | ||
| 이게 자신이 생각한 로직과 예외 상황을 검증하는 용으로 상당히 유용하다는 걸 많이 경험했기에, 한 번도 안해보신 분은 해보면 좋은 방법이긴 합니다. No newline at end of file |
There was a problem hiding this comment.
저는 책에 나와있는 스택오버플로우 임시 작성글과 비슷한 방식을 사용합니다.
언뜻 고무 오리 디버깅과 유사하긴 한 것 같은데, 저의 상황을 아예 모르는 사람들에게 질문한다고 생각하면서 질문 글을 작성하다 보면 상황이 명료하게 이해되고, 해결되는 경우가 꽤 많았습니다.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
sprint 7, sprint 8 때 말씀드렸지만
"AI가 다 해주는데, 지금 이 내용이 무슨 의미가 있냐" 와 같은 흐름으로 절망을 안겨주는 말 금지입니다.
되도록 책 얘기 위주로 해 주시고, 리뷰나 논의 주제 얘기하면서 AI 얘기 끼얹어서 하는 것 까진 막지 않겠습니다.
Close #652