대부분 처음공부할때 변수는 이렇게 작성하는구나, 함수(메서드)는 이렇게 작성하는구나, 함수호출은 이렇게 쓰면되는구나 정도에서 끝나버리는게 문제죠. 진짜 중요한건 함수 호출시 인자의 타입이 무엇이고 몇개인지, 반환하는 타입은 무엇이고 함수 내에서 발생할수 있는 예외가 있는지 등 동작하는 과정과 내용을 이해하는건데 그 내용을 파악하지않고 지나가버리니 함수호출했는데 에러가나요 -> 알고보니 인자가 필요한 함수호출 이런 말도안되는 문제가 발생하는거죠.
이거 바보 같은 소리임. 버그 증상이 뭔지 확인했으면 논리적으로 먼저 따져서 해야지 -> 이게 영상에서 말하는 빤히 쳐다보는거 그냥 무턱대고 자기가 뭔 실수를 했는지 찾지는 않고 그냥 계속 여기 고치고 저기 고쳐서 돌려보는 주니어 수도 없이 봄 그리고 디버깅 툴 쓸 수 없거나 제한된 환경이 많음. 그럴때는 논리적으로 사고해서 이 프로그램이 어디서 잘못된 상황인가 따져나 가는거 무척 중요함
이 댓글이 필터처리되어 있었는데 말 자체는 맞는 말씀이라서 다시 살려냈습니다. 이 영상은 꼬꼬마 초보들 (제목대로 대학생 수준) 질문글 보다가 만들었습니다. 상당수의 질문이 (자기가 아무것도 안해보고) "이거 왜 안돼요?" 입니다. 결과적으로 나중에는 팔장끼고 모니터 째려보거나 한숨 쉬면서 산책하는 시간이 길어져야 하는것이 맞는데, 처음에는 손이 바빠야 합니다. 현재 내 머리속에 들어있는 정보로 오류가 바로 떠오르지 않는다면 추가적으로 정보를 취득해야 합니다. 디버거를 돌리거나 출력을 해보고 분석해야죠. "주니어"들이 시행착오 반복으로 시간을 낭비하고 있다면 그들이 초보때 제대로 디버깅 연습을 안했기(못했기) 때문입니다. 별찍기 같은거 시간 낭비라고 하는 사람들도 있는데, 별찍기 같이 실행 시간이 짧고 간단한 문제를 스스로 고생하면서 풀어내야 나중에 순수하게 머리로 디버깅해야 하는 상황에 적응할 수 있습니다. 글을 읽는 사람이 기분좋게 쓰진 않으셨지만 "논리적으로 사고해서 이 프로그램이 어디서 잘못된 상황인가 따져나 가는거 무척 중요함" 이거는 중요하다는 것에 동의하기도 하고 제 영상이 오해의 여지가 있을 수도 있어서 댓글 살려놓고 갑니다.
초보적인 예를 들어 내가 만든 패키지를 import를 했는데 왜 인식을 못하지? 분명 ctrl cv했고 오타도 없는데... 이런건 기술에 대한 미흡이라 없는 지식 짜봤자 의미 없으니 바로 검색 때리는 게 맞는 것 같고 좀 더 고등적인; 내가 짠 코드 왜 내 생각대로 안흐르지? 이건 자기가 생각해보는 게 맞는 것 같네요
안녕하세요? 좋은 질문입니다. 쇼츠라서 오해의 여지가 있는데 뇌를 컴퓨터에 직접 연결하는거 아니면 눈으로 보긴 봐야죠. 문제가 생겼을 때 코드만 뚫어져라 쳐다보는 학생들이 의외로 많습니다. 코드를 다시 검토해보는 게 나쁜건 아닌데, 제가 오랫동안 가르쳐온 경험상 눈으로만 보다가 모르겠어요 하는 질문들이 굉장히 많습니다. 초보때 모르는 것을 만나는 것은 당연합니다. 그것을 어떻게 해결하는 지가 진짜 공부입니다. - 컴파일 오류라면 에러 메시지 부터 읽어본다. (안 읽어보고 안돼요 하는 경우 엄청 많습니다. 저도 그랬어요.) - 오류 메시지 자체가 이해가 안간다면 오류 메시지를 복붙해서 구글 검색한다. 비슷한 사례들을 보면서 내 코드에서 왜 이런 오류가 발생했는지 추측해본다. - 실행은 되는데 기대와 다르게 작동한다면 원인을 찾아들어간다. 내가 탐정이 되었다고 생각한다. - 초보때는 디버거 사용하면 편하다. 디버거의 기능을 다양하게 활용하는 것도 좋은데 보통 여러 번 디버깅 하다가 "디버거에 이런 기능이 있으면 좋겠다" 싶어서 찾아보면 나온다. - 작성하는 프로그램이 커지면 디버거를 사용할 수 없는 경우도 있다. 예를 들면 디버깅 모드에서는 작동 속도가 느려서 결과를 보는데 너무 오래 걸릴 수 있다. 이럴때는 로그 파일로 여러가지 정보를 출력해서 분석하는게 더 효율적이다. 미국에서는 메모장만으로 코딩과 디버깅을 시키는 경우가 있는데 이런 능력이 있는지를 보는 것이다. (문법 외웠나를 보려는 것은 아닌데 문법도 못 외울 정도로 코딩량이 적었다면 당연히 탈락) - 원인을 찾았거나 또는 정확히 원인은 모르겠지만 더 많은 정보가 필요할 경우 코드를 바꿔서 실행해본다. 과학 시간에 배운 비교군/대조군 처럼 결과의 차이로부터 다시 한 번 어디가 문제인지 추측해본다. - 경험이 어느정도 쌓이면 고참 프로그래머들처럼 팔짱끼고 생각하는 시간이 길어진다. 팔짱끼고 생각하는 시간에는 보통 오류의 원인을 찾는 것 뿐 아니라 오류를 수정하면서 설계를 어떻게 바꿔야 하나 고민하는 시간이 포함된다. 올바르게 공부해나가시는 데에 도움이 되기를 바랍니다.
![POSTECH vs KAIST Showdown Stories [POSTECH Computer Science Department] | Jeongwaja ep.70](http://i.ytimg.com/vi/-k_Q9Svr7j4/mqdefault.jpg)
![POSTECH vs KAIST Showdown Stories [POSTECH Computer Science Department] | Jeongwaja ep.70](/img/tr.png)
![[#갓구운클립] '오늘도 찢었다..!' N사 개발자 자기님이 말하는 취준 일과ㄷㄷ 직장인으로서 가장 좋아하는 하루는? (주말 제외😂) | #유퀴즈온더블럭](http://i.ytimg.com/vi/7NZ7l1O60Ag/mqdefault.jpg)
풀버전
ruclips.net/video/hFPidh7H7GY/видео.html
문제 풀고있는 사람은 찐 컴공 ㅋㅋㅋ
가장 ㅈ된건 이게 왜 작동하는지 모를때 라는거임... 이건 진짜 애메함 ㅋㅋㅋㅋ
답은 5번,,, 컴공 졸업자입니다😂
대부분 처음공부할때 변수는 이렇게 작성하는구나, 함수(메서드)는 이렇게 작성하는구나, 함수호출은 이렇게 쓰면되는구나 정도에서 끝나버리는게 문제죠.
진짜 중요한건 함수 호출시 인자의 타입이 무엇이고 몇개인지, 반환하는 타입은 무엇이고 함수 내에서 발생할수 있는 예외가 있는지 등 동작하는 과정과 내용을 이해하는건데 그 내용을 파악하지않고 지나가버리니
함수호출했는데 에러가나요 -> 알고보니 인자가 필요한 함수호출
이런 말도안되는 문제가 발생하는거죠.
코딩테스트 웹에서 봐보면, 눈으로 디버깅할수밖에 없음. 내가 문제 해결을 위해 이렇게 저렇게 찍어보고 어떻게 나오는지도 확인해봐야 하는데 간단한 프린트문도 못찍게 해놓음.
아, 맞아요. 그래서 공부하면서 디버깅을 많이 해봐야 합니다.
코딩테스트에서 프린트 찍을 수 있지 않나요? 저 볼때는 가능 했던거 같은데
@@helloWorld-o3b 테스트마다 다릅니다 허허
@@helloWorld-o3b 디버거를 돌리는게 안돼죠
요새는 됩니다
그냥 검색하세요. 자신을 믿지 말고
괜찮아요 해결만 하면 괜찮아요
본능적인
....ㅋㅋㅋ 문제풀기
2^(2-r2)(2+r2) = 2^2 = 4
이거 다시보는데 웃기네요 ㅋㅋㅋㅋ 선생님 뒷목잡으심 ㅋㅋㅋㅋ
뭐야 우리교수님인줄.. 너무 똑닮아서 놀랬어요
눈의로 쫙 쳐다 보면서 고치기 시작하는게 왜 잘못된 버릇인지 전혀 이해가 안되는데
일단 눈으로 보기는 해야죠.
오오 숏츠
왜 풀고있었지..
이거 바보 같은 소리임. 버그 증상이 뭔지 확인했으면 논리적으로 먼저 따져서 해야지 -> 이게 영상에서 말하는 빤히 쳐다보는거
그냥 무턱대고 자기가 뭔 실수를 했는지 찾지는 않고 그냥 계속 여기 고치고 저기 고쳐서 돌려보는 주니어 수도 없이 봄
그리고 디버깅 툴 쓸 수 없거나 제한된 환경이 많음. 그럴때는 논리적으로 사고해서 이 프로그램이 어디서 잘못된 상황인가 따져나 가는거 무척 중요함
이 댓글이 필터처리되어 있었는데 말 자체는 맞는 말씀이라서 다시 살려냈습니다. 이 영상은 꼬꼬마 초보들 (제목대로 대학생 수준) 질문글 보다가 만들었습니다. 상당수의 질문이 (자기가 아무것도 안해보고) "이거 왜 안돼요?" 입니다. 결과적으로 나중에는 팔장끼고 모니터 째려보거나 한숨 쉬면서 산책하는 시간이 길어져야 하는것이 맞는데, 처음에는 손이 바빠야 합니다. 현재 내 머리속에 들어있는 정보로 오류가 바로 떠오르지 않는다면 추가적으로 정보를 취득해야 합니다. 디버거를 돌리거나 출력을 해보고 분석해야죠. "주니어"들이 시행착오 반복으로 시간을 낭비하고 있다면 그들이 초보때 제대로 디버깅 연습을 안했기(못했기) 때문입니다. 별찍기 같은거 시간 낭비라고 하는 사람들도 있는데, 별찍기 같이 실행 시간이 짧고 간단한 문제를 스스로 고생하면서 풀어내야 나중에 순수하게 머리로 디버깅해야 하는 상황에 적응할 수 있습니다.
글을 읽는 사람이 기분좋게 쓰진 않으셨지만 "논리적으로 사고해서 이 프로그램이 어디서 잘못된 상황인가 따져나 가는거 무척 중요함" 이거는 중요하다는 것에 동의하기도 하고 제 영상이 오해의 여지가 있을 수도 있어서 댓글 살려놓고 갑니다.
초보적인 예를 들어 내가 만든 패키지를 import를 했는데 왜 인식을 못하지? 분명 ctrl cv했고 오타도 없는데... 이런건 기술에 대한 미흡이라 없는 지식 짜봤자 의미 없으니 바로 검색 때리는 게 맞는 것 같고 좀 더 고등적인; 내가 짠 코드 왜 내 생각대로 안흐르지? 이건 자기가 생각해보는 게 맞는 것 같네요
채고의 조언!
ChatGPT
일단 디버거 키라 이 말이야
그럼 어떻게 오류 확인하나요? 눈으로만 보지 말고 뭘 해야하나요
안녕하세요? 좋은 질문입니다. 쇼츠라서 오해의 여지가 있는데 뇌를 컴퓨터에 직접 연결하는거 아니면 눈으로 보긴 봐야죠. 문제가 생겼을 때 코드만 뚫어져라 쳐다보는 학생들이 의외로 많습니다. 코드를 다시 검토해보는 게 나쁜건 아닌데, 제가 오랫동안 가르쳐온 경험상 눈으로만 보다가 모르겠어요 하는 질문들이 굉장히 많습니다. 초보때 모르는 것을 만나는 것은 당연합니다. 그것을 어떻게 해결하는 지가 진짜 공부입니다.
- 컴파일 오류라면 에러 메시지 부터 읽어본다. (안 읽어보고 안돼요 하는 경우 엄청 많습니다. 저도 그랬어요.)
- 오류 메시지 자체가 이해가 안간다면 오류 메시지를 복붙해서 구글 검색한다. 비슷한 사례들을 보면서 내 코드에서 왜 이런 오류가 발생했는지 추측해본다.
- 실행은 되는데 기대와 다르게 작동한다면 원인을 찾아들어간다. 내가 탐정이 되었다고 생각한다.
- 초보때는 디버거 사용하면 편하다. 디버거의 기능을 다양하게 활용하는 것도 좋은데 보통 여러 번 디버깅 하다가 "디버거에 이런 기능이 있으면 좋겠다" 싶어서 찾아보면 나온다.
- 작성하는 프로그램이 커지면 디버거를 사용할 수 없는 경우도 있다. 예를 들면 디버깅 모드에서는 작동 속도가 느려서 결과를 보는데 너무 오래 걸릴 수 있다. 이럴때는 로그 파일로 여러가지 정보를 출력해서 분석하는게 더 효율적이다. 미국에서는 메모장만으로 코딩과 디버깅을 시키는 경우가 있는데 이런 능력이 있는지를 보는 것이다. (문법 외웠나를 보려는 것은 아닌데 문법도 못 외울 정도로 코딩량이 적었다면 당연히 탈락)
- 원인을 찾았거나 또는 정확히 원인은 모르겠지만 더 많은 정보가 필요할 경우 코드를 바꿔서 실행해본다. 과학 시간에 배운 비교군/대조군 처럼 결과의 차이로부터 다시 한 번 어디가 문제인지 추측해본다.
- 경험이 어느정도 쌓이면 고참 프로그래머들처럼 팔짱끼고 생각하는 시간이 길어진다. 팔짱끼고 생각하는 시간에는 보통 오류의 원인을 찾는 것 뿐 아니라 오류를 수정하면서 설계를 어떻게 바꿔야 하나 고민하는 시간이 포함된다.
올바르게 공부해나가시는 데에 도움이 되기를 바랍니다.
제가 가르쳐줄때 항상 하는말이 있습니다.
코드를 한줄 한줄 봐라.
그냥 째려보면 해결되는게 아니라
코드 한줄한줄, 토큰 하나하나 풀어서 해석해야 코드에 어떤 오류가 있는건지 알 수 있습니다.
@@HongLab정말 좋은 조언입니다
그래서 답은요?
Print Driven Development
Gpt copliot 구글 도와줘