คนในตำนานเดือนละ 10 บรรทัดต่อวันของนักพัฒนา - โครงการขนาดใหญ่ใกล้แค่ไหน? [ปิด]

129

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

ปิดให้บริการใน8 ปีที่ผ่านมา

ทุกคนมักจะบอกว่าพวกเขาสามารถเอาชนะ "10 บรรทัดต่อนักพัฒนาต่อวัน" จาก "Mythical Man Month" และการเริ่มต้นโปรเจ็กต์ฉันมักจะได้รับสองสามร้อยบรรทัดในหนึ่งวัน

แต่ที่นายจ้างคนก่อนของฉันนักพัฒนาทุกคนมีความเฉียบแหลมมาก แต่มันเป็นโครงการขนาดใหญ่โค้ดกว่าล้านบรรทัดพร้อมข้อกำหนดการรับรองที่ยุ่งยากมากและการเชื่อมต่อกับโครงการอื่น ๆ ที่มีจำนวนหลายล้านไลน์ ในบางจุดเพื่อเป็นการฝึกด้วยความอยากรู้อยากเห็นฉันได้พล็อตบรรทัดของรหัสในผลิตภัณฑ์การจัดส่งในกลุ่มของฉัน (ไม่นับเครื่องมือที่เราพัฒนาขึ้น) และเพิ่มขึ้นเรื่อย ๆ โดยเพิ่มขึ้นเป็นประมาณ 12 บรรทัดต่อผู้พัฒนาต่อวัน ไม่นับการเปลี่ยนแปลงรหัสทดสอบหรือข้อเท็จจริงที่ว่านักพัฒนาไม่ได้ทำงานกับรหัสโครงการจริงทุกวัน

คนอื่นเป็นยังไงบ้าง? และคุณต้องเผชิญกับข้อกำหนดประเภทใด (ฉันคิดว่าเป็นปัจจัย)

metrics

— Matthias Wandel
แหล่งที่มา

13

ควรเป็นวิกิชุมชน

— Malfist

24

ถ้า "10" เป็นเลขฐานสองมันจะอยู่ใกล้กับเครื่องหมายมากกว่า

— geofftnz

2

คำถามที่น่าสนใจมาก :)

— Emil H

9

ฉันพบคำพูดที่ดีนี้ "การวัดความคืบหน้าของการเขียนโปรแกรมตามบรรทัดของโค้ดก็เหมือนกับการวัดความก้าวหน้าของการสร้างเครื่องบินตามน้ำหนัก" ในเว็บไซต์นี้ [ลิงค์] ( devtopics.com/101-great-computer-programming-quotes )

— mm24

2

@Greg Bacon, Bill the Lizard: ฉันอยากจะเปิดคำถามนี้อีกครั้ง อาจไม่ตรงกับกฎของ SO แต่ก็ดึงดูดผู้เยี่ยมชมได้อย่างแน่นอน (จนถึงขณะนี้ผู้ชม 35875 คน)

— Skippy Fastol

46

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

งานจะแตกต่างกันระหว่างสองอย่าง - ในโครงการขนาดใหญ่คุณมักจะใช้เวลาส่วนใหญ่ในการหาความสัมพันธ์ระหว่างชิ้นส่วนและมีเพียงเล็กน้อยเท่านั้นในการเปลี่ยนแปลง / เพิ่มเติม ในขณะที่ในโครงการใหม่คุณมักจะเขียน ... จนกว่าจะใหญ่พอและอัตราจะลดลง

— Liran Orevi
แหล่งที่มา

จริง ในช่วงต้นของโครงการกล่าวว่าโฆษณาสุทธิมีขนาดใหญ่กว่ามาก

— Matthias Wandel

1

ดังนั้นจึงยังคงรักษาทฤษฎีที่จะแบ่งโครงการขนาดใหญ่ไปยังส่วนต่างๆที่เป็นอิสระ (อาจเป็นโครงการอิสระก็ได้) - สำหรับการแยกส่วน

— sergzach

108

ในโครงการปัจจุบันของฉันในบางโมดูลฉันภูมิใจที่ได้สนับสนุนการนับบรรทัดเชิงลบในฐานรหัส การระบุว่าส่วนใดของโค้ดมีความซับซ้อนที่ไม่จำเป็นและสามารถทำให้ง่ายขึ้นด้วยการออกแบบที่สะอาดและชัดเจนขึ้นเป็นทักษะที่มีประโยชน์

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

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

