ฉันควรจะใส่ใจไหมถ้าอัตราส่วน LOC ต่อวันของฉันสูงเกินไป [ปิด]

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

ฉันควรจะใส่ใจไหม มันเป็นสัญญาณที่ฉันต้องหยุดและตรวจสอบรหัสทั้งหมดที่ฉันได้เขียนถึงวันนี้และ refactor มันได้หรือไม่

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

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

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

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

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

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

วิธีที่ดีที่สุดในการหลีกเลี่ยงภาวะที่กลืนไม่เข้าคายไม่ออกในคำถามของคุณ IMHO คือลืม LOC และปรับโครงสร้างใหม่ตลอดเวลา เขียนการทดสอบรหัสของคุณก่อนใช้งานเพื่อล้มเหลว refactor ที่จะผ่านจากนั้นดูสิ่งที่อาจได้รับการ refactored นั้นและจากนั้นเพื่อปรับปรุงรหัส คุณจะออกจากงานโดยรู้ว่าคุณได้ตรวจสอบงานของคุณซ้ำแล้วซ้ำอีกและคุณจะไม่กังวลเกี่ยวกับการคาดเดาตัวเองอีกในอนาคต การพูดอย่างแนบเนียนถ้าคุณใช้วิธีการทดสอบครั้งแรกตามที่ฉันได้อธิบายการวัด LOC / วันใด ๆ ในโค้ดที่สมบูรณ์ของคุณจะหมายถึงคุณเขียนจำนวน 3-5 เท่าของจำนวนที่วัดได้แล้ว ความพยายาม

ไม่เลย - บางวันคุณกำลังแก้ไขข้อบกพร่องที่หายากและเปลี่ยนเพียงหนึ่งบรรทัด วันอื่น ๆ ที่คุณเพิ่มรหัสใหม่และเขียนหลายพันบรรทัด

LOC รายวันไม่ได้บอกอะไรเลยนอกจากงานประจำวันนั้นสามารถทำได้ด้วยรหัส 400 บรรทัด

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

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

คุณไม่ควรกังวลกับจำนวน LOC ที่คุณผลิตต่อวัน

แต่คุณควรจะใส่ใจ:

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

LOC เป็นการวัดประสิทธิภาพ 'เป็นทางการ' แต่การโต้แย้งกับค่าอาจยาว (ORM สามารถสร้างรหัส 50,000 บรรทัดใน 3 นาทีอย่างไรก็ตามหากการออกแบบฐานข้อมูลผิดรหัสทั้งหมดอาจไปที่ถังขยะ)

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

อ้างอิงบางส่วนเกี่ยวกับ LOC

• กับ: LOC- วัดที่ไม่มีความหมายมากที่สุด

• เป็นกลางในบางขอบเขต: Wiki-LOC

• Pro (ฉันไม่เห็นด้วยกับส่วนใหญ่ แต่คุณสามารถดูได้): Diseconomies of Scale และ Lines of Code

คุณกำลังวัดจำนวนการทำซ้ำรหัสหรือไม่

หากผลผลิตสูงเป็นเพราะคุณมีจำนวนมากคัดลอกและวางในรหัสของคุณคุณควรกังวล

เหตุผล: ในกรณีที่มีข้อผิดพลาดในการคัดลอกและวางที่มาของคุณมันเป็นเรื่องยากและเกิดข้อผิดพลาดได้ง่ายในการแก้ไขการคัดลอกและวางทั้งหมด

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

"มันไหลหรือไม่มันดูสวยงามไหม"