10 개의 디 버 깅 과 잘못된 제안

빈 텍스트 편집기 에서 새로운 텍스트 를 엽 니 다.코드 가 한 줄 도 없습니다.눈앞 에 나타 난 것 은 무한 한 가능성 과 희망 으로 가득 찬 항목 입 니 다.그러나 수천 줄 의 코드 를 다 쓴 후에 전체 프로젝트 가 bug 의 등장 으로 인해 무 너 졌 습 니 다.새로운 기능 을 추가 하 는 것 은 말 할 것 도 없습니다.이것 은 프로그래머 에 게 가장 큰 타격 일 수도 있 습 니 다.충만 한 열정 에 찬물 을 주 었 습 니 다.사실 가장 좋 은 소프트웨어 프로 그 래머 는 당연히 이러한 버그 를 발견 하고 복구 하 는 방법 을 알 고 있다.프로 그래 밍 을 시작 할 때 소프트웨어 공학 의 가장 좋 은 방법 을 통 해 버그 의 발생 확률 을 낮 춘 다.
bug 가 없 는 코드 를 쓸 수 있 는 프로그래머 는 거의 없 지만 해결 방법 은 항상 어려움 보다 훨씬 많다.다 중 실천 과 끈기 있 는 결심 이 성공 의 관건 이다.그래 야 청결 코드 를 써 서 소프트웨어 시스템 의 신뢰성 을 확보 할 수 있다.

버그 를 진압 할 수 있 는 공구 상자 들 을 살 펴 보 자.
1.출력 문
코드 디 버 깅 의 가장 중요 한 도 구 는 신뢰 할 수 있 고 진실 한 출력 문 구 를 삽입 하 는 것 이다.출력 문 구 는 수량 이 많 고 관리 하기 어 려 울 때 출력 문 에서 기록 시스템 을 적당 하 게 사용 하 는 것 은 같은 효 과 를 가 진 좋 은 방안 이 라 고 할 수 있다.많은 프로 그래 밍 언어 에는 Python 에 구 축 된 기록 라 이브 러 리 와 같은 기 존의 라 이브 러 리 가 설치 되 어 있다.
출력 문 구 는 프로그래머 가 데이터 값 과 변수 유형 을 검사 하 는 가장 빠 르 고 간단 하 며 직접적인 방식 이다.효율 적 인 출력 문 구 는 프로그래머 가 코드 를 통 해 데이터 흐름 을 추적 하고 bug 소스 를 신속하게 식별 하 는 데 도움 을 줄 수 있다.선진 적 인 디 버 깅 도구 가 많 지만 코드 를 디 버 깅 하고 싶다 면 이 일반적인 출력 문 구 는 프로그래머 가 가장 먼저 고려 하 는 방법 이 어야 한다.
2.디 버 거
소스 코드 디 버 거 는 출력 언어 방법의 논리 적 추 리 를 채택 했다.이렇게 하면 프로그래머 가 한 줄 한 줄 씩 코드 를 실행 하 는 동시에 변수 값 에서 끝까지 가상 컴퓨터 의 전체 상 태 를 모니터링 할 수 있다.또한 대부분의 프로 그래 밍 언어 는 여러 개의 디 버 거 를 가지 고 서로 다른 기능 을 제공 할 수 있 으 며 그래 픽 인터페이스,종료 프로그램의 정지점 설정,환경 내부 임 의 코드 의 실 시 를 포함한다.
많은 상황 에서 디 버 거 는 큰 인재 가 적 게 사용 되 었 다 고 할 수 있 지만,합 리 적 으로 이용 하면 디 버 거 는 틀림없이 효율 적 인 도구 이다.더 많은 디 버 거 기능 은 Python 디 버 거:pdb 를 보십시오.
3.버그 추적 시스템