— Charles Bailey
แหล่งที่มา

49

+1 สำหรับการสนับสนุนเส้นลบ ครั้งหนึ่งฉันเคยทำงานในโครงการเล็ก ๆ ที่ฉันลดจำนวนบรรทัดจาก 15K เป็น 5K ในขณะที่เพิ่มคุณสมบัติใหม่ ๆ (และลดจำนวนข้อผิดพลาดลงอย่างมากและเพิ่มความเร็ว)

— rmeador

55

ฉันชอบคำพูดนี้:

หากเราต้องการนับบรรทัดของโค้ดเราไม่ควรถือว่าเป็น "รายการที่สร้าง" แต่เป็น "บรรทัดที่ใช้ไป" - Edsger Dijkstra

บางครั้งคุณมีส่วนร่วมโดยการลบโค้ดมากกว่าการเพิ่ม

— rlovtang
แหล่งที่มา

30

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

— OtávioDécio
แหล่งที่มา

25

ฉันไม่ได้ใช้มันเป็นตัวชี้วัดประสิทธิภาพการทำงาน นี่เป็นการออกกำลังกายส่วนตัวเพื่อความอยากรู้อยากเห็นของฉันเอง

— Matthias Wandel

3

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

— OtávioDécio

1

@ Matthias: ฉันควรแก้ไขสิ่งนั้นใน OP ถ้าฉันเป็นคุณฉันสำหรับหนึ่งคนจะมีน้อย ... ก้าวร้าว: P

— annakata

28

คนอื่นเป็นยังไงบ้าง?

ฉันเป็นนักพัฒนาเต็มเวลาเพียงคนเดียวในบริษัท ของเราและเขียนโค้ด OCaml และ F # 500,000 บรรทัดในช่วง 7 ปีที่ผ่านมาซึ่งเท่ากับโค้ดประมาณ 200 บรรทัดต่อวัน อย่างไรก็ตามโค้ดส่วนใหญ่นั้นเป็นตัวอย่างการสอนซึ่งประกอบด้วยโปรเจ็กต์ต่างๆหลายร้อยโปรเจ็กต์แต่ละอันยาวไม่กี่ร้อยบรรทัด นอกจากนี้ยังมีความซ้ำซ้อนระหว่าง OCaml และ F # เราไม่ได้บำรุงรักษาฐานรหัสภายในที่มีขนาดใหญ่กว่า 50kLOC

นอกเหนือจากการพัฒนาและบำรุงรักษาซอฟต์แวร์ของเราเองแล้วฉันยังได้ให้คำปรึกษากับลูกค้าหลายรายในอุตสาหกรรมในช่วง 7 ปีที่ผ่านมา สำหรับลูกค้ารายแรกฉันเขียน OCaml 2,000 บรรทัดในช่วง 3 เดือนซึ่งเป็นโค้ด 20 บรรทัดต่อวัน สำหรับไคลเอนต์ถัดไปพวกเราสี่คนเขียนคอมไพเลอร์ที่สร้างโค้ด C / C ++ / Python / Java / OCaml นับล้านบรรทัดรวมทั้งเอกสารใน 6 เดือนซึ่งเป็นโค้ด 2,000 บรรทัดต่อวันต่อนักพัฒนา สำหรับไคลเอนต์อื่นฉันแทนที่ 50kLOC ของ C ++ ด้วย 6kLOC ของ F # ใน 6 เดือนซึ่งเป็น -352 บรรทัดต่อวัน สำหรับลูกค้ารายอื่นฉันกำลังเขียน OCaml 15kLOC ใหม่ใน F # ซึ่งจะมีขนาดเท่ากันดังนั้นรหัส 0 บรรทัดต่อวัน

สำหรับลูกค้าปัจจุบันของเราฉันจะแทนที่ 1,600,000 บรรทัดของ C ++ และรหัส Mathematica ด้วย ~ 160kLOC ของ F # ใน 1 ปี (โดยการเขียนคอมไพเลอร์ตามความต้องการ) ซึ่งจะเป็น -6,000 บรรทัดของโค้ดต่อวัน นี่จะเป็นโครงการที่ประสบความสำเร็จมากที่สุดของฉันจนถึงปัจจุบันและจะช่วยลูกค้าของเราได้หลายล้านดอลลาร์ต่อปีด้วยค่าใช้จ่ายที่กำลังดำเนินอยู่ ฉันคิดว่าทุกคนควรตั้งเป้าหมายที่จะเขียนโค้ด -6,000 บรรทัดต่อวัน

