4
저는 물리 모델을 개발하는 팀의 유일한 소프트웨어 엔지니어입니다 (약 3 만 줄의 코드). 나머지 팀은 약 20 년 동안 코드베이스를 개발해온 과학자들로 구성됩니다. 내 워크 플로우 이런 식입니다 :레거시 피직스 모델에 대한 버그 추적
- 과학자 내가 테스트 & 검증을 통해, 나는 깊은 수치
- 과학자 내 어딘가에 심각한 문제를 찾을 수 새로운 기능 요청을 구현하는 새로운 기능
- 를 요청 (# 3에서 확인 된 문제를 수정하지 않고)
버그 추적은 전자 메일과 포스트잇 노트를 통해 수행되는 것 같습니다. 바쁜 업무 일정으로 인해 수개월이나 수개월 동안 버그가 레이더 아래로 미끄러질 수 있습니다. 일부 형식화 된 버그 추적기 (예 : Trac, Redmine, Jira, FogBugz 등)가 도움이 될 것으로 생각합니다. 다음 기능은 필수적입니다 :
- (우리는 Subversion을 사용하여)
이 which bugtracker is "best" 건의 게시물이 많이 있습니다 ...하지만이 있다고 가정
- : 나는 더 관심
- 당신은 버그 추적자가 여분의 유익한 가치가있는 물리학 자 (누가 70 년대의 빈약 한 소프트웨어 엔지니어링 "베스트 프랙티스"를 따르는가)를 납득시킬 수 있습니까?
- 버그 추적기를 설치하면 나는 유일한 사용자가 될 것이라고 생각합니다. 다른 사람이 이것을 경험 했습니까? 여전히 유용한가요? 추가 오버 헤드의 가치가있는 버그 추적기를 만들기 위해 팀이 일정량의 "바이 인 (buy-in)"을 필요로하는 것처럼 보입니다.
좋은 링크! 나는 특히 "다른 사람이 정말로 고쳐야하는 버그를 발견하면 버그 데이터베이스를 사용하여 버그를 할당하십시오. 좋은 버그 추적 소프트웨어가 있다면 전자 메일을 보낼 것입니다." "QA 팀이 버그 추적 시스템에 버그를 입력하는 것을 거부하면 다른 채널을 통해 버그 보고서를 듣기를 거부합니다. 사람들에게 말한 3 천 번째 시간에 대해" 그것을 고치는 것을 좋아하지만 잊어 버릴 것입니다. 시스템에 버그를 입력 할 수 있습니까? "그들은 데이터베이스를 사용하기 시작할 것입니다." – Pete