ตัวชี้วัดซอร์สโค้ดสำหรับการวัดเสถียรภาพของโค้ด?


17

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

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

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



4
"ประการที่สองกลไกที่เป็นนามธรรมการผลิตของมันคือการออกแบบในแง่นี้โปรแกรมเหมือนบทกวี: คุณไม่สามารถเขียนบทกวีโดยไม่ต้องเขียนมัน แต่คนพูดถึงการเขียนโปรแกรมราวกับว่ามันเป็นกระบวนการผลิตและวัด" ผลผลิตโปรแกรมเมอร์ "ในแง่ของ" จำนวนบรรทัดของรหัสผลิต "ในการทำเช่นนั้นพวกเขาจองหมายเลขนั้นในด้านที่ไม่ถูกต้องของบัญชีแยกประเภท: เราควรอ้างถึง" จำนวนบรรทัดของรหัสที่ใช้ " - ผลแห่งความเข้าใจผิด Edsger W. Dijkstra
yannis

3
@ Yanis Rizos: ฉันไม่เคยแนะนำให้วัดความซับซ้อนของรหัสหรือประสิทธิภาพของ LOC เพราะฉันรู้ว่านี่ไม่ใช่วิธีที่ดี ในทางกลับกันหากรหัส 300 บรรทัดเปลี่ยนไปสองวันก่อนการจัดส่งฉันในฐานะผู้จัดการจะมีหลอดไฟ "RED ALERT" ขนาดใหญ่ในใจของฉัน (เว้นแต่จะมีการวางแผนและเป็นผลของการประเมินความเสี่ยงอย่างระมัดระวัง ) โดยทั่วไปฉันจะสมมติว่ารหัสที่ใช้ (และทดสอบ) โดยไม่มีการเปลี่ยนแปลงเป็นเวลานานคือ "มีเสถียรภาพมากขึ้น" กว่ารหัสที่มีการเปลี่ยนแปลง 100 บรรทัดทุกวัน
จอร์โจ

2
@Giorgio Argh ฉันถูกขัดจังหวะ (ตรงกลางของวันทำงานที่นี่) ขณะที่ฉันโพสต์ความคิดเห็นอื่น (กดขีด จำกัด ถ่านในอันแรก) ไม่ได้หมายความว่าคุณกำลังพูดถึงเรื่องการเพิ่มผลผลิตการเสนอราคา Dijkstra มาถึงใจและฉันคิดว่ามันน่าสนใจ ไม่ว่าในกรณีใดตัวชี้วัดการปั่นโค้ดจะค่อนข้างใกล้เคียงกับสิ่งที่คุณกำลังมองหาและมีวรรณกรรมมากมาย สำหรับเครื่องมือFishEye ของ Atlassianนั้นงดงามมาก
yannis

@ Yanis Rizos: มันเป็นเรื่องที่น่าสนใจมาก ๆ สำหรับ FishEye เราใช้ที่สถานที่ทำงานของเรา (สำหรับรีวิว) ดังนั้นฉันจะดูทันทีในคู่มือและดูสถิติที่เราสามารถผลิตได้
Giorgio

คำตอบ:


17

สิ่งหนึ่งที่ Michael Feather ได้อธิบายไว้คือ " The Active Set of Classes "

เขาวัดจำนวนชั้นเรียนที่เพิ่มเข้ากับ "ปิด" คำอธิบายการปิดชั้นเรียนเป็น:

คลาสจะปิดในวันที่ไม่มีการแก้ไขเพิ่มเติมจากวันที่จนถึงปัจจุบัน

เขาใช้มาตรการเหล่านี้เพื่อสร้างแผนภูมิเช่นนี้: แผนภูมิระดับที่ใช้งานอยู่

จำนวนที่น้อยกว่าช่องว่างระหว่างสองบรรทัดที่ดีกว่า

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


4

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

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

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

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

หากคุณกำลังใช้ git หรือ svn และรุ่น gource ของคุณคือ> = 0.39 มันง่ายเหมือนการเรียกใช้ gource ในโฟลเดอร์โครงการ


gource ดูเหมือนจะเป็นเครื่องมือที่ยอดเยี่ยมเช่นกัน! (+1)
Giorgio

1
ฉันสะดุดกับคำตอบนี้จากนั้นใช้เวลาหกชั่วโมงถัดไปเล่นกับ Gource ฉันไม่แน่ใจว่าควรได้รับ +1 หรือ -1 แต่แช่งนั่นเป็นเครื่องมือที่ยอดเยี่ยม
RonU

