프로그래머가 버그 수정에 시간의 절반을 소비 할 수 있다고해도 과언이 아닙니다. 28 원칙에 따르면 대부분의 버그는 검색 엔진에서 찾을 수 있지만 (비즈니스 버그 제외) 나머지 20 % 버그는 종종 우리 시간의 80 %를 차지합니다.
이 문제를 해결하는 가장 좋은 방법은 버그 발생을 줄이는 것이지만, 아무리 줄여도 0으로 줄이는 것은 불가능합니다. 우리는 여전히 디버깅의 효율성을 향상시켜야합니다.
디버그 측면에서 높은 수준의 사람이 효율성면에서 적어도 10 배 이상을 이끌 수 있기 때문입니다. 나는 거의 9 년 동안이 업계에 종사해 왔으며 그러한 사례를 너무 많이 보았습니다. 인터넷에 널리 퍼진 사례도 있고 알리바바 내부 팀이 며칠간 조사하지 못한 문제가있다 듀오 롱 경에게 물어 보면 몇 분 안에 완료 될 것이다. .
제 생각에는 많은 사람들의 디버그 능력이 오랫동안 정체 된 두 가지 주된 이유가 있습니다.
하나는 IDE의 기능에 대해 충분히 알지 못하고 내가 사용해온 기본 기능 만 사용한다는 것입니다.
두 번째는 합리적인 디버깅 아이디어를 습득하지 못했고 "운이 좋은"플레이어라는 것입니다.
프로그래밍 언어가 다르고 주류 IDE가 다르기 때문에 주로 두 번째 점에서 내 경험에 대해 이야기합니다.
일부 숙련 된 프로그래머는 디버깅 과정에서 가장 중요한 것은 버그를 수정하는 방법이 아니라 버그가 발생한 위치를 찾는 방법이라는 것을 알고 있습니다. 따라서 아래에서 논의 할 아이디어는 주로 버그 문제 해결과 관련이 있습니다.
/ 01 문제 범위 좁히기 /
문제의 범위를 좁히는 방법은 여러 가지가 있는데, 본질적으로 당시의 환경에서 문제와 더 관련이있는 변수를 찾는 것입니다. 가장 일반적인 변수는 주로 다음과 같습니다.
운영 환경
운영 데이터
브라우저
해당 소스 코드 버전
먼저 이러한 변수에서 확인하는 것이 좋습니다. 그런 다음 마지막 정상 작업과 현재 버그 작업 사이에 무슨 일이 있었는지 알아 내십시오. 대부분의 경우 문제의 근원은 여기에 있습니다. 오랫동안 숨겨져 있던 어려운 문제는 결국 드물다.
/ 02 각 버그 유형에 대한 표준 처리 프로세스를 개선하고 최적화합니다.
작업의 많은 프로세스에는 SOP가 필요하며 버그 수정에도 동일한 작업을 수행 할 수 있으므로 매번 어려운 버그를 수정하는 프로세스가 촉발 될 수 있습니다.
주로 네 가지 일반적인 유형의 버그가 있습니다.
출력이 예상과 일치하지 않음,
프로그램보고 오류,
프로그램의 응답 속도가 분명히 느림,
프로그램 충돌
에는 항상 동일한 루틴을 사용하여 이러한 4 가지 유형의 문제를 해결하는 경우 고유 한 문제 해결 방법이 있습니다. , 효율성은 당연히 열등하고 너무 높을 것입니다.
1. 출력이 예상과 일치하지 않습니다.
이런 종류의 버그가 가장 번거 롭습니다. 왜 그렇습니까? 비정상 및 오류보고 버그와는 다르기 때문에 스택 정보를 가지고있어 조사 범위를 빠르게 좁힐 수 있으며 심지어 생성 위치를 직접 찾을 수도 있습니다.
그래서 뭘 할건데? 테스트 환경에 문제가있는 경우 1 단계 디버깅으로 시작하는 것이 가장 쉽습니다. 이때 IDE의 디버깅 도구를 좀 더 깊이 숙달하면 조건 변수, 멀티 스레드 디버깅 등 효율성이 높아집니다. , 등등.
여기에 한 문장 더 있습니다. 모든 사람이 IDE 조건 변수와 다중 스레드 디버깅의 두 가지 방법을 습득하는 것이 좋습니다. 현재 환경에서 전체 소프트웨어 개발 분야의 대규모 프로젝트와 다중 스레드 응용 프로그램은 몇 년 전에.
디버깅을 단계별로 진행할 수없는 경우 단일 단계 디버깅의 효과를 얻기 위해 더 많은 로그 만 사용할 수 있습니다. 그러나이를 위해서는 몇 가지 예측이 필요합니다. 일부 코드 분기와 의심스러운 위치를 기록하기 만하면됩니다. 결국 로깅을위한 코드를 작성하는 데 시간이 걸립니다.
2. 프로그램이 오류를보고합니다.
이러한 종류의 버그는 예외가 발생한 코드 위치를 직접 알려주기 때문에 숙련 된 프로그래머에게 가장 쉬운 방법입니다.
그러나 초보자에게는 다릅니다. 많은 초보자는 (NullPointer Exception)과 같이 이상을 설명하는 텍스트가 많은 엔진을 검색하고 N 개 이상의 기사를 찾아 하나씩 읽고 해결할 수없는 것을 찾으려고 노력합니다. 그들의 문제., 사실, 나는 스택 정보를 보는 데 익숙하지 않기 때문입니다. 다른 사람의 NullPointer Exception과 NullPointer Exception의 원인이 다르기 때문입니다.
전체 콜 체인이 스택 정보에 기록되므로 여기에서 전체 메서드 호출 시퀀스를 볼 수 있습니다.
그러나 매일 코드를 작성할 때 코드 블록을 마음대로 잡으려고하지 말고 새 예외를 throw하면 스택 정보가 불완전 해 지므로 기억할 가치가 있습니다.
3. 프로그램이 분명히 느리게 반응합니다.
이러한 종류의 문제는 일반적으로 리소스 경쟁이 발생하거나 리소스가 부족할 때 발생합니다. 조사의 어려움도 상대적으로 높습니다.
처음 두 가지 유형의 문제에서 높은 수준과 낮은 수준의 차이가 효율성 수준에 있다면이 문제는 낮은 수준의 프로그래머가 얼마나 많은 시간을 보내든 상관없이 할 수 있다는 것일 수 있습니다. t 문제의 원인을 찾습니다.
그러나 중요하지 않습니다. 앞으로 이러한 상황에 직면하고 다음 지표에 우선 순위를 두는 것이 좋습니다.
TCP 연결 수
메모리 사용량
스레드 수
TCP 연결의 경우 netstat 명령 설명서를 옆에 보관 한 다음 명령을 입력하여 연결 수가 65535에 가까운 지 확인해야합니다. TIME_WAIT 및 CLOSE_WAIT 상태에 너무 많은 연결이 있습니까?
대부분의 경우 TCP 연결과 관련하여 두 가지 주요 문제 가 있습니다.
연결
이 다 사용 된 후 연결 이 제때 해제되지 않는 경우 긴 링크는 고주파 호출에 사용되지 않고 짧은 링크를 사용합니다. 이때 다운 스트림 서비스가 느리게 응답하면 65535 개의 연결이 빠르게 채워집니다.
메모리 문제의 분석은 주로 GC를 분석하여 수행되며 어떤 유형의 객체가 너무 많은 메모리를 차지하는지 여부에 중점을 둡니다. 너무 큰 상황이있는 경우 주된 이유는 다음 두 가지입니다.
큰 개체를 사용하기 위해 공유해야하며 각 인스턴스가 실수로 코드에 작성됩니다.
객체가 할당되었을 때 static 키워드가 실수로 전달되어 GC가 할당 된 메모리를 회수 할 수 없게되었습니다.
프로그래밍 언어마다 숙련도가 필요한 GC 분석 도구가 다릅니다.
TCP 연결과 유사한 스레드 분석은 주로 스레드 수와 상태에 중점을 둡니다. 스레드가 많을수록 성능이 향상되는 것은 아닙니다. 숫자가 클수록 코드 논리의 실제 실행보다 스레드 간의 컨텍스트 전환에 더 많은 시간이 소요됩니다.
또한 많은 수의 스레드가 차단되거나 교착 상태가 되었습니까? 스레드 중 하나를 선택하고 문제인 현재 스택 정보를 분석하기 만하면됩니다.
4. 프로그램 충돌
충돌의 주된 이유는 두 가지입니다.
위에서 언급 한 이유 3이 제때 감지되지 않아 리소스가 고갈 될 때까지 프로그램이 실행되고 운영 체제가 개입하여 강제로 작업을 종료합니다.
코드에 포착되지 않은 예외가 있습니다.
첫 번째 요점은 원인 3의 처리를 참조하십시오.
두 번째 요점은 매우 간단합니다. 코드의 가장 바깥 쪽 레이어에서 큰 시도를 한 다음 스택 정보를 기록하고 온라인에 게시합니다. 자연스럽게 문제가 발생한 위치를 확인하고 원인으로 이동할 수 있습니다. 2 가지 처리 방법 .
마지막으로, 디버그 기능을 향상시키기 위해 더 많은 연습이 필요합니다. 따라서 기능 모듈에 대한 직접적인 책임이 없더라도 상황이 허용되는 경우 온라인 난치병 문제 해결 작업을 용감하게 시작하는 것이 좋습니다.
외부인에게는 당신이 다른 사람들이 "당신의 엉덩이를 닦도록"돕고있는 것처럼 보일 수 있지만, 이것은 당신의 디버그 능력을 크게 향상시킬 것이며 당신에게 의존성을 형성하는 것은 당신을 더 강하고 강하게 만들어줍니다.
요약하자면.
이 기사에서 Brother Z는 디버그 효율성 향상에 대한 저의 견해를 공유했습니다.
디버그의 효율성을 향상시키기 위해 하나는 IDE 도구를 능숙하게 이해하고 몇 가지 높은 수준의 사용 방법을 아는 것입니다. 두 번째는 디버그에 대한 일련의 아이디어를 갖는 것입니다.
두 번째로 제가 제안하는 단계는 다음과 같습니다 :
1. 문제의 범위 축소
2. 각 유형의 버그에 대한 표준 처리 프로세스 개선 및 최적화
버그는 주로 4 가지 범주로 나뉩니다. 다음 4 가지 범주를 구분하십시오.
1. 출력이 예상과 일치하지 않습니다
. 2. 프로그램이 오류를보고합니다.
3. 프로그램이 분명히 응답하는 속도가 느립니다
. 4. 프로그램이 충돌
합니다.
제 생각에 디버그는 프로젝트 프레임 워크를 디자인하는 것만큼이나 매우 재미 있고 만족스러운 것입니다. 또한 디버그를 사용하면 "악마가 세부 사항에 숨어있는 것"을 진정으로 이해할 수 있습니다.