안녕하세요,
이번 강의에서는 디버깅에 대해 이야기 할게요.
네 여러분이 이해해야 할 중요한 개념입니다 특히 버그를 찾아
고칠 수 있는 도구와 방법을 이해해야 하죠
디버깅은 프로그램에서 오류를 찾고 고치는 과정이죠
보통 논리 오류죠
로직과 논리와 구문 에러의 차이점을 말씀드릴게요 컴파일 구문 에러도 포함할
수 있어요
문법 오류에 대한 전체 과정이죠
디버깅은 컴파일러가 말하는 걸 이해하는 거예요
처음 발견한 문제를 고치는 데 집중하고 싶잖아요
여러분 일반적인 컴파일러 오류와 경고를 살펴보고자 합니다 여러분이 듣게 될 수도 있는 거죠
컴파일러에 대해 항상 알아야 할 것 중 하나는 컴파일러가 여러분에게 몇 가지 오류를 줄
수 있다는 거죠
항상 첫 번째 오류에 집중해야 합니다 첫 번째 오류는 다른 오류를 낳을 수 있거든요
오류일 수 있습니다 프로그램에서 오류가 5개 보이면 오류가 발생하는 거죠 컴파일러가 오류가 1개라고 말하고
있다면요 첫 번째 오류가 다른 오류를 초래할 수도 있고요
그래서 항상 첫 번째 오류를 보고 그걸 먼저 고치는 게 중요해요
이 간단한 예제에선 이 코드에 여러 개의 에러가 있었어요
그런 거 없어요
시작 괄호인 중괄호가 없어요
세미콜론이 없어요
스트링을 반환하는 거예요
네 이걸 저장하고 컴파일하면 빨간 오류가 나와요
컴파일하면 오류가 3개란 걸 알려주죠
네 7번째 줄에서 마지막 오류를 선택해선 안 되죠 이 경우엔 실제 오류지만요
첫 번째 오류만 고치면 되죠
네 네 재편집해서 다시 실행하면 돼요
하지만 이렇게 하는 이유는 상위 레벨의 오류를 고치기 위해서입니다 그 오류는 다른 문제를 일으킬
수 있거든요
첫 번째 에러를 고치는 데 집중하세요 디버깅과 버그를 찾고 고치는 과정은 아주 복잡합니다 간단한
에러를 찾는 것부터 분석을 위해 많은 데이터를 수집하는 것까지 말이죠
상황에 따라 다르죠
네 로그 외에 어떤 정보도 제공되지 않을 때가 있어요 그런 경우엔 분석을
해야 하죠
반복할 수 없는 버그가 있을 때도 있어요
아주 드문 경우라 재현할 수가 없어요
보통 그럴 때 일지 같은 걸 분석하죠
프로그래머가 디버그하는 건 필수 기술이죠
엄청난 시간과 돈을 절약할 수 있는 문제 해결 기술이죠
배워야 할 중요한 기술이죠
중요한 기술이에요
연습이 필요해요
그냥 가는 게 아니에요
네 디버깅을 더 잘하기 위해 적용할 수 있는 기술과 방법이
있어요
소프트웨어 코드를 정말 잘 쓰는 개발자들을 꽤 많이 알고 있어요
언어는 잘 이해하지만 디버깅 실력이 형편없죠
벌레가 생길 수도 있고 벌레를 해결하려는 첫 번째 의도가 주제에서 벗어날 수도 있죠
이것도 연습이 필요하죠
네 디버깅에 점점 능숙해지고 문제를 찾고 고치는 법을 이해하게 될 겁니다
하지만 그것도 배워야 하는 거죠
관리 단계는 소프트웨어 라이프 사이클에서 가장 비싼 단계죠
제품을 출시하고 나서 관리하는 단계가 있어요
유지하려면 새로운 버그를 고치고 새로운 기능을 추가해야 하죠
네 그래서 예를 들어 Windows가 Windows 10 같은 새 운영 체제를 출시할 때 해당 소프트웨어를 생산하지
않을 수도 있어요
아마 10년은 더 쓸 거예요
네 여전히 Microsoft의 책임입니다 새로운 버그가 발생하거나 소프트웨어에 새 버그가 발견되면 고쳐야 하니까요
그래서 자동 업데이트를 누르고 그런 걸 하는 거죠
그리고 시장 변화와 기술 변화에 따라 운영 체제도 새로운 기능을 갖게
된다는 걸 알게 되죠
그래서 관리가 아주 중요해요
그 결과 버그를 찾아 고치는 건 아주 중요해요
하지만 벌레는 피할 수 없다는 걸 알아두세요
모든 소프트웨어에 버그가 있어요
아무도 완벽한 코드를 쓸 수 없어요 꼭 완벽한 코드를 써야 하는 건 아니죠
시간이 지나면서 상황이 변했죠
그 결과 버그가 발생할 수도 있어요
이해하셔야 합니다 소프트웨어에 버그가 있다고 해서 그게 엉성한 코드는 아니죠
어쩔 수 없죠
네 버그가 있어도 괜찮아요 있잖아요 버그를 찾아서 고치면 훨씬 좋아요 뭔가를 성취한다는
느낌이 들거든요
흔한 문제죠
화면에 관련된 특정 문제에 관해 좀 더 얘기할 거예요
하지만 디버그할 때 흔히 발생하는 문제는 논리 오류죠
네 논리 에러는 코드가 컴파일하는 문법 에러의 반대와는 관련이 없어요
작동은 하지만 원래 목적을 달성하진 못했죠
그러니까 어떤 종류의 논리나 의도된 기능이 잘못된 거죠
IF 문이 있는데 잘못된 조건에서 IF 문으로 뛰어든 거죠
네 루프가 있는데 루프가 횟수를 잘못 실행하거나 정렬을 잘못할 수 있어요
기능은 고장 났지만 컴파일러는 모든 게 정상이라고 하죠
논리 오류의 예가 여기 있어요
네 논리 오류는 구문은 맞는데 원하는 결과가 틀린 경우입니다 논리 문제
때문에요
이 코드에서 for 루프 끝에 세미콜론이 있는 걸 보실 수 있어요 구문적으로 올바른 거죠
하지만 for 루프가 5번 실행되리라 예상하죠
하지만 아니에요
1회 실행 시간밖에 안 돼요
네 빌드를 하면 이 프로젝트를 빌드하면 경고가 보이죠 좋아요 경고를 수정해야
해요
하지만 컴파일은 성공적이었죠
네 이 프로젝트를 실행하면 한 번만 실행되고 Hello World는 한 번만 프린트된다는
걸 알 수 있죠
논리 오류의 예죠
문법 에러는 컴파일러와 직접적으로 관련 있어요
언어 규칙을 따르지 않는 것들이죠
문장 끝에 세미콜론이 없어요
엔딩이 없죠?
왼쪽 괄호요
브래킷이 빠졌네요
키워드를 잘못 쓴 거죠
네 문법 에러는 보통 컴파일러에 의해 발생하죠 논리 에러는 테스트 단계에서 프로그래머가
발생합니다
기억 손상도 흔한 문제죠 특히 C에서요
네 정확히 할당했는데 기억을 자유롭게 하지 못하면 달랑거리는
레퍼런스 같은 게 생기거나 사용되지 않는 기억과 관련된 기억력에 문제가 생길 수 있어요
메모리가 새기도 해요
메모리 오류의 예가 여기 있네요
네 이 코드에서 메모리가 누출되고 있어요 포인터 얘길 안 했네요
동적 메모리 할당은 아직 얘기 안 했죠
C#에선 프로그램 실행 중에도 메모리를 할당할 수 있어요
말코손바닥사슴 기능을 쓸 수 있어요
그래서 기억을 표시하고 할당하지만 풀어놓지는 않아요
이 코드를 빌드하고 실행할 수 있고 모든 게 순조롭지만 이 오류를 해방하진 않았어요
네 이 메모리 오류를 수정하기 위해 해야 할 일은 free라고 입력하고 free
X로 포인터를 해제하는 거죠
하지만 메모리를 할당하면 자유롭게 할 수 없죠
메모리 누출이에요
다른 예는 이겁니다 메모리를 할당하지 않을 경우 포인터를 생성해 할당하려고
할 경우 메모리 손상 현상이 발생합니다 메모리는 할당되지 않으니까요 그리고
그에 값을 할당해야 하죠
네 지금까지 메모리 손상과 성능, 확장성의 예제를 살펴봤는데요
네 원래 기능 그대로의 상태라면 문제가 될 수 있어요 코드는 구문적으로 정확하지만
효율적이지 않거나 그걸 지원할 하드웨어가 없을 때요
네 서버를 실행하는데 모든 요청을 지원할 하드웨어가 충분하지 않으면
정말 정말 느려질 거예요
또는 10명의 사용자와 작업할 수 있는 프로그램을 작성했는데 사용자가 너무 많으면
데이터베이스가 정체되어서 속도가 안 날 수도 있어요
네 네 코드는 작동하지만 많은 수의 사용자나 그런 걸 처리하도록 올바르게 설계된
건 아니죠
통일성이 없어요
코드에서 문제가 될 수 있어요 코드와 관련된 품질이 감소하는 거죠 혹은 함수가 너무
많은 일을 하는 거죠
그렇죠 단일 초점이 아니에요 심지어 앱도 기능이 너무 많고 사용되지
않는 기능이 있어요 그래서 재설계가 필요할 거예요
이 프로그램은 모듈화되지 않고 응집력도 없어요
네 하나의 큰 기능이 너무 많은 일을 하고 있어요 수백 줄의 코드 수천 줄의
코드요
함수를 헬퍼 함수로 나눠서 모듈을 분리하는 거죠
프로그램이 훨씬 더 조화롭고 유지하기 쉬워지죠
네 초기화를 하는 주요 메서드를 갖는 대신에 입력 읽기 찾기 차이점
찾기 제품 찾기 쿼티언트 찾기 코드를 생성해서 헬퍼 모듈에 넣고 코드를
분리합니다 분리를 통해 버그를 찾고 고치는 것이 훨씬 쉬워지죠
네 C에서는 응집력이 중요해요 도우미 방법을 제공함으로써 응집력이 높은 곳을
결정하죠
단단히 연결해요
이건 코드 품질과도 관련이 있어요
종속성이 많은 곳이죠
결합은 응집과 달라요
하나로 통합하는 게 중요해요
커플링은 함수나 개체 간의 종속성을 갖는 곳이죠
커플링과 전역 변수에 대해 얘기했죠
네 네 전역 변수가 다양한 함수에 사용될 경우 함수들 사이에 종속성이
생길 수 있어요
네 여러분이 코드를 작성할 때 특히 고품질의 코드를 작성할 때 여러분이
추구하는 건 응집력은 높고 결합력은 낮은 거죠
디버깅 과정이죠
네 네 오류를 찾아서 고치기 전에 먼저 해야 할 일은 문제를 이해하는
거예요
이건 관련이 있어요. 그냥 뛰어들어 코드를 보는 것이 아니에요. 테스터와 함께 앉아 요구사항을
이해하고 어떻게 되는지 이해하세요.
무슨 일이 벌어지는지 모르면 영영 모를 테니까요
풀려고 하지 마세요
네 벌레를 이해하고 나면 복제하려고 하세요 벌레를 복제하면 더 많은 정보를 얻을 수 있어요 그리고 그
벌레를 복제하면
벌레를 번식시키는 게 항상 가능한 건 아니에요 아주 드문 상황에서 발생할 수 있으니까요
네 그래서 예를 들어 버그의 경우 인종 문제나 메모리 손상 같은 특정 유스 케이스에서만
발생할 수 있고 간헐적인 문제일 수 있어요
그게 사실인가요?
재현할 수 없죠
디버그가 점점 어려워지겠죠
그걸 재현할 수 있다면 정보를 충분히 수집해서 고칠 수 있어요
대부분의 문제는 고칠 수 있어요
네 또한 다중 스레드 환경에서는 문제를 복제하지 못할 수도 있습니다 병렬 프로세스나
스레드 문제일 수도 있죠
네 그것도 디버그가 아주 어려워요 문제가 뭔지 파악하고 나면 복제하려고
노력해야 합니다 복제할 수 있는 경우를 이해하고 난 후에요 그렇지 않다면
분할 정복 방식을 적용해 보려고 노력해야 합니다
네 버그를 분리해야 합니다 문제를 단순화해야죠 줄일 수 있으면 정보를 얻을 수 있지만
버그가 코드 어느 부분에 있는지 꼭 알려 주진 않으니까요
문제를 단순화하기 위해 여러분이 할 수 있는 건 원래 테스트 케이스 일부를 제거하는 겁니다 테스트를
너무 많이 하지 않도록요
네 문제를 더 작게 분리할 수 있어요 이런 특정한 상황에서만 발생하는 문제라고 하면 되죠
코드도 주석 처리하세요
함수는 구현이 아니라 텁팀을 갖는다는 얘기를 했었죠
때로는 테스트에 사용되어 문제 집합을 제한할 수 있죠
또한, 코드를 주석 처리하면 버그가 발생할 수 있는 코드가 줄어들게 되죠
네 코드를 주석으로 붙이거나 변화를 줄일 때 버그가 사라질 수 있어요 버그가 사라진다면
주석으로 붙인 코드가 문제를 일으킨다는 뜻이죠
네 하지만 본질적으로 하고 싶은 건 큰 프로그램을 작은 프로그램으로 만드는 거죠 테스트나
코멘트를 통해서요
또 다른 보편적인 기술은 코드 주위에 단위 테스트를 하는 거죠
네 단위 테스트가 실패하면 여러분 코드의 논리 또는 문제가 정확히 어디 있을지 알려드릴 수 있어요
네 버그를 분리하고 나면 코드에서 문제의 근원을 찾는 데 도움이 될 겁니다 문제를
일으키는 특정 코드요
때로는 디버거 같은 디버깅 도구를 사용하죠
네 디버거에 관해선 구체적으로 얘기하겠지만 보통은 여러분이 사용하는 IDE 통합 개발에
따라 달라요 IDE와 함께 오는 디버거가 있죠
독립 실행형 디버거도 있어요
C# 프로그래밍에 사용할 중요한 디버거는 GDB라는 건데요
네 누 디버거예요 좋은 도구죠 그래픽 도구예요 프로그램 실행을
멈추고 중단점을 추가할 수 있죠
그리고 그 다음에 실행을 멈추면 코드에서 한 줄씩 살펴보면서 변수의 값을 볼 수 있어요
그래서 실행되는 동안 코드에서 무슨 일이 일어나는지 볼 수 있죠
아주 유용한 도구죠
정말 유용해요
디버거를 실행할 거예요
중단점 추가하는 법을 보여드릴게요
네 시계 설정하는 법을 보여드릴게요 변수가 변하는 걸 보고 코드를 단계별로 작업할 수
있도록요
문제의 원인을 파악한 후에 문제를 해결하는 거죠
많은 경험과 연습이 필요하죠
그래요? 하지만 문제의 근원을 찾았다고 해서 고칠 수 있는 건 아니에요 경험에
따라 다르겠죠
다시 만들 수도 있습니다 다른 코드를 재디자인하거나 리팩터링하는 경우 특히 확장성
문제나 성능 문제에서는 소프트웨어를 확장할 수 있도록 재디자인해야 하죠
문제를 찾아 고치는 게 늘 쉽지만은 않아요
문제는 특히 스레딩이나 병렬 처리 같은 더 어려운 문제들이 있어요 고치기
더 어려운 것들이죠
하지만 코드를 더 쓸수록 이건 더 쉬워져요
마지막으로 미친 듯이 테스트해야 해요
여러 가지 테스트를 해 보세요
좋은 사례와 나쁜 사례를 번갈아 가며 문제를 해결했는지 확인하죠
기술과 도구도 사용 가능하고요
아주 보편적이고 자주 사용되는 도구는 print문을 사용하는 거죠
print문을 이용해 코드를 추적할 수 있어요
C#에서 print F 문을 사용할 수 있어요 코드에 여러 줄을 넣어 여러분의 위치를
표시할 수 있죠
프로그램이 중단될 경우 아주 유용하죠
추락 지점을 알 수 있어요
네 print문을 추가할 때 코드를 따라 추적할 때 print문에 출력을 추가해
변수의 값을 알 수 있습니다 변수의 값이 상태에 영향을 미치고 논리에 문제가 생길
수 있기 때문이죠
print문을 추가하는 건 아주 아주 유용해요
실행 흐름을 보여주고 오류를 분리하는 데 도움을 주죠
GDB에서 디버거를 언급했듯이 프로그램 실행을 모니터할 수 있어요
중단할 수 있어요 중단할 수 있어요 한 줄씩 실행하고 재시작하고 중단점을 설정하고 변수와 메모리를 볼 수 있어요
문제가 어디 있는지 진단할 때 아주 유용하죠
로그 파일요
일지 파일도 아주 유용합니다 특히 재현할 수 없는 벌레들에게는요
나중에 분석해서 도청 당시 어떤 일이 있었는지 알 수 있어요
그 말은 여러분이 여러분 코드에 훌륭한 로깅 문을 제공해야 한다는 거죠 이게
유용해지려면요
네 그래서 여러분은 자신만의 로그 파일을 만들어 프로그램이 실행될 때 그 로그에 작성할 수 있습니다 그래서 오류가
발생하면 그 로그를 개발자에게 보낼 수 있죠
맞아요 복사기 작업에서도 자주 쓰는 방법이에요 문제가 생기면 복제할 수 없고 현장에서
마주칠 수도 있거든요
버그가 발생했을 때 무슨 일이 있었는지 일지에 접속해야 해요
감시 프로그램이에요
네 메모리 사용과 네트워크 트래픽 위협과 객체 정보를 모니터하고 런타임 분석하는 소프트웨어가
있어요
메모리가 너무 많이 할당되어도 삭제하지 않을지 알려줄 수 있어요
네 너무 많은 패킷을 전송하는지 혹은 소프트웨어가 확장
가능한지 알려줄 수 있는 도구죠 네트워크 트래픽이 증가하면
응답 시간이 감소하는 게 보여요
네 네 스레드에서 어떤 일이 일어나는지
볼 수 있죠
그럼 실 같은 문제를 진단할 수 있어요
오류를 찾아 고치는 다른 디버깅 도구도 있죠
예외 처리를 사용할 수 있어요
많은 프로그래밍 언어에는 예외 처리가 있어요
네 불행히도 C는 안 그렇죠 예외 처리기는 런타임에 충돌을 예방하고 많은
일을 해요
보는 건 안 되지만 이해는 할 수 있죠
시어캐치 블록 같은 거요
정적 분석기요
C 고정 분석기에 사용할 수 있는 정적 분석기가 많아요
실제 실행 파일 없이 소스 코드를 분석하세요
프로그램을 실행할 필요는 없어요
한 줄씩 진행하면서 소스 코드를 보죠
소스 코드를 구문 분석하면서 알려진 문제를 찾아요
의미론을 확인할 수 있죠
그렇게 만들 수 있죠
그게 다예요
네 미확정 변수가 없어요 만약 새 메모리를 할당한다면 지울 수 있어요
실행되지 않는 데드 코드가 있다면 그 코드를 삭제할 수 있어요
레이스 상황이나 교착 상태도 분석할 수 있어요
제가 일하는 곳에는 정적 분석기가 몇 대 있어요
네 커버리티라는 것도 있는데 꽤 인기있는 거죠 코드 소나 툴도 사용하고 있어요 전체 기준선과
전체 소스 집합에서 이걸 실행해 볼게요
새 파일과 새 코드를 도입할 때마다 해당 도구가 해당 코드에 실행돼 코드의 즉각적인 이슈를
확인할 수 있습니다 입증되지 않은 변수까지도요 메모리 누출 등도요
구문을 분석하지 않아요
컴파일러가 왜 있겠어요?
네 여러분의 소프트웨어로 실행할 수 있는 포괄적인 시스템 간 테스트를 실행하는 테스트
스위트도 많아요
네 테스트는 항상 중요합니다 하지만 자동화해서 새로운 빌드를 할 때마다 특정
테스트를 수행할 수 있다면 아주 도움이 될 수 있습니다 오류를 예방할 수
있고 오류 진단에도 도움이 됩니다
프로그램이 꺼진 후 디버깅하는 거죠
콜 스택에 대해 얘기해 볼 텐데요
네 이건 아주 유용한 메커니즘입니다 특히 C# 같은 언어에서 크래시가 발생하면 얻을
수 있는 정보는 세그먼트 오류 같은 것뿐이죠
네 크래시가 발생하면 어떻게 되죠? 많은 시간이 크래시되는 경로에 따라
핵심 파일이 생성됩니다 콜 스택을 분석해서 프로그램이 어디서 죽었는지 알 수 있어요
⇲
프로그램이 어디서 죽었는지 알려줄 거예요
콜 스택에 대해 배우죠
핵심 파일 분석에 관한 한 그건 좀 더 고급 기술이죠
C#에서는 코어 파일이 생성되고 분석할 수 있어요
네 좀 더 고급 기술이죠 소프트웨어에 디버깅을 할 수 있는 또 다른 방법이에요
오류 예방은요?
네 디버깅은 오류를 찾아 고치는 작업입니다 오류를 예방할 수 있다면 더 좋겠죠
오류를 예방하는 방법 중 하나는 고품질 코드를 작성하는 거죠
이건 소프트웨어 엔지니어들에게 초점을 맞추는 게 아니에요
많은 소프트웨어 엔지니어들이 코드를 작성하고 그것이 작동하는 한
그것에만 신경을 씁니다 출력이 올바른 한 그들은 다 끝났다고 생각하죠
하지만 질 낮은 코드도 있어요 그런 건 작성하면 안 되죠
네 강의에서 몇 가지 보여드렸지만 의미 있는 변수 이름 같은 건 아주
중요해요
혹은 필요 이상으로 루프를 사용하는 비효율적인 코드를 작성하거나 if문을 사용하거나
혹은 필요하지 않을 수도 있죠
이 모든 게 낮은 품질의 코드를 포함해요
네 100가지 다른 일을 하는 함수가 있고 응집력이 없다면 함수 하나에 줄이
5천 개고 코드가 모듈식으로 정리되지 않았다면 혹은 함수들 사이에
종속성이 많다면 모두 품질이 나쁜 코드니 그렇게 되지 않도록 노력해야죠
프로그램이 잘 짜인 기술을 사용하고 싶을 거예요
네 관리하기도 쉽고 응집력도 좋고 연결도 약하고 의미 있는 가명도 쓸 수
있어요
아주 중요하죠
아주 중요한 점이에요 유지 보수 단계가 아주 비싸거든요
낮은 품질의 코드를 작성하면 유지하기가 훨씬 어려워지죠
오류 분리나 새 기능을 추가하는 게 더 어렵죠
코드를 작성할 때 직원의 고품질 테크닉이 필요하죠
단위 테스트요
단위 테스트는 오류를 예방하는 데 큰 도움이 돼요
단위 테스트는 일반적으로 자동으로 실행되죠 단위 테스트를 컴파일할 때 회귀를 피할 수 있습니다
그게 가장 중요한 요소죠
회귀는 네 회귀는 새로운 코드 작성이죠
오랜 규칙을 어겼잖아요
그러면 안 돼요
네 어떤 소프트웨어가 작동하는데 여러분이 한 새로운 것이 그걸 망가뜨리면 즉시 알려받길 원하고 단위
테스트가 그걸 도울 수 있어요 왜냐하면 단위 테스트는 그 낡은 코드에 실행되고 그건 이렇게 말할 테니까요 이봐
이건 작동했는데 이제 실패하고 있어
전달되기 전에 새 코드에서 에러를 찾을 수도 있어요 왜냐하면 빌드한 후에 실행되니까 뭔가
잘못됐다고 즉시 알려 주거든요
시험적 개발이라는 개념이 있는데 아주 인기가 많죠
여기서 테스트를 먼저 작성하고 그 후에 코드를 개발하세요
네 여기서 목표는 첫 테스트를 작성할 때 실패하고 통과하기 위해 코드를 작성하는
거죠
TDD는 장점이 많아요 반대 사고방식인 셈이죠
네 보통 코드를 작성할 땐 코드를 먼저 작성하고 테스트를 작성하죠
TDD는 다른 사고방식을 제공해 줍니다 작은 덩어리로 작업하더라도
응집력 있는 코드를 작성할 수 있습니다 코드는 종속성이 많지 않습니다
왜일까요?
코드를 테스트할 수 있다면 코드는 그만큼 종속성이 많지 않다는 거죠
네 단위 테스트가 정말 크고 이런 다양한 것들을 조롱하는 경우 여러분의
코드가 다른 것에 아주 의존적이란 걸 알려주는 지표가 되죠
그렇군요 그래서 TDD를 사용하면 종속성이 없는 느슨하게 결합된 코드를 써야
하고 기능에 일관성이 있어야 해요
TDD는 장점이 많아요
좋은 문서를 제공하고 적절한 계획을 세워야죠
그냥 코드로 뛰어들어 구현하지 마세요
종이에 도안을 적어 주세요
슈도코드를 사용하세요
네
암호를 짜요
네 코드를 계획하고 요구 사항을 이해하면 좋은 디자인을 세심하게 할 수 있어요
많은 실수를 예방할 수 있죠
지금까지도 말씀드렸는데 분할 정복 형식의 접근법이 아주 중요합니다 작은
단계를 밟고 매 단계마다 꾸준히 테스트하세요 1,000줄의 코드를 작성해놓고 OK라고 하지 마세요
컴파일하고 테스트하지 마세요
좋은 접근법이 아니에요
너무 많은 변화를 한 번에 피하세요
네 수정을 할 때는 조금씩 적용해 주는 거예요 수정을 하나 추가하고 다음 단계를 시작하기 전에 철저하게 테스트해
보는 거예요 ?
모든 종류의 버그를 줄일 수 있고 문제 설정도 제한할 수 있어요
네 버그가 있다면 코드 어디에 있는지 즉시 알 수 있죠 컴파일하고
라인 수를 추가했으니까요
네 다시 말씀드리지만 디버깅의 중요성은 아무리 강조해도 지나치지 않습니다 고품질 코드를 작성하고 오류를 예방하는 것도요
네 이런 문제 해결 기술은 시간을 많이 절약하고 더 나은 프로그래머로 만들 수
있어요
네 다음 강의에서는 C# 프로그래밍 언어에서 공통적으로 발생하는 오류에 관해 얘기할
거예요
콜 스택에 대해서도 좀 얘기하고 싶어요
디버거를 통해 메뉴 옵션을 소개하고 시계 실행 및 중단하는 법을 알려드릴게요
그리고 일반적인 컴파일 오류도 확인하도록 도와드릴게요 컴파일러를 해석하는 방법이죠 컴파일
경고와 오류요
컴파일러가 이렇게 말한다면 무슨 뜻일까요?
컴파일러가 이런 경고를 한다면 무슨 뜻일까요?
고마워요