การอ้างอิงที่น่าเชื่อถือสำหรับแนวทางปฏิบัติที่ดีที่สุดของซอฟต์แวร์

ฉันกำลังเขียนวิทยานิพนธ์ปริญญาเอกของฉัน ฉันใช้เวลาส่วนหนึ่งของปริญญาเอกในการทำความสะอาดและขยายรหัสทางวิทยาศาสตร์ที่มีอยู่การใช้แนวปฏิบัติที่ดีที่สุดด้านวิศวกรรมซอฟต์แวร์ซึ่งก่อนหน้านี้ไม่ได้ใช้และต้องการที่จะเขียนเกี่ยวกับสิ่งนี้ในวิทยานิพนธ์ของฉัน แทนที่จะพูดว่า "ฉันเพิ่มการทดสอบหน่วย" ฉันต้องการที่จะสามารถเขียนสิ่งนี้:

เจ Doe คิดค้นทดสอบหน่วยในปี 1975 [ 23 ] การศึกษาล่าสุดโดย Bloggs et al [ 24 ]แสดงให้เห็นว่าการทดสอบหน่วยลดการเกิดข้อผิดพลาดของซอฟต์แวร์ 73% ... 234 การทดสอบแยกหน่วยถูกเพิ่มเข้าไปในฐานรหัสจัดการโดยกรอบ xUnit ที่สร้างโดย Timpkins et al$^{[23]}$$^{[24]}$$^{[25]}$

ฉันกำลังมองหาข้อมูลอ้างอิงทางวิชาการที่อ้างอิงได้ (บทความที่น่าสนใจในวารสารที่มีการตรวจสอบแบบ peer-reviewed ซึ่งฉันสามารถรับ DOIs, BibTeX และอื่น ๆ ) ไปยังแนวปฏิบัติที่ดีที่สุดสำหรับวิศวกรรมซอฟต์แวร์ที่ได้รับการยอมรับโดยเฉพาะ:

• การทดสอบหน่วย
• การควบคุมเวอร์ชัน
• การแยกส่วน / แยกความกังวล
• การทำโปรไฟล์ประสิทธิภาพ / การปรับให้เหมาะสมขึ้นอยู่กับข้อมูลการทำโปรไฟล์
• การติดตามข้อบกพร่อง / ปัญหา

ฉันกำลังมองหาข้อมูลเกี่ยวกับการประดิษฐ์เริ่มต้นและการประเมินประสิทธิผลที่ตามมา หากมีบทความรีวิวที่แสดงรายการทั้งหมดนี้ในที่เดียวก็ยิ่งดี

Code Completeของ Steve McConnell หนังสือฉบับที่ 2มีบรรณานุกรมกว้างขวางที่พูดถึงปัญหาเหล่านี้จากมุมมองของนักพัฒนาซอฟต์แวร์มากกว่านักวิทยาศาสตร์ด้านการคำนวณ หนังสือเล่มนี้เริ่มจะล้าสมัยไปแล้วซึ่งใกล้จะถึงทศวรรษแล้วดังนั้นจึงไม่ครอบคลุมวิธีการทดสอบล่าสุดเช่นการพัฒนาที่เน้นพฤติกรรม อย่างไรก็ตามมันเป็นสิ่งที่ใกล้เคียงที่สุดกับบทความทบทวนที่ครอบคลุมเกี่ยวกับการสร้างซอฟต์แวร์ที่ฉันรู้ คุณสามารถหาบทความในซอฟต์แวร์ IEEE

ในด้านวิทยาศาสตร์การคำนวณของสิ่งต่าง ๆ ฉันคิดว่าบทความที่ดีที่สุดน่าจะเป็นเวอร์ชัน PLX ของ arXiv preprint DavidKetcheson อ้างถึง "วิธีปฏิบัติที่ดีที่สุดสำหรับการคำนวณทางวิทยาศาสตร์" ฉันบอกว่าสิ่งนี้มาจากภูมิหลังทางวิศวกรรมที่ผู้คนจำนวนน้อยอ้างถึงการอ้างอิงของ arXiv หรือโพสต์ก่อนพิมพ์ arXiv และด้วยเหตุนี้จึงอ้างถึง "บทความวารสารจริง" (แน่นอนปัญหาทั้งหมดเกี่ยวกับการตีพิมพ์ทางวิทยาศาสตร์ที่กำลังถกเถียงกันอยู่ตอนนี้ ) ถูกมองว่าเป็นประโยชน์มากกว่า (และฉันได้รับความประทับใจนั่นคือสาเหตุที่ผู้เขียนเลือกที่จะเผยแพร่ในวารสาร)