일부 중대 한 소프트웨어 프로젝트 에 서 는 bug 추적 시스템 을 사용 하 는 것 이 필요 하 다.bug 추적 기 를 사용 하지 않 았 다 면 가장 전형 적 인 상황 은 프로그래머 가 기 존의 메 일 이나 채 팅 기록 을 정리 해서 bug 를 찾 는 것 입 니 다.더 나 쁜 것 은 프로그래머 가 다른 것 을 전혀 기억 하지 못 하고 bug 문서 만 기억 하 는 것 입 니 다.이러한 상황 이 발생 하면 bug 는 전체 코드 프로 그래 밍 으로 가득 할 것 입 니 다.더욱 심각 한 것 은 이러한 bug 를 식별 하고 그들의 위 치 를 확인 하 는 것 이 어렵 습 니 다.
간단 한 텍스트 파일 은 프로젝트 에서 최초의 bug 추적 시스템 으로 사용 할 수 있 습 니 다.코드 라 이브 러 리 가 계속 증가 함 에 따라 bug 에서 텍스트 파일 을 파생 시 키 는 데 시간 이 오래 걸 리 지 않 습 니 다.많은 상업 과 오픈 소스 의 bug 추적 소프트웨어 가 제공 하 는 해결 방안 은 모두 고려 할 수 있 습 니 다.어떤 bug 추적 소프트웨어 를 선택 하 는 지 먼저 명확 한 부분 은 프로 그래 밍 프로젝트 에서 비 프로그래머 들 이 이 bug 추적 시스템 을 신속하게 사용 할 수 있 도록 확보 하 는 것 입 니 다.
4. Linter
일부 프로 그래 밍 언어 에서 린 터 는 코드 를 작성 하고 실행 하기 전에 문제 영역 을 식별 할 수 있 도록 코드 에 대한 정적 분석 을 실행 할 수 있다.일부 다른 프로 그래 밍 언어 에서 Linter 도 구 는 문법 검사 와 스타일 강화 에 도움 이 된다.프로 그래 밍 을 할 때 편집기 에서 Linter 프로그램 을 열거 나 코드 를 작성 하고 실행 하기 전에 Linter 를 통 해 코드 를 전달 하 는 것 은 프로그래머 가 소프트웨어 를 사용 하기 전에 더 많은 오 류 를 발견 하고 바로 잡 는 데 유리 합 니 다.따라서 린 터 를 사용 하면 귀중 한 시간 을 절약 하 는 동시에 문법 오류,타자 오류 또는 데이터 형식 오류 로 인 한 bug 원본 을 찾 아 낼 수 있 습 니 다.
어떤 린 터 가 당신 에 게 가장 적합 한 지 알 고 싶 습 니 다.Python 의 린 터 도구:Pyflakes 를 보 세 요.
5.버 전 관리
어떤 중대 한 소프트웨어 프로젝트 에서 도 버 전 관리 시스템 을 소홀히 해 서 는 안 된다.예 를 들 어 Git,Mercurial,SVN 과 같은 버 전 관 리 는 서로 다른 코드 라 이브 러 리 버 전 을 서로 다른 기초 위 에서 분리 할 수 있 도록 허용 한다.
서로 다른 제어 버 전이 합 쳐 질 수 있 기 때문에 여러 프로그래머 가 같은 시간 에 같은 코드 라 이브 러 리 를 실행 할 수 있 습 니 다.버 전 제 어 는 코드 오류 에서 도 매우 중요 한 위 치 를 차지 하기 때문에 프로그래머 가 비교적 빠 른 버 전의 코드 를 되 돌 릴 수 있 고 가능 한 한 오류 가 발생 하기 전에 코드 라 이브 러 리 에서 오 류 를 복구 할 수 있다.
6.모듈 화
구조 가 부족 한 코드 는 bug 를 복구 하기 어 려 운 주요 원천 입 니 다.코드 가 이해 하기 쉽 고 이론 적 으로 통 하기 만 한다 면 프로그래머 에 게 bug 를 찾 고 신속하게 복구 하 는 것 은 그리 어 려 운 일이 아니다.다른 한편,중요 한 코드 일수 록 오류 가 발생 할 확률 이 높 고 이 오 류 를 찾 는 것 도 상대 적 으로 어렵다.
소프트웨어 를 디자인 하 는 구성 요 소 는 항상 고려 해 야 할 것 이 바로 코드 모듈 화 이다.코드 모듈 화 는 프로그래머 가 두 가지 방법 으로 소프트웨어 시스템 을 이해 하 는 데 도움 을 줄 수 있다.첫째,모듈 화 는 일정한 차원 의 추상 감 을 창조 할 수 있 고 모든 세부 사항 을 완전히 이해 하지 못 한 상황 에서 도 시스템 의 모델 을 상상 할 수 있다.예 를 들 어 프로그래머 가 상업 시스템 을 구축 하고 있 는데 신용카드 처리 모듈 을 고려 한 다음 에 이 모듈 이 다른 코드 와 어떤 관계 가 있 는 지 관찰 하고 신용카드 처리 모듈 의 모든 상세 한 내용 을 고려 하지 않 아 도 된다.둘째,모듈 의 상세 한 설명 은 이 상세 한 설명 은 다른 모듈 의 내용 과 헷 갈 리 지 않 습 니 다.마치 모든 카드 에 하나의 카드 번호 만 있 는 것 과 같 습 니 다.
7.자동화 테스트
단원 테스트 와 다른 유형의 자동화 테스트 는 모듈 화 와 매우 큰 관련 이 있 기 때문에 상부 상조 라 고 할 수 있다.자동화 테스트 는 코드 가 특수 한 입력 값 으로 소프트웨어 를 실행 하여 프로그램 운행 이 예상 한 것 과 일치 하 는 지 검사 하 는 것 이다.
유닛 테스트 는 주로 하나의 기능 성 을 검사 하 는 데 사용 되 지만 기능 테스트 는 특수 한 프로그램의 성능 을 검사 하고 유닛 테스트 와 결합 하여 소프트웨어 시스템 의 전체 부분 을 검사 하 는 데 사용 된다.테스트 프로그램 을 작성 할 수 있 는 테스트 프레임 워 크 가 많 고 대부분 인기 있 는 테스트 프레임 워 크 는 Kent Bent 가 작성 한 JUnit 라 이브 러 리 에서 파생 된 것 입 니 다.Kent Bent 는'테스트 구동 개발 방법'최초의 지지자 중 한 명 입 니 다.Python 표준 라 이브 러 리 는 JUnit 의 Python 버 전 을 포함 하 는데 PyUnit 또는 unittest 라 고 불 리 는 단원 테스트 프레임 워 크 입 니 다.
8.테 디 베 어 방법(고무 오리 테스트)

