소프트웨어 모범 사례에 대한 인용 가능한 참조

현재 박사 학위 논문을 쓰고 있습니다. 나는 이전에 사용되지 않은 소프트웨어 엔지니어링 모범 사례를 적용하면서 기존 과학 코드를 정리하고 확장하는 박사 학위의 상당 부분을 논문에 쓰려고했습니다. 단순히 "단위 테스트를 추가했습니다"라고 말하지 않고 다음과 같이 작성할 수 있기를 원합니다.

J. Doe는 1975 년에 단위 테스트를 발명했다 [ 23 ] . Bloggs에 의한 최근의 연구 등 [ 24 ] 단위 테스트 73 %의 소프트웨어 오류의 발생을 줄이는 것이 ... (234 개) 별도의 단위 테스트 Timpkins 의해 생성 xUnit의 프레임 워크에 의해 관리되는 코드베이스에 첨가했다 등 [ 25 ]$^{[23]}$$^{[24]}$$^{[25]}$

널리 인정되는 소프트웨어 엔지니어링 모범 사례, 특히 다음과 같은 인용 가능한 학술 참고 문헌 (바람직하게 DOI, BibTeX 등을 얻을 수있는 동료 검토 저널의 기사)을 찾고 있습니다.

• 단위 테스트
• 버전 관리
• 모듈화 / 문제 분리
• 프로파일 링 정보를 기반으로 한 성능 프로파일 링 / 최적화
• 버그 / 문제 추적

나는 초기 발명과 그 이후의 효과 평가에 관한 정보를 찾고 있습니다. 이 모든 것을 한곳에 나열하는 리뷰 기사가 있다면 훨씬 좋습니다.

Steve McConnell의 저서 인 Code Complete, 2nd edition 에는 전산 과학자보다 소프트웨어 개발자의 관점에서 이러한 문제를 다루는 광범위한 참고 문헌이 있습니다. 이 책은 10 년 전에 다가오고 있다는 점에서 조금 더 오래된 책이되기 시작하여 행동 중심 개발과 같은 최신 테스트 방법론을 다루지 않습니다. 그럼에도 불구하고, 내가 알고있는 소프트웨어 구성에 대한 포괄적 인 검토 기사와 가장 가까운 것이 바로 그것입니다. IEEE 소프트웨어에서 기사를 찾을 수도 있습니다.

계산 과학 측면에서 가장 좋은 기사는 아마도 "과학 컴퓨팅을위한 모범 사례"에서 인용 한 arXiv 프리 프린트 DavidKetcheson 의 PLoS 버전 일 것입니다 . 소수의 사람들이 arXiv 참고 문헌을 인용하거나 arXiv 프리 프린트를 게시하여 "실제 저널 기사"를 인용하는 공학적 배경에서 비롯된 것입니다. )를 더 호의적으로 바라 봅니다 (저는 저자가 저널에 게시하기로 선택한 이유를 알게되었습니다).

DavidKetcheson과 제가 인용 한 PLoS 논문의 저자는 Software Carpentry 라는 조직의 일원으로, 과학자들에게 소프트웨어 개발을위한 모범 사례와 과학자들을위한 유용한 계산 기술에 대해 (일반적으로 2 일) "부트 캠프"를 실시합니다. 전산 과학자). Software Carpentry 웹 사이트에는 과학의 소프트웨어 개발과 관련된 광범위한 참고 문헌이 있습니다. 이 문제에 관심이 있으시면 문의 해주십시오. 그들은 항상 다양한 역량으로 자원 봉사를하기 위해 소프트웨어 개발의 모범 사례를 더 많이지지하고 있습니다. ( 면책 조항 : 저는 소프트웨어 목공에 자원합니다.)

소프트웨어 개발 모범 사례에 참여하기위한 또 다른 정당성은 재현성입니다. Victoria Stodden은 여러분이하고 싶은 말에 따라 관심을 가질만한 재현 가능한 연구 참조 목록을 길게 정리했습니다 .

나는 이러한 각 아이디어 / 연습의 기원에 대한 언급이 없습니다. 그러나 가장 최근에 관련된 참고 자료는 다음과 같습니다.

• 계산 오픈 소스 소프트웨어 라이브러리의 성공 이유는 무엇입니까?
• 과학 컴퓨팅을위한 모범 사례

IMHO 나는 과학적으로 입증 된 접근법의 맥락에서 "모범 사례"를 인용하여 세심한주의를 기울일 것입니다. 대부분의 관행은 서로 다른 접근 방식에 대한 엄격한 테스트에서 도출 된 것이 아니라 "그 프로젝트에 관여하는 전문가로 인식 된 누군가에 의해 일련의 프로젝트에서 작동하는 것"에서 비롯됩니다. 소프트웨어 엔지니어링에는 참조 할 수있는 "모범 사례"목록이 있다고 언급하기에는 너무 많은 변수와 인적 요소가 있습니다 (예 : 한 프로젝트에서 작동하는 사례는 다른 프로젝트에서는 완전히 실패합니다).

프로젝트에 필요한 것이 무엇인지, 왜 필요한지, 사용 된 메소드에 대한 참조를 추가하고, 왜 사용했는지 설명하여 접근합니다.

또한 귀하의 요점을 언급하기위한 참조가 아닌 수량화 가능한 결과를보고하는 데 주력합니다. 예를 들어, 장치에서 발견 된 100 개의 버그를 테스트 한 경우 그 중 10 개는 이전에 게시 된 결과를 의심 할 정도로 심각합니다. 이것은 당신이 단위 테스트의 기원을 알고 있다는 진술보다 박사 학위에 가지고있는 훨씬 더 강력한 진술입니다.

편집 : (고정 된 오타)-다음에 대한 답변-나는 종종 어린이들을 소프트웨어 프로젝트와 유사하게 키 웁니다. 평균 또는 테스트 하위 샘플에 대해 작동하기 때문에 한 가지 방법으로 자녀를 양육하려고 시도하는 방법과 테스트 방법이 많이 있습니다. 자녀가 테스트 한 것과 동일한 한 효과가 있습니다. 많은 방법을 알고 인스턴스에서 작동하는 방법을 적용하는 것이 좋습니다. 그렇습니다. 단위 테스트는 입증 될 수 있지만,이를 기반으로 적용하면 프로젝트가 늦게 출시되어 목표에 도달하지 못할 수 있습니다 (목표 일 경우). 필자는 논문의 주제가 방법론을 측정하지 않는 한 다른 프로젝트를 기반으로 시도한 것을 나열하는 것보다 논문에서 결과를 얻는 방법을 적용하고 그 결과를 제공하는 것이 논문에서 더 낫다고 말합니다. :)