정보가 거의없는 디버깅을위한 팁? [닫은]

나는 상당히 큰 코드베이스로 프로젝트를 물려 받았으며 원래 개발자는 거의 이메일에 답장하지 않습니다. 그것에 몇 가지 일을 할 수있는 다양한 방법이 있으며, 나는 그것들을 모두 모른다. 이 경로를 따라 많은 중복 코드 (예 : 상대적으로 동일한 5 페이지, 5 페이지에 복사 된 코드)에 포함 된 기능 및 데이터베이스의 일부 미묘한 문제 (우리 모두 스파게티 코드에 대해 들어 보았습니다) 그러나 스파게티 데이터베이스에 대해 들어 본 적이 있습니까?)

이 모든 것은 대부분 문제없이 처리 할 수 ​​있습니다.

문제는 클라이언트가 어딘가에서 버그를 발견했을 때입니다. 그들은 보통 종료 문제의 스크린 샷을 보내며 "이걸 좀 볼 수 있을까요?"라고 말합니다. 페이지에서 잘못된 부분을 강조하고 때로는 예상했던 부분을 강조 표시합니다. 더 많은 정보가 제공되며, 그들과 대화하고 더 많은 것을 얻으려고 노력하는 것 (예 : 결과를 얻기 위해 한 것)은이를 당기는 것과 같습니다.

기본적으로 다음과 같이 요약됩니다.

• 100 % 익숙하지 않은 크고 복잡한 코드 기반
• 일이 잘못 될 수있는 많은 방법
• 버그가 어떻게 발생했는지에 대한 정보는 거의 없습니다.

아무도 이런 종류의 디버깅 방법에 대한 팁, 요령, 제안 등이 있습니까?

그런 것을 얻으면 보통 더 많은 정보를 요구합니다. 어떻게 작동하는지 잘 모르겠지만 여기에서 문제를 로컬로 재현하기에 충분한 정보가 없으면 자세한 정보를 요청하여 재현 할 수 없음으로 표시된 티켓을 다시 보낼 수 있습니다. 나는 그것을 끝낼 수있다.

고객이 단계를 설명하는 데 문제가 있으면 스크린 캡 비디오를 요청하십시오. Jing 과 같이 제품을 만들 수있는 몇 가지 무료 제품이 있습니다 . 그들이하고있는 것을 정확하게 볼 수있을 때 훨씬 쉬워집니다.

편집 : 몇 년 전에 이것을 썼을 때 징은 좋은 생각이었습니다. 그 이후로 그들은 요청하지 않은 "보너스"스크랩웨어로 시스템을로드하도록 설치 프로그램을 수정 했으므로 더 이상 권장하지 않습니다. 그래도 주변에는 괜찮은 스크린 레코더가 많이 있습니다.

이 책 이 좋은 출발점이 될 것 입니다 .

개발자가 더 이상 지원하지 않는 것처럼 들리므로 아래 정의를 사용하고 있습니다.

레거시 코드는 더 이상 지원되지 않는 소스 코드입니다.

몇 년 전에 비슷한 문제가 있었고 생산성과 코드 정리가 크게 향상되어 버그 추적을 시스템에 통합했습니다.

우리는 Fogbugz를 사용했습니다 (여전히 Fogcreek를하고 있다고 가정합니다!). 예외가 발생할 때마다 사용자가 버튼을 누르고 즉시 시스템에 로그인 할 수있는 예외 처리 메커니즘을 구축 할 수있었습니다. 더 이상 스크린 샷이 없습니다. 이 옵션을 사용하면 사용자로부터 정보를 추출하지 않고 필요한 정보를 얻을 수 있습니다. 변형과 같은 소리, 특히 스크린 샷 캡처 옵션을 사용하면 좋을 것입니다.

시작하고 싶은 다른 것은 로깅 추가를 시작하는 것입니다. 인수 값을 사용하여 모든 메소드 호출을 로깅하는 것이 좋습니다. 레거시 코드 (테스트가없는 코드)로 작업하는 것처럼 들리므로이 로깅을 사용하면 적절한 단위 테스트를 추가하여 문제를 반복하지 않아도됩니다.

가장 진지한 조언은 가능한 리팩토링을 시작하는 것입니다. 전체 사본이 100 %가 아님을 알기 위해 기능의 재 복사를 본 횟수는 셀 수 없습니다. 사본은 99.9 % 였고 사소한 작은 실수로 버그가 발생했습니다. 모든 것에 단위 테스트를 추가하고 QA 부서가 있다면 작업중인 코드 부분에 대해 자동화 된 테스트 스크립트를 가져 오십시오.

반면, 코드에 얼마나 많은 로깅을 삽입 할 수 있는지 확인하십시오. 즉, 로깅 방법이 많지 않은 경우 코드에 플래그를 추가하여 자체 디버깅 목적으로 더 자세한 로깅을 선택할 수 있습니다. 이것은 대화 상자가 표시되면 사용자가 켜고 끌 수있는 것입니다. 내가 셀 수있는 것보다 더 많은 시간이 도움이되었습니다. 나는 보통 문제의 그림없이 "작동하지 않습니다"라는 메시지를받습니다. 그냥 "로그 파일 보내기"라고 말합니다.

단위 테스트를 작성하여 시작하십시오. 클래스 또는 함수를 선택하고 어떻게 작동해야하는지에 따라 테스트 세트를 작성하십시오. 테스트가 실패하면 이유를 알아 내십시오. 버그 인 경우 수정하십시오. 당신의 기대가 틀린 것으로 판명되면, 실제로 무엇을하는지 파악하고 테스트를 적절히 수정하십시오.

적절한 단위 테스트가 완료되면 코드를 더 깨끗하게 만들기 위해 리팩토링을 수행 할 수있는 안전망이 생깁니다.

코드베이스를 이해할 때까지 반복하십시오.

말할 필요도없이, 이것은 버그 리포트에 대한 응답이 아니라 미리해야 할 일입니다.