มีการใช้ SLOC อย่างถูกต้องเพื่อวัดประสิทธิภาพหรือไม่?

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

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

ในขณะที่ฉันไม่คิดว่าการอ้างสิทธิ์นี้ได้รับการสนับสนุนจากการวิเคราะห์ทางสถิติที่เข้มงวด แต่มีหลักฐานบางอย่างในอุตสาหกรรมที่จะสนับสนุนแนวความคิดนี้หรือไม่?

อาร์กิวเมนต์ของสถาปนิกอาวุโสอาจหมายถึงสองสิ่ง

1. อาจหมายความว่าผู้พัฒนาโดยเฉลี่ยใน บริษัท จะสร้างโค้ดเพิ่มเติมเมื่อใช้ภาษาคงที่มากกว่าเมื่อใช้ไดนามิก ตัวอย่างเช่นหากนักพัฒนาสิบห้าทำงานกับ Java เป็นเวลาหกเดือนพวกเขาจะเขียน 100 KLOC และถ้านักพัฒนาสิบห้าคนเดียวกันทำงานกับ Python เป็นเวลาหกเดือนพวกเขาจะเขียนเพียง 50 KLOC

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

2. เขาอาจหมายความว่าผู้พัฒนาโดยเฉลี่ยใน บริษัท ผลิตโค้ดน้อยกว่าเมื่อใช้ภาษาคงที่กว่าเมื่อใช้ไดนามิกส์: นักพัฒนาสิบห้าคนจะเขียนในหกเดือน 100 KLOC ใน Java หรือ 200 KLOC ใน Python

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

ในทั้งสองกรณี LOC ไม่ได้เป็นตัวชี้วัดที่มีคุณค่าเพราะคุณลักษณะเดียวกันจะไม่แปลในจำนวนเดียวกันของเส้นของรหัสในภาษาที่แตกต่าง บางภาษามีแนวโน้มที่จะละเอียดมากขึ้น; อื่น ๆ - กะทัดรัดกว่า ในบางกรณีความกะทัดรัดมีค่า แต่ไม่มีกฎทั่วไปสำหรับสิ่งนั้น ตัวอย่างสุดขีดคือภาษา Brainfuck ซึ่งมีขนาดกะทัดรัดมาก แต่ไม่เป็นที่นิยมสำหรับการอ่าน การเปรียบเทียบภาษาที่คล้ายคลึงกันอาจเป็นเรื่องยุ่งยาก: ตัวอย่างเช่นเมื่อพูดถึงการดัดโค้ง Java ตามสไตล์ K&R ในขณะที่ใน C # การเปิดลอนรั้งอยู่ในสายของตัวเองในกรณีส่วนใหญ่เมื่อทำตามสไตล์ทางการซึ่งนำไปสู่การประดิษฐ์ เพิ่ม LOCs สำหรับ C # และจะเกิดอะไรขึ้นเมื่อเปรียบเทียบภาษาเชิงกระบวนวิธีกับภาษาเชิงวัตถุหรือภาษาเชิงฟังก์ชัน

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

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

เกี่ยวกับประสิทธิภาพและ SLOC

ปัญหาเกี่ยวกับ SLOC

ปัญหาเกี่ยวกับตัวชี้วัดSLOCคือการวัดปริมาณโดยประมาณของโค้ดที่เขียนโดยไม่คำนึงถึง:

• คุณภาพของรหัส (เช่นจะเกิดอะไรขึ้นถ้าทุกๆ 100 SLOC คุณต้องเพิ่ม 90 SLOC อีกครั้งเนื่องจากข้อผิดพลาด แต่คุณไม่รู้ตอนที่ส่งรหัสของคุณหรือไม่)
• เป้าหมายที่มาถึงด้วยรหัส (เช่น 10K SLOC จัดการกับทุกกรณีการใช้งานที่คาดหวังหรือเรื่องราวของผู้ใช้หรือไม่หรือเป็นเพียงชุดย่อยเล็ก ๆ )
• ความสามารถในการบำรุงรักษาของรหัส (เช่นคุณจะต้องเพิ่มรหัสเพิ่มเติม 1% หรือ 50% สำหรับการปรับรหัสให้เป็นไปตามข้อกำหนดการพัฒนาที่คาดหวังได้หรือไม่)

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

