Bus Number – ปลั๊กอิน GitHub ที่เพื่อนร่วมงานขอร้องว่าอย่าเขียน

 (scannedinavian.com)
1 คะแนน โดย GN⁺ 2024-11-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

Bus Factor คืออะไร?

  • Bus Factor คือดัชนีที่บอกว่าต้องมีสมาชิกในทีมกี่คนที่หายไปอย่างกะทันหัน จึงจะทำให้โปรเจกต์ล่าช้า
  • ในปี 2015 เมื่อผู้มีส่วนร่วมในโค้ดเบสที่สร้างรายได้เพียงแห่งเดียวของบริษัทถูกเลิกจ้าง จึงตัดสินใจเขียนปลั๊กอิน GitHub เพื่อคำนวณสิ่งนี้

กระบวนการพัฒนาปลั๊กอิน

  • เริ่มพัฒนาปลั๊กอินโดยอ้างอิงจากงานวิจัยเรื่อง Truck Factor
  • เพื่อนร่วมงานกังวลว่าปลั๊กอินนี้อาจถูกผู้บริหารใช้เป็นเครื่องมือคำนวณว่าควรไล่ใครออกได้ง่าย ๆ

ความพยายามในการทำซ้ำผลลัพธ์

  • พยายามทำซ้ำผลลัพธ์โดยใช้ GitHub repository ที่ให้มาในงานวิจัย
  • ข้อมูลถูกให้มาในรูปแบบ JSON และสามารถทำ visualization ได้ผ่าน CSV
  • คำแนะนำใน README ทำงานได้ไม่ถูกต้อง จึงใช้เวลาแก้ปัญหาอยู่พักหนึ่ง

การใช้ GNU Parallel

  • ใช้ GNU Parallel เพื่อโคลน GitHub repository หลายแห่งพร้อมกัน
  • แม้จะตั้งให้ใช้เพียง 8 โปรเซส แต่ทุกคอร์ก็ถูกใช้งานจนเต็ม

Ruby Gems และ NixOS

  • พบความยากลำบากในการติดตั้งปลั๊กอิน Linguist
  • กำลังหาวิธีติดตั้ง Ruby Gems บน NixOS

การคำนวณผลลัพธ์ใหม่

  • ฟอร์ก repository ต้นฉบับ แล้วคอมไพล์ซอร์ส Java เพื่อคำนวณผลลัพธ์ใหม่
  • ตัวอย่างผลลัพธ์ของ repository Linux kernel: Truck Factor 12, coverage 49.98%

ปัญหาและการวิจัยเพิ่มเติม

  • กระบวนการคำนวณไม่ได้พิจารณา process การรีวิว
  • จำเป็นต้องตรวจสอบว่าทำไม Truck Factor ของ Linux kernel จึงต่างจากเมื่อ 10 ปีก่อนอย่างมาก
  • มีแผนจะตรวจสอบคำอ้างอิงของงานวิจัยเพื่อหาวิธีคำนวณที่ดีกว่า

บทสรุป - ความสำคัญของ Bus Factor

  • ในงานวิจัยปี 2015 ประเมิน Truck Factor ของ Linux kernel ไว้ที่ 90 แต่ปัจจุบันคำนวณได้ 12
  • นี่ไม่ได้หมายถึงการปรับปรุงที่ดีขึ้น
  • สามารถดู visualization เพิ่มเติมและรายละเอียดอื่น ๆ ได้ที่บล็อกของ mclare

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-11-13
ความคิดเห็นจาก Hacker News

  • หนึ่งในความสามารถของ CodeScene คือการระบุส่วนที่มีการกระจายความรู้ต่ำในบริเวณที่โค้ดมีการเปลี่ยนแปลงบ่อย เพื่อค้นหาจุดเสี่ยงสูง

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

  • Amazon มีความสามารถที่ช่วยให้มองเห็นกิจกรรมของทีมและปัจจัยเสี่ยงได้ง่าย ผ่านรายงานเกี่ยวกับระบบโค้ด

    • 'bus factor' เป็นตัวชี้วัดที่แสดงว่าทีมจะได้รับผลกระทบมากแค่ไหนหากสมาชิกบางคนไม่อยู่
    • นักพัฒนาอาจคิดว่าความรู้เฉพาะเกี่ยวกับระบบหนึ่งช่วยรับประกันความมั่นคงในงานของตนได้ แต่สิ่งนี้ก็อาจมองได้ว่าเป็นความเสี่ยงทางเทคนิค

  • เหตุผลที่ GNU Parallel ใช้ทุกคอร์ก็เพราะ git clone แต่ละครั้งสร้างเธรด index-pack หลายตัว

    • การตั้งค่า pack.threads เป็น 1 อาจช่วยได้

  • 'bus factor' แสดงถึงความเป็นอิสระและความโปร่งใสของทีม และในสภาวะอุดมคติ สมาชิกทุกคนควรเข้าใจทุกอย่างได้

    • bus factor เท่ากับ 0 หมายความว่าสมาชิกในทีมสามารถแทนที่บทบาทกันได้ ซึ่งสะท้อนถึงความเรียบง่ายของซอฟต์แวร์
    • การประเมินคนจากอีเมล คอมมิต PR หรือจำนวนบรรทัดโค้ด เป็นวิธีที่ผิด

  • มีความเข้าใจผิดว่าเมื่ออาชีพก้าวหน้าขึ้น นักพัฒนาควรโฟกัสที่การรีวิวมากกว่าการเขียนโค้ด

    • ไม่อยากเปลี่ยนนักพัฒนาที่ยอดเยี่ยมให้กลายเป็นผู้จัดการธรรมดา

  • ผู้เขียนของระบบถูกนิยามว่าเป็นผู้ใช้ที่มีส่วนร่วมสำคัญกับไฟล์นั้น และหากผู้เขียนครอบคลุมทั้งไฟล์น้อยกว่า 50% ระบบอาจเผชิญความล่าช้ารุนแรง

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

  • ในซอฟต์แวร์องค์กรบางตัว อาจมีแดชบอร์ดที่วัดปริมาณการส่งและรับอีเมล

    • การทำอะไรเป็นงานอดิเรกที่เพื่อนร่วมงานคัดค้าน อาจดูเป็นพฤติกรรมที่ไม่ดี

  • CPAN ติดตาม bus factor มานานแล้ว เช่น Moose มี bus factor เท่ากับ 5

  • มีการใช้คำว่า 'lottery factor' เพื่อสื่อว่า ต่อให้ใครบางคนถูกรางวัลลอตเตอรี่แล้วลาออกไป โครงการก็ยังเดินหน้าต่อได้