— JD
แหล่งที่มา

1

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

— 24

7

@ mm24 "คุณช่วยชี้แจงได้ไหมว่าทำไมการเขียนโค้ดใหม่ใน F # จะช่วยประหยัดเงินให้กับลูกค้าของคุณ" ประการแรกพวกเขาได้รับความเสียหายจาก Wolfram Research ที่เรียกเก็บเงินจากสัญญาที่ปรึกษามูลค่า 1 ล้านปอนด์เพื่อแก้ไขปัญหาที่พวกเขาตั้งใจนำมาใช้ในการอัปเกรด Mathematica เช่นการเปลี่ยนความหมายของ [LongDash] ประการที่สองพวกเขาจะรวมฐานรหัสสองฐาน (Mathematica & C ++) ซึ่งปัจจุบันได้รับการบำรุงรักษาควบคู่กันเป็นฐานรหัส F # เดียวซึ่งไม่เพียงลดความพยายามที่ซ้ำซ้อน แต่การโต้ตอบจำนวนมากยังรวมถึงการอัปเดตและแก้ไขผลิตภัณฑ์ที่ระบุในการทดสอบ

— JD

7

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

— JD

7

@ mm24 ประการที่สี่การปรับปรุงประสิทธิภาพครั้งใหญ่ F # เป็นคำสั่งขนาดที่เร็วกว่า Mathematica และรหัสพิสูจน์แนวคิดใน F # นั้นเร็วกว่ารหัส C ++ ที่ใช้งานจริงถึง 5 เท่า ซึ่งหมายความว่าการทดสอบจะดำเนินการในไม่กี่วินาทีแทนที่จะเป็นชั่วโมงซึ่งการทดสอบจะกลายเป็นส่วนสำคัญของการพัฒนาซึ่งช่วยเพิ่มผลผลิตได้อย่างมาก

— JD

7

@ mm24 ประการที่ห้าความสามารถที่เพิ่มขึ้น พวกเขาต้องการกำจัดรหัสตายและวัดความครอบคลุมของรหัสของการทดสอบ แต่ไม่สามารถทำได้ด้วยเครื่องมือที่ใช้อยู่ การย้ายไปที่. NET ทำให้สิ่งนี้ (และอื่น ๆ !) เป็นเรื่องง่าย

— JD

13

โดยไม่ได้ตรวจสอบสำเนา "The Mythical Man-Month" ของฉันจริงๆ (ทุกคนที่อ่านเรื่องนี้ควรมีสำเนาพร้อมใช้งานจริงๆ) มีบทหนึ่งที่ Brooks มองไปที่การผลิตตามบรรทัดที่เขียนขึ้น ประเด็นที่น่าสนใจสำหรับเขาไม่ใช่จำนวนบรรทัดที่เขียนจริงต่อวัน แต่ความจริงที่ว่าแอสเซมเบลอร์และใน PL / I นั้นใกล้เคียงกัน (ฉันคิดว่านั่นคือภาษาระดับสูงที่ใช้)

Brooks ไม่ได้กำลังจะทิ้งรูปแบบการผลิตโดยพลการ แต่เขากำลังทำงานจากข้อมูลในโครงการจริงและสำหรับทั้งหมดที่ฉันจำได้พวกเขาอาจอยู่ที่ 12 บรรทัด / วันโดยเฉลี่ย

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

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

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

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

— เดวิด ธ อร์นลีย์
แหล่งที่มา

3

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

— Matthias Wandel

11

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

— เจฟฟรีย์ไฮนส์
แหล่งที่มา

จริง แต่คุณจะเจอสถานการณ์นั้นบ่อยขึ้นเมื่อโครงการใหญ่ขึ้น ฉันเขียนโปรแกรม 10 บรรทัดที่สมบูรณ์แบบที่ไม่มีจุดบกพร่อง ทั้งหมดเป็นเรื่องของขนาด

— Matthias Wandel

1

ไม่มีโปรแกรมที่ไม่มีจุดบกพร่อง

— Daniel Moura

14

Bah! ไวยากรณ์ของคุณมีจุดบกพร่อง ...

— RAL

3

@DanielMoura โอ้ฉันไม่เห็นด้วยกับที่ ... โปรแกรม "hello world" อาจไม่มีประโยชน์มากนัก แต่คุณสามารถพูดได้อย่างมั่นใจว่ามันไม่มีจุดบกพร่องใด ๆ :)