ดังนั้น SLOC จึงไม่ใช่วิธีที่ดีที่สุดในการวัดประสิทธิภาพ

เรากำลังพิจารณาผลิตผลอะไร

วัดผลผลิตสำหรับกระบวนการ ดังนั้น SLOC อาจเป็นตัวบ่งชี้ที่ถูกต้องสมบูรณ์แบบสำหรับกระบวนการเข้ารหัสเพียงอย่างเดียว

ตัวอย่างเช่นคุณเข้าใจผิดเกี่ยวกับความต้องการใช้เวลาห้าเดือนในการผลิตซอฟต์แวร์แสดงให้ผู้ใช้พบว่ามันผิดปกติและใช้เวลาอีก 5 เดือนเพื่อเขียนใหม่ให้ดีตั้งแต่เริ่มต้นคุณจะได้ผลผลิตที่เท่ากันใน SLOC / เดือนที่ทีมเขียนรหัสถูกต้องในครั้งแรกเช่นเนื่องจากพวกเขาใช้กระบวนการที่คล่องตัวซึ่งช่วยลดความเข้าใจผิดผ่านการป้อนกลับบ่อย ผลผลิตที่เท่ากันอย่างเห็นได้ชัดนี้ซ่อนปัญหามากมาย

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

จะวัดผลการส่งมอบซอฟต์แวร์ได้อย่างไร

มีหลายวิธี:

• วิธีการทั่วไปในวิศวกรรมซอฟต์แวร์แบบคลาสสิกคือFunction Points (FP) คะแนนฟังก์ชั่นถูกวัดตามความต้องการในการเติมเต็ม (เช่นจำนวนฟอร์มจำนวนฟิลด์ในแต่ละฟอร์ม ฯลฯ ... ) ผลผลิตจะถูกวัดเป็น FP ต่อหน่วยเวลาและต่อคน บริษัท บางแห่งมีข้อมูลที่บอกจำนวนฟังก์ชันที่ผู้พัฒนาสามารถสร้างได้ต่อหน่วยเวลาในภาษาที่กำหนดสำหรับโดเมนที่กำหนด ปัญหาของ FP คือมันต้องการรายละเอียดความต้องการอย่างละเอียดและใช้เวลานาน
• วิธีการที่ทันสมัยและใช้งานจริงมากขึ้นคือจุดเรื่องราว (SP) สิ่งเหล่านี้ใช้เพื่อประเมินความซับซ้อนของรหัสที่จะผลิตและใช้เป็นประจำในการประเมินความเร็วของทีมพัฒนา อย่างไรก็ตาม SP เป็นตัวชี้วัดการประเมินสำหรับงานที่ทำก่อนที่จะทราบรายละเอียดทั้งหมด ไม่ใช่มาตรการสุดท้ายของสิ่งที่เกิดขึ้นจริง ดังนั้นการดูแลบางส่วนจะต้องดำเนินการเมื่อใช้มันเป็นตัวชี้วัดผลผลิตเพราะมันจะย้อนกลับมาเกี่ยวกับกระบวนการการประเมิน

เกี่ยวกับผลผลิตของการพิมพ์แบบคงที่และแบบไดนามิก

ฉันต้องสารภาพว่าฉันเป็นแฟนตัวยงของภาษาที่พิมพ์แบบคงที่เพราะในตัวตนภายในของฉันฉันรู้ว่ามันน่าเชื่อถือมากขึ้น (การเข้ารหัสเป็นเวลาหลายปีพิสูจน์แล้วว่าฉัน)

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

สถาปนิกของคุณใช่มั้ย

อาจจะอาจจะไม่.

แต่ข้อโต้แย้งของเขาดูเหมือนจะไม่ถูกต้อง: การเพิ่มผลผลิตของภาษาที่พิมพ์แบบคงที่มาจากข้อผิดพลาดจำนวนมากที่คอมไพเลอร์ติดตั้งไว้ล่วงหน้า

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

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

