ฉันต้องรับผิดชอบรหัสมากน้อยเพียงใด

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

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

มีทรัพยากรใดที่ฉันสามารถใช้เพื่อช่วยฉันในการวัดภาระงานของฉันอย่างแม่นยำมากกว่าการนับจำนวนบรรทัดโค้ด

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

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

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

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

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

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

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

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

การวัดความคืบหน้าการเขียนโปรแกรมด้วยบรรทัดของรหัสเป็นเหมือนการวัดความก้าวหน้าของการสร้างอากาศยานด้วยน้ำหนัก - Bill Gates

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

ตัวอย่างเช่นหาก Facebook มีโปรแกรมเมอร์ 2 คนพวกเขาจะทำงานหนักเกินไปอย่างเห็นได้ชัด แต่คุณจะได้ข้อสรุปอย่างไร นั่นคือประเภทของคำถามที่ฉันจะทำ

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

1. คุณทำงานกี่ชั่วโมง
2. คุณควรทำงานกี่ชั่วโมง
3. เป็นไปตามกำหนดเวลาหรือไม่?

จากนั้นทำตามตรรกะนี้:

• ถ้า 1> 2 คุณต้องการคนมากหรือน้อยกว่ากำหนดเวลาก้าวร้าว
• ถ้า 1 <2 คุณต้องการคนน้อยลงหรือมีความคิดริเริ่มมากขึ้น
• หากไม่พบกำหนดเวลาและ 1> = 2 คุณต้องการคนเพิ่ม
• หากไม่พบกำหนดเวลาและ 1 <2 คุณควรไปหาคนอื่น

นี่คือการอนุมานที่มีข้อบกพร่องสองข้อที่เห็นได้ชัด

• ผู้คนไม่ได้สร้างขึ้นอย่างเท่าเทียมกัน
• มีวิธีที่จะทำให้ผู้คนได้รับผลผลิตมากขึ้น (อัพเกรดคอมพิวเตอร์หรืออะไรบางอย่าง)

แต่คุณได้รับความคิด