จำนวนข้อผิดพลาดเฉลี่ยต่อ loc นั้นเท่ากันสำหรับภาษาการเขียนโปรแกรมที่แตกต่างกันหรือไม่? [ปิด]

ฉันได้รับแจ้งว่าจำนวนข้อบกพร่อง / ข้อบกพร่องโดยเฉลี่ยต่อบรรทัดของรหัสคือ "คงที่" สำหรับภาษาการเขียนโปรแกรมที่แตกต่างกัน Ruby ของ KLOC 10 ตัวจะมีจำนวนบั๊กเท่ากับ 10 KLOC ของ c ++ อาร์กิวเมนต์มักจะใช้เพื่อส่งเสริมการใช้ภาษาที่แสดงออก (คิดว่าหลาม / ruby ​​มากกว่า c ++ / แอสเซมบลี) เนื่องจากจำนวนบรรทัดเพื่ออธิบายการทำงานเดียวกันจะมีขนาดเล็กลง

ไม่มีใครทราบว่าข้อเรียกร้องนี้มาจากไหน ภาษาระดับสูงขึ้นนำไปสู่ข้อบกพร่องน้อยลงหรือไม่

ตรงกันข้ามกับสัญชาตญาณจำนวนข้อผิดพลาดต่อ 1,000 บรรทัดดูเหมือนจะค่อนข้างคงที่โดยไม่คำนึงถึงภาษาเฉพาะที่เกี่ยวข้อง Steve McConnellผู้เขียนโค๊ดสมบูรณ์และการประมาณค่าซอฟต์แวร์: เข้าใจอย่างลึกซึ้งถึงศิลปะสีดำในรายละเอียดบางอย่าง

ฉันไม่มีสำเนาของฉันพร้อมส่ง - พวกเขานั่งอยู่บนชั้นวางหนังสือในที่ทำงาน - แต่ Google อย่างรวดเร็วพบคำพูดที่เกี่ยวข้อง:

ค่าเฉลี่ยอุตสาหกรรม: "ข้อผิดพลาดประมาณ 15 - 50 ข้อต่อรหัสส่ง 1,000 บรรทัด"
(สตีฟ) กล่าวเพิ่มเติมว่านี่มักจะเป็นตัวแทนของรหัสที่มีระดับของการเขียนโปรแกรมที่มีโครงสร้างอยู่ด้านหลัง แต่อาจรวมถึงการผสมผสานของเทคนิคการเข้ารหัส

อ้างอิงจากCode Completeพบได้ที่นี่: http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