การศึกษาใดที่สนับสนุนข้อเรียกร้องดังกล่าว

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

• การเปรียบเทียบเชิงประจักษ์ของระบบประเภทคงที่และแบบไดนามิกในการใช้งาน API ในการแสดงตนของ IDE: Java กับ groovy กับ eclipse , 2014
• เมื่อพิจารณาถึงผลการผลิตของการประกาศประเภทอย่างชัดเจนปี 2014 แต่ไม่ได้ข้อสรุป
• การศึกษาเชิงประจักษ์เกี่ยวกับอิทธิพลของระบบชนิดคงที่ต่อการใช้งานของซอฟต์แวร์ที่ไม่มีเอกสาร

นี่คือตัวอย่างตัวอย่างสำหรับสถาปนิกอาวุโสของคุณ: สมมติว่าฉันต้องการเขียนลำดับชั้นของสามคลาสซึ่งสองอันมาจากที่สามโดยใช้ฟังก์ชั่นเสมือนบางอย่างที่คลาสพื้นฐานกำหนด

ถ้าฉันเขียนสามคลาสนี้ใน C ++ มันจะค่อนข้างตรงไปตรงมา ฉันประกาศคลาสใช้เสมือนในสถานที่ที่ถูกต้องและทำได้

ถ้าฉันเขียนคลาสสามตัวนี้ใน C ฉันจะต้องเพิ่มโค้ดอีกสักหน่อย: ฉันต้องกำหนดstructs สำหรับ v-tables ฉันต้องเพิ่มตัวชี้ v-table เข้ากับคลาสพื้นฐานฉันต้องเพิ่ม รหัสไปที่ constructors เพื่อตั้งค่าตัวชี้ v-table จริง ๆ ฉันต้องเพิ่ม code ที่ constructors เพื่อเรียกตัวสร้างคลาสพื้นฐานจริง ๆ ฉันต้องเพิ่ม code เพื่อทำการจัดสรรหน่วยความจำอย่างชัดเจนก่อนเรียกตัวสร้าง (ซึ่ง C ++ newทำในขั้นตอนเดียว ) เช่นเดียวกันฉันต้องแยกการทำลายจากการfree()เรียกครั้งต่อๆ ไปเรื่อย ๆ

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

ภาษาใด ๆ ที่ต้องใช้รหัสสำเร็จรูปจำนวนหนึ่งจะมีประสิทธิภาพมากขึ้นในแง่ของ SLOCs มากกว่าภาษาที่ไม่ต้องการรหัสสำเร็จรูปจำนวนเดียวกัน

คุณจะเห็นว่าข้อโต้แย้ง SLOC นั้นมีข้อบกพร่องพื้นฐานอย่างแท้จริงซึ่งฉันเห็นจริง ๆ แล้วเป็นอย่างอื่น: ฉันจะกล่าวว่า "โปรแกรมเมอร์มีแนวโน้มที่จะสร้าง SLOCs มากขึ้นในภาษาคงที่" เพื่อหมายถึง: "ภาษาคงดูเหมือนว่าต้องการมากกว่า รหัสสำเร็จรูปและลดประสิทธิภาพการทำงาน "

ฉันจะเป็นคนที่แตก

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