ผู้เขียนกระดาษของ PLoS ที่ DavidKetcheson และฉันอ้างถึงเป็นส่วนหนึ่งขององค์กรที่เรียกว่าSoftware Carpentryซึ่งจัดทำ "boot camps" (ปกติ 2 วัน) เพื่อสอนนักวิทยาศาสตร์เกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดสำหรับการพัฒนาซอฟต์แวร์และทักษะการคำนวณที่มีประโยชน์สำหรับนักวิทยาศาสตร์ นักวิทยาศาสตร์คอมพิวเตอร์) เว็บไซต์ Software Carpentry มีบรรณานุกรมกว้างขวางเกี่ยวกับการพัฒนาซอฟต์แวร์ด้านวิทยาศาสตร์ หากคุณสนใจปัญหาเหล่านี้ฉันขอแนะนำให้คุณติดต่อกับพวกเขา พวกเขามักจะมองหาผู้สนับสนุนแนวทางปฏิบัติที่ดีที่สุดในการพัฒนาซอฟต์แวร์เพื่อเป็นอาสาสมัครในความสามารถที่หลากหลาย ( ข้อจำกัดความรับผิดชอบ : ฉันเป็นอาสาสมัครกับ Software Carpentry)

เหตุผลทั่วไปอีกประการหนึ่งสำหรับการมีส่วนร่วมในแนวทางปฏิบัติที่ดีที่สุดในการพัฒนาซอฟต์แวร์คือการทำซ้ำ Victoria Stodden ได้รวบรวมรายการอ้างอิงงานวิจัยที่ทำซ้ำได้จำนวนมากซึ่งอาจเป็นที่สนใจทั้งนี้ขึ้นอยู่กับสิ่งที่คุณต้องการจะพูด

ฉันไม่มีการอ้างอิงถึงที่มาของความคิด / การปฏิบัติเหล่านี้ แต่นี่เป็นข้อมูลอ้างอิงที่เกี่ยวข้องล่าสุด:

• อะไรทำให้ห้องสมุดซอฟต์แวร์โอเพ่นซอร์สคอมพิวเตอร์ประสบความสำเร็จ
• วิธีปฏิบัติที่ดีที่สุดสำหรับการคำนวณทางวิทยาศาสตร์

IMHO ฉันจะใช้ความระมัดระวังอย่างยิ่งในการอ้างถึง "แนวปฏิบัติที่ดีที่สุด" ในบริบทของวิธีการที่ได้รับการพิสูจน์ทางวิทยาศาสตร์ การปฏิบัติส่วนใหญ่มาจาก "สิ่งที่ดูเหมือนว่าจะทำงานให้กับชุดของโครงการโดยมีคนเห็นว่าเป็นปราชญ์ที่เกี่ยวข้องในโครงการเหล่านั้น" แทนที่จะได้มาจากการทดสอบอย่างเข้มงวดของวิธีการต่าง ๆ มีตัวแปรมากเกินไปและปัจจัยมนุษย์ในวิศวกรรมซอฟต์แวร์ที่ระบุว่ามีรายการ "แนวทางปฏิบัติที่ดีที่สุด" ที่อ้างอิงได้ (เช่นการปฏิบัติที่ทำงานในโครงการหนึ่งจะล้มเหลวโดยสิ้นเชิง)

ฉันจะเข้าใกล้มันโดยระบุว่าโครงการของคุณต้องการอะไรทำไมมันถึงต้องการมันและเพิ่มการอ้างอิงถึงวิธีการที่ใช้และทำไมคุณถึงใช้มัน

ฉันจะพึ่งพาการรายงานผลลัพธ์เชิงปริมาณมากกว่าการอ้างอิงเพื่อระบุจุดของคุณ ตัวอย่างเช่นหากหน่วยของคุณทำการทดสอบพบข้อบกพร่อง 100 ข้อ 10 ข้อนั้นร้ายแรงพอที่จะสงสัยในผลลัพธ์ที่เผยแพร่ก่อนหน้านี้ นี่เป็นคำแถลงที่ทรงพลังยิ่งกว่าที่จะมีในปริญญาเอกของคุณมากกว่าข้อความที่คุณทราบถึงที่มาของการทดสอบหน่วย

แก้ไข: (พิมพ์ผิดที่คงที่) - ตอบคำถามต่อไปนี้ - ฉันมักจะให้เด็กเลี้ยงเป็นการเปรียบเทียบกับโครงการซอฟต์แวร์ มีหลายวิธีและวิธีทดสอบเพื่อยกระดับพวกเขาพยายามเลี้ยงดูลูกของคุณด้วยวิธีหนึ่งเพราะมันใช้งานได้กับค่าเฉลี่ยหรือตัวอย่างย่อยที่ทดสอบแล้วจะทำงานได้ตราบใดที่ลูกของคุณเหมือนกับที่ทดสอบ มันจะดีกว่าที่จะรู้วิธีการมากมาย ใช่การทดสอบหน่วยอาจได้รับการพิสูจน์ แต่การนำไปใช้โดยอาศัยเพียงอย่างเดียวอาจหมายถึงโครงการของคุณออกสู่ตลาดช้าและไม่สำเร็จตามวัตถุประสงค์ (ถ้าเป็นวัตถุประสงค์) ฉันกำลังบอกว่าการใช้วิธีการเพื่อให้ได้ผลลัพธ์และให้ผลลัพธ์ของผลลัพธ์นั้นในความคิดของฉันดีกว่าในวิทยานิพนธ์มากกว่าการแสดงรายการสิ่งที่คุณพยายามทำตามโครงการอื่น ๆ - ยกเว้นแน่นอนว่าหัวข้อของวิทยานิพนธ์เป็นการวัดวิธีการ :)