หากหน่วยความจำทำงานได้อย่างถูกต้องสตีฟจะทำการอภิปรายอย่างละเอียดซึ่งแสดงให้เห็นว่าตัวเลขนั้นมีความคงที่ในภาษาต่างๆ (C, C ++, Java, Assembly และอื่น ๆ ) และแม้จะมีปัญหา (เช่นการกำหนดว่า

ที่สำคัญที่สุดคือเขามีแหล่งอ้างอิงจำนวนมาก - เขาไม่ได้เสนอความคิดเห็นที่ไม่มีเงื่อนไข แต่มีการอ้างอิงเพื่อสำรองข้อมูลเหล่านั้น

ดูเหมือนว่าจะเดือดลงไปถึงสิ่งนี้: จำนวนข้อบกพร่องโดยเฉลี่ยต่อ kloc ดูเหมือนจะเป็นทรัพย์สินของความจริงที่ว่านักพัฒนาเป็นมนุษย์ที่เข้าใจผิดได้มากกว่าข้อดีที่แปลกประหลาดหรือข้อเสียของภาษาหรือแพลตฟอร์มเฉพาะ

(นอกเหนือจาก: หากคุณยังไม่มี Code Complete ให้ไปซื้อสำเนาของตัวเองและอ่านอย่างละเอียด - คุ้มค่ากับการลงทุน)

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

การอ้างสิทธิ์คือ - ที่ดีที่สุด - ไร้เดียงสา

SLOC ไม่ใช่ตัวชี้วัดที่เชื่อถือได้สำหรับสิ่งที่มีประโยชน์ยกเว้นว่าอาจเปรียบเทียบขนาดของโครงการสองโครงการขึ้นไป นอกจากนี้ยังมี SLOC สองประเภทที่แตกต่างกันคือ LOC ทางกายภาพและ LOC เชิงตรรกะและอาจแตกต่างกันอย่างมีนัยสำคัญ ลองพิจารณาตัวอย่างนี้จาก Wikipedia :

for (i = 0; i < 100; i += 1) printf("hello"); 

ที่นี่เรามี LOC ทางกายภาพหนึ่งแห่ง แต่มีสองตรรกะ ( forและprintfข้อความ) แต่แน่นอนเราสามารถเขียนตัวอย่างเป็น:

for (i = 0; i < 100; i += 1) 
  printf("hello"); 

ซึ่งจะให้เราสอง LOC ทางกายภาพและสอง LOCs ตรรกะ ฉันคิดว่าเป็นที่ชัดเจนว่าการวัด "บั๊กต่อตำแหน่ง" ใด ๆ ที่ขึ้นอยู่กับ LOC ทางกายภาพจะเสียรูปแบบการเขียนโปรแกรมดังนั้นการวัดของเราจะไร้ประโยชน์อย่างมาก

ในทางกลับกันถ้าเราไปด้วย LOC เชิงตรรกะแล้วการวัดของเราจะขึ้นอยู่กับวากยสัมพันธ์ของภาษานั้น ๆ แม้ว่าการวัดผลที่ได้อาจมีประโยชน์เล็กน้อยเมื่อเปรียบเทียบโครงการที่เขียนในภาษาเดียวกัน แต่ก็ไม่มีประโยชน์พอสมควรสำหรับโครงการที่เขียนในภาษาต่างๆ

แหล่งหนึ่งที่เป็นไปได้สำหรับการอ้างสิทธิ์คือความล้มเหลวของซอฟต์แวร์และความล้มเหลวของซอฟต์แวร์ Les Hatton :

เราสามารถสรุปได้ว่าการเลือกภาษาการเขียนโปรแกรมนั้นเกี่ยวข้องกับความน่าเชื่อถือน้อยที่สุด

หลังจากนั้นกระดาษกล่าวถึงความหนาแน่นข้อบกพร่องที่คล้ายกันสำหรับ C และ C ++:

ในการศึกษาเมื่อเร็ว ๆ นี้เปรียบเทียบสองระบบที่มีขนาดใกล้เคียงกัน (ประมาณ 50,000 บรรทัดต่อหนึ่ง) หนึ่งใน C และอีกหนึ่งใน C ++ ที่ออกแบบโดยวัตถุความหนาแน่นของข้อบกพร่องที่เกิดขึ้นแสดงให้เห็นว่ามีค่าเท่ากับ 2.4 และ 2.9 ต่อ 1,000 บรรทัดตามลำดับ

อย่างไรก็ตามนี่ไม่ได้หมายความว่า "บั๊กต่อ LOC" เป็นค่าคงที่ในภาษาการเขียนโปรแกรมหรือมันจะมีความสำคัญหากเป็นเช่นนั้น

การสังเกตนี้เก่ามากและมาจากแหล่งข้อมูลที่น่าเคารพนับถืออย่างมากคือเฟรดบรูคในหนังสือ "The Mythical Man Month" เขาเป็นผู้จัดการอันดับต้น ๆ ของ IBM และจัดการโครงการการเขียนโปรแกรมจำนวนมากรวมถึงระบบปฏิบัติการระบบปฏิบัติการ milions-of-line ในความเป็นจริงเขารายงานว่าจำนวนข้อบกพร่องในโปรแกรมไม่ได้เป็นสัดส่วนกับความยาวของรหัส แต่เป็นกำลังสอง ! จากการวิจัยของเขาพบว่าจำนวนข้อบกพร่องนั้นแปรผันตามความยาวของโปรแกรมต่อกำลัง 1.5 กล่าวอีกนัยหนึ่งโปรแกรมที่มีความยาวมากกว่าสิบเท่าจะมีข้อผิดพลาดมากกว่า 30 เท่า และเขารายงานว่าสิ่งนี้มีอยู่ในทุกภาษาโปรแกรมและระดับของภาษาโปรแกรม

ฉันไม่พบ Bugs ต่อ LOC ให้เป็นค่าคงที่สำหรับภาษาใดภาษาหนึ่ง ข้อบกพร่องต่อ LOC ดูเหมือนว่าตัวชี้วัดที่ผู้จัดการบางคนใช้ในการกำหนดคุณภาพของนักพัฒนาเมื่อต้องตรวจสอบเวลา

นอกเหนือจากนี้บางภาษามีแนวโน้มที่จะเกิดข้อผิดพลาดหรือข้อบกพร่องมากกว่าภาษาอื่น ๆ โดยทั่วไป แต่ไม่เสมอไปนี่เป็นภาษาระดับต่ำกว่าภาษาที่สูงกว่า ตัวอย่างเช่นการเขียนโค้ดใน C กับ C # (หรือ Java.) ฉันมักจะพูดเพราะความเป็นจริงของมันและปมของคำตอบที่คุณกำลังมองหาลงมาที่คุณภาพของนักพัฒนาและการเขียนโปรแกรมในสถานที่ ฉันเห็นนักพัฒนา C ที่ดีมากที่มีคุณภาพโค้ดสูงกว่าและนับจำนวนข้อบกพร่องน้อยกว่านักพัฒนา Java / C # โดยเฉลี่ย นี่คือหนึ่งรายการที่แยกนักพัฒนาอาวุโสออกจากรุ่นรอง ไม่ใช่จำนวน LOC ที่พวกเขาเขียนในกรอบเวลาที่กำหนด แต่คุณภาพของรหัสที่เขียนโดยไม่คำนึงถึงภาษา LOC หรือกรอบเวลา

คำตอบเดียวที่ฉันสามารถบอกได้ว่าอาจเกี่ยวข้องกันก็คือยิ่ง LOC ยิ่งมีข้อบกพร่องมากเท่าไหร่ก็ยิ่งมีข้อบกพร่องมากขึ้นเท่านั้น

ข้อบกพร่องต่อสายของรหัส

Bugs / LOC สัมพันธ์กับบุคคลเท่านั้น สำหรับธุรกิจที่ใช้เครื่องมือติดตามบั๊กที่ลิงก์กับที่เก็บซอร์สโค้ด เป็นไปได้สำหรับผู้จัดการที่จะจัดการปัญหาโดยนักพัฒนาเรียงตามปัญหาที่ผ่านมาและการเปลี่ยนแปลงรหัส

ข้อบกพร่องมีความสัมพันธ์กับงานของคุณ

นักพัฒนาซอฟต์แวร์อาวุโสที่มีประสบการณ์สูงมีทักษะสูงฉลาดและสามารถทำงานอิสระได้มีแนวโน้มที่จะมีการบันทึกข้อบกพร่องเพิ่มเติมในระบบติดตามจากนั้นเป็นนักพัฒนารุ่นน้องที่มีประสบการณ์น้อย

เป็นไปได้อย่างไร?

นักพัฒนาอาวุโสมักมีส่วนร่วมในงานพัฒนาความเสี่ยงที่สูงขึ้น การสร้างโค้ดใหม่และการสร้างระบบใหม่เป็นตัวอย่าง นักพัฒนารุ่นน้องมักได้รับมอบหมายให้แก้ไขปัญหาที่ทราบแล้วซึ่งไม่คุ้มค่ากับเวลาของนักพัฒนาอาวุโส

ดังนั้นการมอบหมายงานจูเนียร์จึงไม่ได้แนะนำบั๊ก แต่ทำการแก้ไขและนักพัฒนาอาวุโสได้รับอนุญาตให้เสี่ยงต่อการแนะนำพวกเขาเพราะประโยชน์ของสิ่งที่พวกเขากำลังพยายามที่จะเก็บถาวรนั้นสำคัญกว่าประเด็นเล็ก ๆ น้อย ๆ งาน

ไวยากรณ์ภาษาเป็นสิ่งสำคัญ

ข้อโต้แย้งที่ว่าภาษานั้นมีข้อบกพร่องน้อยกว่าเพราะมันสามารถที่จะประสบความสำเร็จได้มากขึ้นในโค้ดที่น้อยลงนั่นคือตำนานที่สมบูรณ์ ภาษาที่มีโครงสร้างสูงเช่น C ++ / C # / Java บังคับให้นักพัฒนาแสดงชัดเจนในการเขียนสิ่งที่ควรจะเป็นคำสั่งที่เป็นภาษาเช่น Python / PHP ไม่มีโครงสร้างมาก ภาษาเหล่านั้นอนุญาตให้มีการแสดงออกเป็นลายลักษณ์อักษรที่ไม่เพียง แต่จะสร้างความสับสนให้กับนักพัฒนา แต่ยังแยกวิเคราะห์ภาษา

คอมไพเลอร์ลดข้อบกพร่อง

จำนวนข้อบกพร่องใน Python / PHP ทำให้มันกลายเป็นเซิร์ฟเวอร์การผลิตเพราะไม่มีคอมไพเลอร์ที่เตือนผู้พัฒนาว่ามีบางอย่างไม่ถูกต้อง เมื่อคุณวัดข้อบกพร่องต่อ LOC นั้นก่อนหรือหลังคอมไพเลอร์ได้ประมวลผลซอร์สโค้ดหรือไม่

อัปเดต 2019:

คอมไพเลอร์ไม่ได้สร้างความแตกต่างให้กับธรรมชาติหรือจำนวนข้อบกพร่อง ข้อบกพร่องนั้นสัมพันธ์กับบุคคลที่เขียนซอร์สโค้ดอย่างสมบูรณ์และบั๊กเองอาจมีความรู้สึกส่วนตัวในธรรมชาติ

FWIW ในประสบการณ์ของฉัน

1. มีข้อบกพร่องสองชนิด: a) โปรแกรมไม่เป็นไปตามความคาดหวังและ b) โปรแกรมไม่สามารถทำตามความคาดหวังที่สมเหตุสมผลได้เพราะมันทำให้แฮงค์ / แฮงค์ / จะไม่คอมไพล์

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