— WendiKidd

10

มันจะดีกว่ามากหากตระหนักว่าการพูดถึงบรรทัดจริงของโค้ดนั้นไม่มีความหมายเลย จำนวน Lines of Code (LoC) ทางกายภาพจึงขึ้นอยู่กับรูปแบบการเข้ารหัสซึ่งอาจแตกต่างกันไปตามลำดับความสำคัญจากผู้พัฒนารายหนึ่งไปยังอีกคนหนึ่ง

ในโลก. NET มีวิธีที่สะดวกในการนับ LoC จุดลำดับ จุดลำดับคือหน่วยของการดีบักเป็นส่วนของรหัสที่เน้นด้วยสีแดงเข้มเมื่อวางจุดพัก ด้วยจุดลำดับเราสามารถพูดถึงLoC เชิงตรรกะและเมตริกนี้สามารถเปรียบเทียบกับภาษา. NET ต่างๆได้ เมตริกโค้ด LoC เชิงตรรกะได้รับการสนับสนุนโดยเครื่องมือ. NET ส่วนใหญ่รวมถึงเมตริกโค้ด VisualStudio, NDepend หรือ NCover

ตัวอย่างเช่นนี่คือวิธี 8 LoC (จุดเริ่มต้นและจุดสิ้นสุดของวงเล็บจะไม่ถูกนำมาพิจารณา):

ข้อความแสดงแทน

การผลิต LoC จะต้องนับในระยะยาว บางวันคุณจะคาย LoC มากกว่า 200 LoC บางวันคุณจะใช้เวลา 8 ชั่วโมงในการแก้ไขข้อบกพร่องโดยไม่เพิ่ม LoC แม้แต่ตัวเดียว บางวันคุณจะล้างรหัสที่ตายแล้วและจะลบ LoC บางวันคุณจะใช้เวลาทั้งหมดในการปรับโครงสร้างโค้ดที่มีอยู่และไม่ได้เพิ่ม LoC ใหม่ใด ๆ ลงในผลรวม

โดยส่วนตัวแล้วฉันจะนับ LoC เดียวในคะแนนประสิทธิผลของตัวเองก็ต่อเมื่อ:

ครอบคลุมโดยการทดสอบหน่วย
มีความเกี่ยวข้องกับสัญญารหัสบางประเภท (ถ้าเป็นไปได้แน่นอนว่า LoC ทั้งหมดไม่สามารถตรวจสอบได้ตามสัญญา)

ในสภาพนี้คะแนนส่วนบุคคลของฉันในช่วง 5 ปีที่เข้ารหัสเครื่องมือสำหรับนักพัฒนา NDepend NET เป็นค่าเฉลี่ยของ80 LoC ทางกายภาพต่อวันโดยไม่ต้องเสียสละใด ๆ หมายความว่าคุณภาพรหัส จังหวะยังคงอยู่และฉันไม่เห็นมันลดลงในเร็ว ๆ นี้ สรุปแล้ว NDepend เป็นฐานรหัส C # ที่ปัจจุบันมีน้ำหนักประมาณ 115K LoC ทางกายภาพ

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

— Patrick จากทีม NDepend
แหล่งที่มา

1

โพสต์ของคุณเป็นพื้นฐานและสมควรได้รับการโหวตมากขึ้น

— Skippy Fastol

9

ไม่มีสิ่งที่เรียกว่ากระสุนเงิน

เมตริกเดียวแบบนั้นก็ไร้ประโยชน์โดยตัวมันเอง

ตัวอย่างเช่นฉันมีห้องสมุดชั้นเรียนของตัวเอง ปัจจุบันสถิติต่อไปนี้เป็นจริง:

จำนวนบรรทัดทั้งหมด: 252.682
รหัสบรรทัด: 127.323
ความเห็น: 99.538
บรรทัดว่าง: 25.821

สมมติว่าฉันไม่ได้เขียนความคิดเห็นใด ๆ เลยนั่นคือโค้ด 127.323 บรรทัด ด้วยอัตราส่วนของคุณไลบรารีโค้ดนั้นจะใช้เวลาเขียนประมาณ 10610 วัน นั่นคือ 29 ปี

ฉันไม่ได้ใช้เวลา 29 ปีในการเขียนโค้ดนั้นเนื่องจาก C # ทั้งหมดและ C # ไม่ได้ใช้เวลานานขนาดนั้น

