데스크톱 응용 프로그램에서 특정 기능을 구현 한 코드를 찾는 몇 가지 기술이 궁금합니다.
나는 웹 프로그래밍과 관련된 전문적인 프로그래밍 경험 만 가진 주니어 개발자입니다. 웹에서는 그렇게하는 것이 더 쉽습니다. 예를 들어, 브라우저 도구를 사용하여 단추를 “검사”하면 단추를 클릭했을 때 수행되는 작업을 확인할 수 있습니다. 그런 다음 전체 소스 코드가 있다고 가정하면 호출 계층을 드릴 다운 할 수 있습니다.
그러나 데스크톱 응용 프로그램에서 어떻게합니까? 적어도 전체 코드베이스에 들어 가지 않고도?
답변
역 추적
역 추적은 기능과 연관된 이벤트에 엔드 포인트 를 찾는 중입니다 (아래 참조). 일단 중단되면 디버거에 중단 점이 배치됩니다. 기능이 트리거되고 디버거가 중지 될 때 호출 경로를 다시 추적하기 위해 호출 스택을 검토합니다. 콜 스택을 걷는 동안 변수 상태에 대한 메모를하거나 새로운 중단 점을 배치하여 이벤트를 다시 검사 할 수 있습니다.
기능이 다시 트리거되고 디버거가 새 중단 점에서 중지됩니다. 그런 다음 목표를 찾을 때까지 역 추적 을 반복 하거나 정방향 추적을 수행 할 수 있습니다 .
찬반 양론
- 통화 스택을 걸어 가고 어딘가에 어떻게 왔는지 확인하는 것이 항상 더 쉽습니다.
- 엔드 포인트에 도달하기 전에 수백만 개의 조건이 충족되어야합니다. 끝점을 이미 알고 있다면 많은 작업을 저장했습니다.
- 기능이 손상된 경우 엔드 포인트에 도달하지 못할 수 있으며 이유를 파악하는 데 시간이 낭비 될 수 있습니다.
엔드 포인트 발견
기능을 디버그하려면 소스 코드에서 최종 목표가 달성되는 위치를 알아야합니다. 이 시점에서만 코드가 어떻게 도착했는지 역 추적 할 수 있습니다 . 예를 들면; 실행 취소 방법을 이해합니다. 코드에서 어떤 부분이 취소되었는지는 알지만 상황이 어떻게 진행되는지는 모릅니다 . 이 기능의 작동 방식을 파악하기 위해 백 트레이싱 후보가 될 수 있습니다 .
순방향 추적
정방향 추적은 기능과 관련된 이벤트의 시작점 을 찾습니다 (아래 참조). 일단 로깅 메시지가 소스 코드에 삽입되거나 중단 점이 설정됩니다. 이 프로세스는 기능 의 목표 를 발견 할 때까지 시작점 에서 멀어 질수록 반복됩니다 .
찬반 양론
- 기능을 찾는 가장 쉬운 시작점입니다.
- 코드 복잡성은 순방향 추적의 효율성을 감소시킵니다. 코드에 조건이 많을수록 잘못된 방향으로 갈 확률이 높아집니다.
- 순방향 추적은 종종 관련없는 이벤트에 의해 트리거되는 중단 점을 설정합니다. 디버깅 프로세스를 방해하고 검색을 방해합니다.
시작점 발견
키워드, 사용자 인터페이스 식별자 (버튼 ID, 창 이름)를 사용하거나 기능과 관련된 이벤트 리스너를 쉽게 찾을 수 있습니다. 예를 들어 실행 취소 기능 을 트리거하는 데 사용되는 버튼으로 시작할 수 있습니다 .
제거 과정
이를 시작점 및 끝점 위치 와 비교 한 중간 점 으로 생각할 수 있습니다 . 기능에 사용 된 코드 조각을 이미 알고 있지만 기능의 시작 또는 끝이 아닌 경우 제거 프로세스를 수행 합니다.
중간 지점 에서 가져 오는 방향 은 출입 횟수에 따라 다릅니다. 코드 청크가 여러 곳에서 사용 되는 경우이 위치에서 역 추적 을 수행하면 모두 검사해야하므로 시간이 많이 걸릴 수 있습니다. 그런 다음 제거 프로세스를 사용하여이 목록을 줄입니다. 또는 이 시점부터 순방향 추적 을 수행 할 수 있지만 코드 청크가 여러 위치로 분기되는 경우에도 문제가 될 수 있습니다.
지형지 물에 대해 명확하게 실행되지 않는 경로를 따르지 않으면 서 위치 방향을 줄여야합니다. 이 코드를 지나서 기능과 관련이있는 곳에만 중단 점을 배치하십시오.
중간 점 디버깅에는 더 많은 고급 IDE 기능이 필요합니다. 코드 계층 및 종속성을 볼 수있는 기능 이러한 도구가 없으면 어렵습니다.
찬반 양론
- 중간 점 은 종종 기능을 생각할 때 머리에 튀어 나오는 첫 번째 코드 조각입니다. “아, 그건 작동하려면 XXXX를 사용해야합니다.”
- 중간 지점 은 시작 지점 을 가장 쉽게 표시 할 수 있습니다 .
- 중간 점 은 동기화 또는 스레딩 변경으로 인해 손실 될 때 형상을 추적하는 쉬운 방법이 될 수 있습니다.
- 중간 점 은 익숙하지 않은 코드로 안내 할 수 있습니다. 무슨 일이 일어나고 있는지 배우는 데 시간이 걸립니다.
답변
이 기능이 버튼이나 메뉴와 같은 UI와 관련이 있다고 가정하면 내가하는 경향은 다음과 같습니다 (매우 지루하지만 작동합니다). 이것은 디버거를 사용하지 않고 소스 코드를 살펴보고 있습니다.
- “Super Feature X3″과 같이 버튼에서 텍스트를 검색하십시오.
- 그것은 아마도 상수가있는 파일에있을 것입니다 (예 🙂
SUPER_BUTTON_3 = "Super Feature X3"
. 나중에 참조 할 수 있도록이 파일 이름을 기억하십시오. - 추상화의 또 다른 계층이있을 수 있습니다. 버튼에서 사용되는 “실제”문자열을 찾기 위해 계속 검색하십시오. 이것이 미래에 어떻게 수행되는지 주목하십시오.
- 이제 그 상수를 검색하십시오. 바라건대 이제 버튼을 찾았습니다. 어쩌면 그것이 ActionListener를 연결하는 곳 일 것입니다. (YMMV에서 Java를 사용하고 있지만 개념은 여전히 유효합니다)
- 필요한 경우 해당 버튼을 검색하면 결국 리스너에 연결된 위치를 찾을 수 있습니다.
- 아마도 리스너는 상수에 따라 다른 리스너 ( “실제”기능)로 실제로 리디렉션됩니다. 그렇다면 if / else 또는 case 문을 따르십시오. 참고 : 중앙 발송이 필요한 경우 중단 점을 설정하기에 좋은 곳 입니다.
- 마지막으로 실제 코드에 있어야합니다.
@ amon이 지적했듯이 때로는 디버거가 더 간단합니다 …
답변
-
관련 코드를 전혀 찾을 수 없으면 소스 제어 소프트웨어를 사용하여 전체 커밋 또는 추가 한 근처 커밋을 표시 할 수 있습니다. 해당 기능을 구현하는 데 필요한 모든 것이 표시됩니다.
-
살펴볼 출발점을 찾는 쉬운 방법 중 하나는 코드베이스를 통해 버튼의 텍스트를 찾는 것입니다.
-
종종 사람들은 커밋 메시지에 이슈 트래커의 이슈 ID를 넣습니다. 기능 요청을 설명하는 문제를 찾을 수 있으면 해당 문제 ID로 커밋을 검색 할 수 있습니다.