สิ่งเหล่านี้ (อีกครั้งในประสบการณ์ของฉัน) ไม่ใช่ฟังก์ชั่นของภาษา แต่เป็นทักษะ / วุฒิภาวะของโปรแกรมเมอร์ โปรแกรมที่มีข้อผิดพลาดน้อยกว่านั้นมักจะมีขนาดเล็กกว่ามากในแง่ของ LOC สำหรับชุดการทำงานที่กำหนด

ฉันเคยเห็นระบบที่บางคนเขียนโปรแกรมในขณะที่คนอื่นเขียนไดเรกทอรีและอดีตมักจะ "เพิ่งทำงาน" เมื่อเทียบกับระบบหลัง

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

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

ภาษาระดับสูงขึ้นนำไปสู่ข้อบกพร่องน้อยลงหรือไม่

สิ่งนี้แตกต่างจากบั๊ก / LOC เนื่องจากภาษาระดับสูงทำได้มากกว่าโดยใช้รหัสน้อยกว่า การใช้ความต้องการคุณสมบัติบางอย่างอาจใช้ LISP 500 บรรทัดกับชุด x86 15000 บรรทัด

ดังนั้นแม้ว่า bugs / LOC จะมีค่าคงที่ระหว่างทุกภาษาภาษาระดับสูงจะยังคงให้บั๊กน้อยลง