@RonU: คุณสามารถใช้ gource เพื่อแสดงภาพสถานะของที่เก็บในช่วงเวลาที่กำหนดเอง ประเด็นคือมันแสดงให้เห็นภาพกิจกรรมบนฐานรหัสของคุณเมื่อเวลาผ่านไป การตีความข้อมูลนั้นง่ายเพียงใดขึ้นอยู่กับปัจจัยหลายอย่างเช่นที่ฉันอธิบายไว้ในคำตอบข้างต้น ใช่มันเป็นเครื่องมือที่น่าตื่นตาตื่นใจถ้าคุณต้องการ "ภาพใหญ่" ดังนั้นผมจึงคิดว่าสมควรได้รับ +1;)
คาร์ล

ใช่เมื่อฉันพูดว่า "หกชั่วโมง" ฉันไม่ได้หมายความว่าฉันวิ่งหนึ่งซิมของ Gource ในช่วงเวลานั้น ... แค่ฉันเล่นไปพร้อมกับตัวเลือกมากมายส่งไปที่ ffmpeg อาจเพิ่มซาวด์แทร็กที่ยิ่งใหญ่ ฯลฯ ค่อนข้างเป็นโพรงกระต่าย :)
RonU

เล็มเดา เพลงประกอบคือ Harlem Shuffle;)
Carl

0

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

ตอนแรกการกระจายในช่วงเวลาของสายการแก้ไขขึ้นอยู่กับรูปแบบการจัดการซอฟต์แวร์ของโครงการ มีรูปแบบการจัดการที่แตกต่างกันมาก

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

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


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

BTW รหัสไม่เสถียรเนื่องจากผู้พัฒนาไม่ดี แต่เนื่องจากข้อกำหนดไม่ชัดเจนและโครงการยังอยู่ในช่วงการสร้างต้นแบบ
Giorgio

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

-1

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

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

ความทนทานวัดจากการทดสอบ การทดสอบหน่วยการทดสอบควันการทดสอบการถดถอยอัตโนมัติ การทดสอบการทดสอบการทดสอบ!

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

โปรดกลับมาใช้ชุดทดสอบที่เหมาะสมอีกครั้ง

ด้วยความปรารถนาดี


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

ฉันไม่ต้องการที่จะเถียงกับคุณ แต่แนะนำคุณออกไปอย่างไร้ความปราณีจากความโง่เขลาของ code metric meaninglessness ฉันอ่านคำถามของคุณอีกครั้งและตัวอย่างของคุณทั้งหมดบ่งบอกถึงความปรารถนาที่จะอนุมานความสัมพันธ์ระหว่างบรรทัดของโค้ดที่ได้รับการเปลี่ยนแปลงและความทนทานที่เกิดขึ้น ฉันเข้าใจว่ายิ่งคุณพิมพ์คำมากเท่าไหร่คุณก็ยิ่งมีโอกาสที่จะพิมพ์ผิดมากเท่านั้น แต่ฉันก็ต่อต้านหลักการในสิ่งที่คุณถามว่าฉันจะต้องออกมาอย่างยิ่งในความโปรดปรานของคุณละทิ้งการแสวงหาของคุณในลักษณะนี้ การทดสอบที่ดี = ความน่าจะเป็นที่ดีของความแข็งแกร่ง
Sassafras_wot

"การทดสอบที่ดี = ความน่าจะเป็นที่ดีของความแข็งแกร่ง": ฉันเห็นด้วยอย่างยิ่ง นั่นเป็นสาเหตุที่ฉันแนะนำว่าต้องมีการทดสอบโค้ดอีกชิ้นหนึ่งเมื่อไม่นานมานี้ก่อนที่เราจะมั่นใจได้ว่ามันถูกต้อง
Giorgio

มีคำจำกัดความของความมั่นคงหลายประการและหนึ่งในนั้นคือสิ่งที่คุณโต้เถียง มันเป็นการตีความหมายที่แตกต่างจากที่ฉันทำ ฉันเอาความมั่นคงหมายถึงว่ามันเป็น "ไม่อยู่ภายใต้การเปลี่ยนแปลงที่รุนแรง" มากกว่า "ความต้านทานต่อการเปลี่ยนแปลง"
Dave Hillier
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.