소프트웨어 프로 그래 밍 계 에 서 는 전설 적 인 인물 인 Brain Kernighan 과 Rob Pike 를 언급 할 수 밖 에 없다.테 디 베 어 디 버 깅 법 은 한 대학 컴퓨터 센터 에서 기원 되 었 다.여기 서 학생 들 이 신비 한 bug 를 만 났 을 때 먼저 책상 위 에 놓 인 테 디 베 어 에 게 문 제 를 설명 한 다음 에 선생님 이나 조교 에 게 도움 을 청 할 수 있다.그래서 곰 과 만 이야기 해도 문 제 를 해결 할 수 있 을 때 가 있다.이 디 버 깅 방법 은 정말 효과 가 있어 서 전체 소프트웨어 공학 업 계 를 휩 쓸 었 다.예 를 들 어 인쇄 문 구 를 인쇄 하 는 쪽 과 같이 복잡 한 도구 들 이 아무리 많은 바람 을 일 으 키 더 라 도 수출 문 구 는 아직도 오늘 인기 가 많다.
테 디 베 어 디 버 깅 법 과 비슷 한 방법 은 고무 오리 디 버 깅 법 이 라 고 합 니 다.침묵 을 지 키 는 고무 오리 에 게 설명 하 는 과정 에서 당신 의 생각,관점,사고 와 실제 코드 가 서로 어 긋 나 는 것 을 발견 할 수 있 습 니 다.그래서 코드 중의 bug 를 찾 을 수 있 습 니 다.한 문제 가 세부 사항 을 충분히 묘사 하면 해결 방법 도 분명 하 다.너 는 이 방법 이 너무 어리석다 고 생각 하 니,너무 지혜 롭 지 못 하 다 고 생각 하 니?네,그렇게 하 는 사람 은 머리 가 좀 나 쁜 것 같 아 요.그러나 내 가 너 에 게 알려 주 고 싶 은 것 은 이 방법 이 확실히 효과 가 있다 는 것 이다.이것 이 바로'코드 리 뷰'의 초기 형태 이기 때문이다!
9.코드 주석 작성

주석 기능 은 코드 의 작성 목적 을 이해 하기 쉬 운 차원 에서 설명 하고 가능 한 한 많이 쓰 는 것 입 니 다.줄 마다 코드 가 무엇 을 하 는 지,어떻게 완성 하 는 지,이런 문 제 는 코드 를 통독 한 후에 쉽게 답 을 찾 아야 합 니 다.또한 각 기능 과 변수 에 합 리 적 인 이름 을 붙 이 는 것 도 코드 실시 과정 을 간소화 하 는 데 도움 이 된다.코드 줄 아래 의 공백 에 설명 을 써 서 왜 특수 한 실현 기능 을 사용 해 야 하 는 지,또는 코드 가 프로그램의 나머지 부분 과 어떻게 상호작용 하 는 지 등 을 대답 합 니 다.
상세 한 설명 을 작성 하 는 것 은 소프트웨어 공학 에서 신뢰 할 수 있 는 검사 절차 라 고 할 수 있 습 니 다.bug 가 없 는 코드 에서 도 똑 같이 사 용 됩 니 다.이렇게 되면 bug 가 나타 나 도 걱정 하지 마 세 요.주석 은 몇 시간 동안 잘못된 시간 을 절약 할 수 있 습 니 다.
10.문서 작성
코드 설명 은 프로그래머 가 간단 한 방식 과 개인의 관점 으로 작성 한 것 이 고 소프트웨어 문 서 를 작성 하 는 것 은 소프트웨어 시스템 의 기능 성 을 설명 하 는 동시에 사용자 도 이 소프트웨어 문 서 를 볼 수 있다.소프트웨어 유형 에 따라 문 서 는 프로그램 인터페이스,도형 인터페이스 또는 작업 절 차 를 상세 하 게 설명 할 수 있다.
문 서 를 작성 하 는 또 하나의 장점 은 소프트웨어 시스템 에 대한 이해 정 도 를 보 여 주 며 소프트웨어 시스템 이 완선 되 지 않 은 부분 이나 bug 소스 일 수 있 는 부분 을 지적 하 는 것 이다.