최고의 디버깅 조언에 대한 잠깐의 토론

Question

최근에 저는 소프트웨어의 주요 부분을 물려 받았습니다. 원래 모델의 소프트웨어는 여러 세대에 걸친 프로그래머들의 노력으로 사라졌습니다 ("원래 모델"조차도 크게 손상된 것처럼 보입니다). 코드에는 단위 테스트가 없습니다. 다행스럽게도 이전 버전과 호환 될 필요가 없습니다 (아, 지옥보다 나빠질 것입니다!). 나는 코드를 리팩토링하는 선택적 강제적이고 선택적 제한적 접근 방식을 취하고있다. 과거에는 많은 것을 동시에 변경하려고 시도하면서 자주 손을 태웠지만 여전히 그렇게하는 경향이 있다고 생각합니다.

한동안, 나는 장시간 붙어 버린 버그도 해결했습니다. 그 경험을 통해 나는 새로운 것을 시도하는 것보다 누락 된 "올바른 가설"을 찾는 시간을 보내는 것이 중요하다는 것을 이해했습니다.

나는 내 다음 목표가 가능한 한 빨리 테스트를 만들어야한다는 것을 알고 있지만, 현재 어떻게해야하는지에 대해서는 부끄럽다. 나는 "Working Effectively with Legacy Code"이라는 책에서 다루는 리팩토링의 원칙을 사용하고 싶지만 인내와 시간 (또는 규율)이 부족하여 책을 따라갈 수 없습니다.

경험에 근거한 디버깅 요령을 제공하려면 다음을 수행하십시오.

Answer 1

제 경험상 최종 사용자 지원을받는 것이 중요합니다.

나는 Clipper Summer '87 응용 프로그램을 유지 관리하고 Y2K와 호환되도록 만들었을 때 비슷한 경험을했습니다. 악몽으로 시작 : 나는 한 곳에서 몇몇 버그를 수정하기 시작했고 다른 부분은 작동을 멈췄다. 시간을 보냈을 때 몇 명의 주요 사용자와 회의를 예약하고 해당 응용 프로그램을 다시 작성하라고 제안했습니다.

필자는 가장 중요한 기능을 처음으로 다시 작성하고 매일 사용자와 매우 긴밀한 대화를 나눴다. 매주 몇 가지 샘플 데이터를 마이그레이션 할 것이므로 애플리케이션이 어떻게 실행되고 있는지 느낄 수 있습니다. 약 3 주 만에 첫 번째 버전이 실행되었고 작은 기능 세트가 마이그레이션되었습니다.

처리되는 데 45 분이 걸리는 특정 보고서가 있었으며 최신 버전에서는 단 5 초만 소요되었습니다. 따라서 사용자는 오래된 코드를 버리고 새로운 버전을 시작하는 데 더 많은 시간과 돈을 소비하는 것이 좋은 선택이라는 것을 알았습니다.

애플리케이션을 다시 작성할 수있을 때마다 알리는 것이 아닙니다. 그러나 고객에게 중요한 것이 무엇인지 이해하고 일부 주요 변경 사항이 해당 프로젝트 성공을 결정 짓는다는 것을 이해하게 만들 수 있습니다.