특정 기능을 구현 한 소스 코드를 찾는 방법은 무엇입니까? [닫은]

데스크톱 응용 프로그램에서 특정 기능을 구현 한 코드를 찾는 몇 가지 기술이 궁금합니다.

나는 웹 프로그래밍과 관련된 전문적인 프로그래밍 경험 만 가진 주니어 개발자입니다. 웹에서는 그렇게하는 것이 더 쉽습니다. 예를 들어, 브라우저 도구를 사용하여 단추를 "검사"하면 단추를 클릭했을 때 수행되는 작업을 확인할 수 있습니다. 그런 다음 전체 소스 코드가 있다고 가정하면 호출 계층을 드릴 다운 할 수 있습니다.

그러나 데스크톱 응용 프로그램에서 어떻게합니까? 적어도 전체 코드베이스에 들어 가지 않고도?

역 추적

역 추적은 기능과 연관된 이벤트에 엔드 포인트 를 찾는 중입니다 (아래 참조). 일단 중단되면 디버거에 중단 점이 배치됩니다. 기능이 트리거되고 디버거가 중지 될 때 호출 경로를 다시 추적하기 위해 호출 스택을 검토합니다. 콜 스택을 걷는 동안 변수 상태에 대한 메모를하거나 새로운 중단 점을 배치하여 이벤트를 다시 검사 할 수 있습니다.

기능이 다시 트리거되고 디버거가 새 중단 점에서 중지됩니다. 그런 다음 목표를 찾을 때까지 역 추적 을 반복 하거나 정방향 추적을 수행 할 수 있습니다 .

찬반 양론

• 통화 스택을 걸어 가고 어딘가에 어떻게 왔는지 확인하는 것이 항상 더 쉽습니다.
• 엔드 포인트에 도달하기 전에 수백만 개의 조건이 충족되어야합니다. 끝점을 이미 알고 있다면 많은 작업을 저장했습니다.
• 기능이 손상된 경우 엔드 포인트에 도달하지 못할 수 있으며 이유를 파악하는 데 시간이 낭비 될 수 있습니다.

엔드 포인트 발견

기능을 디버그하려면 소스 코드에서 최종 목표가 달성되는 위치를 알아야합니다. 이 시점에서만 코드가 어떻게 도착했는지 역 추적 할 수 있습니다 . 예를 들면; 실행 취소 방법을 이해합니다. 코드에서 어떤 부분이 취소되었는지는 알지만 상황이 어떻게 진행되는지는 모릅니다 . 이 기능의 작동 방식을 파악하기 위해 백 트레이싱 후보가 될 수 있습니다 .

순방향 추적

정방향 추적은 기능과 관련된 이벤트의 시작점 을 찾습니다 (아래 참조). 일단 로깅 메시지가 소스 코드에 삽입되거나 중단 점이 설정됩니다. 이 프로세스는 기능 의 목표 를 발견 할 때까지 시작점 에서 멀어 질수록 반복됩니다 .

찬반 양론

• 기능을 찾는 가장 쉬운 시작점입니다.
• 코드 복잡성은 순방향 추적의 효율성을 감소시킵니다. 코드에 조건이 많을수록 잘못된 방향으로 갈 확률이 높아집니다.
• 순방향 추적은 종종 관련없는 이벤트에 의해 트리거되는 중단 점을 설정합니다. 디버깅 프로세스를 방해하고 검색을 방해합니다.

시작점 발견

키워드, 사용자 인터페이스 식별자 (버튼 ID, 창 이름)를 사용하거나 기능과 관련된 이벤트 리스너를 쉽게 찾을 수 있습니다. 예를 들어 실행 취소 기능 을 트리거하는 데 사용되는 버튼으로 시작할 수 있습니다 .

제거 과정

이를 시작점 및 끝점 위치 와 비교 한 중간 점 으로 생각할 수 있습니다 . 기능에 사용 된 코드 조각을 이미 알고 있지만 기능의 시작 또는 끝이 아닌 경우 제거 프로세스를 수행 합니다.