ตอนนี้คุณสามารถโต้แย้งได้ว่ารหัสนั้นไม่ดีทั้งหมดเนื่องจากเห็นได้ชัดว่าฉันต้องเกินเมตริก 12 บรรทัดต่อวันของคุณและใช่ฉันจะเห็นด้วย แต่ถ้าฉันจะนำไทม์ไลน์ไปที่ เมื่อ 1.0 ถูกปล่อยออกมา (และฉันไม่ได้เริ่มสร้างมันจริง ๆ จนกระทั่ง 2.0 ถูกปล่อยออกมา) ซึ่งคือ 2002-02-13 ประมาณ 2600 วันค่าเฉลี่ยคือ 48 บรรทัดต่อวัน

โค้ดทุกบรรทัดดีไหม? Heck no. แต่ลงโค้ดวันละ 12 บรรทัด?

Heck no.

ทุกอย่างขึ้นอยู่กับ

คุณสามารถมีโปรแกรมเมอร์ระดับแนวหน้าในการปั่นรหัสตามลำดับวันละหลายพันบรรทัดและโปรแกรมเมอร์ขนาดกลางจะปั่นรหัสตามลำดับวันละหลายร้อยบรรทัดและคุณภาพก็เหมือนกัน

และใช่จะมีข้อบกพร่อง

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

— Lasse V.Karlsen
แหล่งที่มา

สาธุ! (บวกช่องว่างเพื่อพบกัน 15 นาที)

— เนท

หมายเหตุสถิติเหล่านี้คำนวณโดย DPack ( usysware.com/dpack )

— Lasse V.Karlsen

5

บางทีกฎ 10 บรรทัดต่อวันอาจใช้ไม่ได้กับสิ่งที่เล็กกว่าเช่นไลบรารีชั้นเรียนที่คุณเขียน (ฉันคิดเอาเอง) จำนวนของ Brooks ส่วนใหญ่มาจากโครงการขนาดใหญ่ (OS360 ของ IBM) ซึ่งอยู่ในระดับที่แตกต่างจากไลบรารีคลาสของคุณโดยพื้นฐาน ฉันเดาว่าการสังเกตของ Brooks นั้น (บ่อยครั้ง) ใช้ได้กับโครงการขนาดใหญ่ที่ต้องใช้คนจำนวนมากและเครือข่ายการสื่อสารที่สำคัญของมนุษย์ แต่ไม่ถูกต้องสำหรับโครงการขนาดเล็ก

— J. Polfer

6

Steve McConnell ให้สถิติที่น่าสนใจในหนังสือ "Software Estimation" (p62 ตารางที่ 5.2) เขาแยกความแตกต่างระหว่างประเภทโครงการ (Avionic, Business, Telco ฯลฯ ) และขนาดโครงการ 10 kLOC, 100 kLOC, 250 kLOC ตัวเลขจะได้รับสำหรับแต่ละชุดค่าผสมใน LOC / StaffMonth EG Avionic: 200, 50, 40 ระบบอินทราเน็ต (ภายใน): 4000, 800, 600 ระบบฝังตัว: 300, 70, 60

ซึ่งหมายความว่า: เช่น สำหรับโครงการ Avionic 250-kLOC มี 40 (LOC / เดือน) / 22 (วัน / เดือน) == <2LOC / วัน!

— Valentin Heinitz
แหล่งที่มา

1

250 Terra Lines of Code? KLoC มีอะไรผิดปกติ

— fadedbee

4

ฉันคิดว่าสิ่งนี้มาจากช่วงการพัฒนาน้ำตกซึ่งระยะการพัฒนาจริงของโครงการอาจน้อยถึง 20-30% ของเวลาโครงการทั้งหมด ใช้โค้ดทั้งหมดและหารด้วยเวลาโครงการทั้งหมดแล้วคุณจะได้ประมาณ 10 บรรทัด / วัน หารด้วยช่วงเวลาการเข้ารหัสแล้วคุณจะเข้าใกล้สิ่งที่ผู้คนอ้างถึงมากขึ้น

— pgs
แหล่งที่มา

3

codebase ของเรามีขนาดประมาณ 2.2MLoC สำหรับความพยายามของมนุษย์ 150 ปี นั่นทำให้มีc ++ หรือ c # ประมาณ75บรรทัดต่อนักพัฒนาต่อวันตลอดอายุของโครงการ

— สตีฟคูเปอร์
แหล่งที่มา

2

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