1. ใช่บางภาษาสามารถทำได้มากกว่าโดยใช้รหัสน้อย ในความเป็นจริงเรามีกรอบทั้งหมดที่เราได้สร้างขึ้นว่า "อัตโนมัติ" ส่วนใหญ่ของการพัฒนาสำหรับปัญหาทางธุรกิจเฉพาะของเรา (back-end เท่านั้น) ผลลัพธ์ทั้งหมดนี้ไม่ใช่ว่าคนเขียนรหัสน้อยลง แต่เพียงว่าเรามีเวลาเขียนรหัสมากขึ้น ดังนั้นใน บริษัท ของเราอัตราการเขียนรหัสโดยรวมค่อนข้างคงที่ในเทคโนโลยีและขึ้นอยู่กับระดับความสามารถของวิศวกรเป็นหลัก
2. แนวคิดที่ว่านักพัฒนาซอฟต์แวร์ที่ดีกว่าจะผลิตรหัสน้อยลงเพราะพวกเขาเขียนอย่างชาญฉลาดไม่เป็นความจริงแน่นอน ใช่โปรแกรมที่ออกแบบมาดีกว่าอาจใช้โค้ดน้อยลง อย่างไรก็ตามฉันได้พบเป็นการส่วนตัวว่านักพัฒนา "ดีกว่า" เขียนโค้ดที่มีประสิทธิภาพมากขึ้นไม่ต้องใช้เวลาในการวางแผนนานไปกว่านักพัฒนารุ่นใหม่ที่กำลังเขียนสิ่งที่ไกล เป็นผลให้นักพัฒนาอาวุโสมากขึ้นจะได้รับผ่านการเขียนโปรแกรมของพวกเขาได้เร็วขึ้นและไปที่การเขียนรหัสที่แตกต่างในอัตราที่สูงเดียวกัน

ส่วน lat นั่นคือสรุปโดยรวมของฉัน BTW สิ่งที่ฉันได้พบก็คือไม่ว่าจะเป็นเทคโนโลยีแบบกองซ้อนหรือโครงการผู้พัฒนาส่วนใหญ่มีจังหวะของตัวเองซึ่งเป็นก้าวที่พวกเขาดำเนินการ หากภาษามีคุณสมบัติมากมายที่ทำให้นักพัฒนาโค้ดมีประสิทธิภาพมากขึ้นนั่นเป็นประโยชน์อย่างยิ่งสำหรับธุรกิจ แต่นั่นไม่ได้หมายความว่าพวกเขาจะเขียนโค้ดน้อยลง แต่จะทำให้คุณสมบัติต่าง ๆ ทำงานได้เร็วขึ้นและเปลี่ยนไปใช้รหัสใหม่ได้อย่างรวดเร็ว อีกครั้งผลลัพธ์ที่ได้คือพวกเขาให้คะแนนว่าโค้ดขึ้นอยู่กับทักษะของพวกเขาเป็นหลัก ในความเป็นจริงด้วยเหตุนี้โดยทั่วไปฉันคาดหวังว่ากองเทคโนโลยีจะสร้างความแตกต่างในอัตราที่ตั๋วและฟีเจอร์ได้รับการพัฒนามากกว่าอัตราที่รหัสคน

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

ข้อยกเว้นหนึ่งข้อ

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

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

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

แม้ว่าฉันจะกระโดดบนเกวียน ฉันคิดว่าผลกระทบต่อพฤติกรรมของโปรแกรมเมอร์จะต้องมีการเน้น

การใช้ SLOC เป็นมาตรการสำหรับการผลิตมีผลเป็นพิษต่อขวัญกำลังใจของโปรแกรมเมอร์ ทันทีที่วิศวกรในทีม / บริษัท ของคุณรู้ว่ามีการวัด SLOC หลายอย่างเกิดขึ้น:

1. พวกเขาเริ่มเขียนโค้ดที่ยาวขึ้นเพื่อทำหน้าที่เดียวกัน
2. พวกเขาจะใส่ใจน้อยกว่าเกี่ยวกับคุณภาพของรหัสของพวกเขา
3. พวกเขาจะหยุดทำสิ่งอื่น ๆ ที่ช่วยทีมของคุณ (การสรรหาการดีบั๊กการช่วยเหลือจูเนียร์)
4. พวกเขาจะเกลียดงานของพวกเขาและมีแนวโน้มที่จะจากไป

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

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

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

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

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

ในความจริงจังทั้งหมดการเปรียบเทียบประสิทธิภาพของทีม / ภาษานั้นไม่มีความหมายเนื่องจากมีปัจจัยเพิ่มเติมมากมายที่ส่งผลต่อประสิทธิภาพการทำงานของทีมคุณไม่สามารถสรุปข้อสรุปที่มีความหมายได้

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

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