중간 지점 에서 가져 오는 방향 은 출입 횟수에 따라 다릅니다. 코드 청크가 여러 곳에서 사용 되는 경우이 위치에서 역 추적 을 수행하면 모두 검사해야하므로 시간이 많이 걸릴 수 있습니다. 그런 다음 제거 프로세스를 사용하여이 목록을 줄입니다. 또는 이 시점부터 순방향 추적 을 수행 할 수 있지만 코드 청크가 여러 위치로 분기되는 경우에도 문제가 될 수 있습니다.

지형지 물에 대해 명확하게 실행되지 않는 경로를 따르지 않으면 서 위치 방향을 줄여야합니다. 이 코드를 지나서 기능과 관련이있는 곳에만 중단 점을 배치하십시오.

중간 점 디버깅에는 더 많은 고급 IDE 기능이 필요합니다. 코드 계층 및 종속성을 볼 수있는 기능 이러한 도구가 없으면 어렵습니다.

찬반 양론

• 중간 점 은 종종 기능을 생각할 때 머리에 튀어 나오는 첫 번째 코드 조각입니다. "아, 그건 작동하려면 XXXX를 사용해야합니다."
• 중간 지점 은 시작 지점 을 가장 쉽게 표시 할 수 있습니다 .
• 중간 점 은 동기화 또는 스레딩 변경으로 인해 손실 될 때 형상을 추적하는 쉬운 방법이 될 수 있습니다.
• 중간 점 은 익숙하지 않은 코드로 안내 할 수 있습니다. 무슨 일이 일어나고 있는지 배우는 데 시간이 걸립니다.

이 기능이 버튼이나 메뉴와 같은 UI와 관련이 있다고 가정하면 내가하는 경향은 다음과 같습니다 (매우 지루하지만 작동합니다). 이것은 디버거를 사용하지 않고 소스 코드를 살펴보고 있습니다.

1. "Super Feature X3"과 같이 버튼에서 텍스트를 검색하십시오.
2. 그것은 아마도 상수가있는 파일에있을 것입니다 (예 :) SUPER_BUTTON_3 = "Super Feature X3". 나중에 참조 할 수 있도록이 파일 이름을 기억하십시오.
3. 추상화의 또 다른 계층이있을 수 있습니다. 버튼에서 사용되는 "실제"문자열을 찾기 위해 계속 검색하십시오. 이것이 미래에 어떻게 수행되는지 주목하십시오.
4. 이제 그 상수를 검색하십시오. 바라건대 이제 버튼을 찾았습니다. 어쩌면 그것이 ActionListener를 연결하는 곳 일 것입니다. (YMMV에서 Java를 사용하고 있지만 개념은 여전히 ​​유효합니다)
5. 필요한 경우 해당 버튼을 검색하면 결국 리스너에 연결된 위치를 찾을 수 있습니다.
6. 아마도 리스너는 상수에 따라 다른 리스너 ( "실제"기능)로 실제로 리디렉션됩니다. 그렇다면 if / else 또는 case 문을 따르십시오. 참고 : 중앙 발송이 필요한 경우 중단 점을 설정하기에 좋은 곳 입니다.
7. 마지막으로 실제 코드에 있어야합니다.

@ amon이 지적했듯이 때로는 디버거가 더 간단합니다 ...

• 관련 코드를 전혀 찾을 수 없으면 소스 제어 소프트웨어를 사용하여 전체 커밋 또는 추가 한 근처 커밋을 표시 할 수 있습니다. 해당 기능을 구현하는 데 필요한 모든 것이 표시됩니다.

• 살펴볼 출발점을 찾는 쉬운 방법 중 하나는 코드베이스를 통해 버튼의 텍스트를 찾는 것입니다.

• 종종 사람들은 커밋 메시지에 이슈 트래커의 이슈 ID를 넣습니다. 기능 요청을 설명하는 문제를 찾을 수 있으면 해당 문제 ID로 커밋을 검색 할 수 있습니다.