— Loren Pechtel
แหล่งที่มา

1

โครงการขนาดเล็กช่วยได้และโดดเดี่ยว ตอนแรกฉันตกใจมากที่เห็นว่าเราได้ตัวเลขในประวัติศาสตร์นี้อย่างน้อยก็เพิ่มขึ้นทีละน้อย ในช่วงเริ่มต้นโครงการดังกล่าวผลผลิตของฉันสูงขึ้นอย่างน้อย 10 เท่า

— Matthias Wandel

2

การวางแผนที่ดีการออกแบบที่ดีและโปรแกรมเมอร์ที่ดี คุณได้รับ togheter ทั้งหมดและคุณจะไม่ใช้เวลา 30 นาทีในการเขียนหนึ่งบรรทัด ใช่ทุกโครงการต้องการให้คุณหยุดและวางแผนคิดทบทวนทดสอบและแก้ไขข้อบกพร่อง แต่ในสองบรรทัดต่อวันทุก บริษัท จะต้องมีกองทัพเพื่อให้ tetris ทำงาน ...

บรรทัดล่างสุดถ้าคุณทำงานให้ฉัน 2 บรรทัดต่อชั่วโมงคุณควรหากาแฟให้ฉันเยอะ ๆ และนวดเท้าของฉันเพื่อที่คุณจะได้ไม่ถูกไล่ออก

— lcabral
แหล่งที่มา

1

มีคนสงสัยว่าลูกอมผู้จัดการตลอดกาลนี้ได้รับการประกาศเกียรติคุณเมื่อทุกอย่างเป็นแอป sys ที่เขียนด้วยภาษา C เพราะถ้าไม่มีอะไรอื่นเลขวิเศษจะแตกต่างกันไปตามลำดับขนาดขึ้นอยู่กับภาษาขนาดและลักษณะของแอปพลิเคชัน จากนั้นคุณจะต้องลดความคิดเห็นและคุณลักษณะต่างๆ และท้ายที่สุดใครสนใจเกี่ยวกับจำนวนบรรทัดของโค้ดที่เขียน? คุณควรจะเสร็จสิ้นเมื่อถึง 10,000 เส้นหรือไม่? 100K? ตามอำเภอใจ

มันไม่มีประโยชน์

— annakata
แหล่งที่มา

คุณอธิบายขนาดของโครงการได้อย่างไร?

— Matthias Wandel

1

ถ้ามันมาจาก "The Mythical Man-Month" มันมาก่อน C โดยทางยาว ในหนังสือเล่มนั้น Brooks มองไปที่แนวคิดที่ว่าผลลัพธ์ของโปรแกรมเมอร์ในบรรทัด / วันนั้นค่อนข้างคงที่แม้จะใช้ภาษาและสันนิษฐานว่าการเขียนด้วยภาษาที่แสดงออกมากขึ้น (จำนวนบรรทัดต่อหน่วยการทำงานน้อยลง) จะส่งผลให้โปรแกรมเมอร์มีประสิทธิผลมากขึ้น เขาทราบดีว่าจำนวนจะแตกต่างกันอย่างมาก (หลักการทั่วไปของเขาคือระบบปฏิบัติการนั้นยากกว่าโปรแกรมแอปพลิเคชันประมาณ 9 เท่า)

— David Thornley

2

หน่วยรหัสแยกจุดเชื่อมต่อ (นั่นคือการโต้ตอบหน่วย) ระดับชั้นเรียน (ใน OOP) ... มีประมาณล้านวิธี KLOC ไม่ใช่ตัวชี้วัดที่ดีจริงๆนอกจากเป็นหน่วยความซับซ้อนที่อาจเกิดขึ้น (เช่น "นี่ใช้เวลา 3 สัปดาห์ในการดีบักเพราะฉันต้องเจาะทะลุ 4 KLOCs เพื่อหามัน!")

— John Rudy

2

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

— annakata

เรามีจุดเชื่อมต่อมากมายและเช่นนั้น แต่คุณจะนับสิ่งเหล่านั้นได้อย่างไร? เมื่อใดที่บางสิ่งกลายเป็นจุดเชื่อมต่อ ชั้นเรียนมีความสำคัญเมื่อใด ขนาดโค้ดที่คอมไพล์น่าจะเป็นเมตริกที่ดีกว่าภายในระบบและภาษาที่กำหนด แต่จะแตกต่างกันไปในแต่ละระบบ

— Matthias Wandel