คำถามติดแท็ก metrics

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

57 management  metrics 

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

55 productivity  metrics 

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

45 language-agnostic  quality  metrics 

ฉันใหม่สำหรับการวิเคราะห์โค้ดแบบสแตติก แอปพลิเคชันของฉันมีความซับซ้อนตามวัฏจักร 17,754 แอปพลิเคชันนั้นมีรหัสเพียง 37,672 บรรทัด มันถูกต้องหรือไม่ที่จะบอกว่าความซับซ้อนนั้นสูงตามบรรทัดของโค้ด? อะไรคือความซับซ้อนของวงจรที่บอกกับฉัน?

42 metrics  cyclomatic-complexity 

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

33 code-quality  metrics 

ฉันค่อนข้างใหม่สำหรับวิธีการ TDD และการทดลองครั้งแรกของฉันบอกว่าการเขียนโค้ดฟังก์ชัน 1 บรรทัดหมายถึงการเขียนโค้ดทดสอบประมาณ 2-3 บรรทัด ดังนั้นในกรณีที่ฉันจะเขียน 1,000 LOC, codebase ทั้งหมดรวมถึงการทดสอบจะเป็นอะไรที่เหมือน ~ 3500 LOC นี่ถือว่าเป็นเรื่องปกติหรือไม่ อัตราส่วนในโค้ดที่คุณเขียนคือเท่าใด

27 testing  unit-testing  tdd  metrics 

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

27 project-management  productivity  metrics 

คุณจะตัดสินอย่างเป็นกลางเมื่อเวลาผ่านไปว่าคุณจะพัฒนาโค้ดได้ดีขึ้นอย่างไร? ตัวอย่างเช่นฉันอาจนั่งที่นี่และรู้สึกว่า "ฉันรู้<language>แล้วและฉันใช้<technique>ตอนนี้ดังนั้นฉันต้องดีขึ้นกว่านี้" แต่นี่ไม่ได้อธิบายถึงอคติของฉันเองหรือความจริงที่ว่าฉันอาจเริ่มดีขึ้นในอัตราที่ช้ากว่าที่ตั้งใจไว้หรือฉันอาจดูด<technique>และไม่เข้าใจ มีวิธีใดบ้างสำหรับคนที่จะประเมินความสามารถของตนเองอย่างเป็นกลาง ? จะเปรียบเทียบพวกเขากับกลุ่มเพื่อนของพวกเขาอย่างเป็นกลางได้อย่างไร

27 self-improvement  skills  metrics 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ประเภทของความซับซ้อนตามวัฏจักรคืออะไร? ตัวอย่างเช่น: 1-5: บำรุงรักษาง่าย 6-10: ยาก 11-15: ยากมาก 20+: ใกล้จะเป็นไปไม่ได้ เป็นเวลาหลายปีแล้วที่ฉันได้ไปโดยมีข้อสันนิษฐานว่า 10 ข้อ จำกัด และสิ่งอื่น ๆ นอกเหนือจากนั้นไม่ดี ฉันกำลังวิเคราะห์วิธีแก้ปัญหาและฉันพยายามกำหนดคุณภาพของรหัส ความซับซ้อนตามวัฏจักรแน่นอนไม่ได้วัดเพียง แต่มันสามารถช่วย มีวิธีการที่มีความซับซ้อนของวงจร 200+ ฉันรู้ว่ามันแย่มาก แต่ฉันอยากรู้เกี่ยวกับช่วงล่างเช่นในตัวอย่างด้านบน ฉันพบสิ่งนี้ : ค่าอ้างอิงดังกล่าวจาก Carnegie Mellon กำหนดช่วงคร่าวๆสี่ค่าสำหรับค่าความซับซ้อนของวงจร: วิธีการระหว่าง 1 ถึง 10 ถือว่าง่ายและเข้าใจง่าย ค่าระหว่าง 10 ถึง 20 แสดงถึงรหัสที่ซับซ้อนกว่าซึ่งอาจยังเข้าใจได้ อย่างไรก็ตามการทดสอบจะยากขึ้นเนื่องจากจำนวนสาขาที่เป็นไปได้มากขึ้นที่รหัสสามารถทำได้ ค่า 20 …

26 design  programming-practices  metrics 

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

25 testing  metrics 

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

23 c#  visual-studio-2010  metrics  maintainability  measurement 

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

21 scalability  metrics 

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

18 complexity  metrics  static-analysis  code-metrics 

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

18 code-quality  metrics 

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

17 metrics