การเป็นเจ้าของคุณลักษณะเป็นการปฏิบัติที่ดีหรือไม่?

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

สำหรับบันทึกเราใช้ SCRUM ภายใน SAFe และเรามีนักพัฒนาเต็มเวลาต่อทีมแบ่งปัน QA และเจ้าของผลิตภัณฑ์ระหว่างสองทีมของเรา (Android และ iOS)

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

การตรวจสอบรหัสจะเสียค่า
แบ่งปันความรู้น้อยที่สุด
การเพิ่มความเสี่ยง
การสูญเสียความยืดหยุ่นของทีม

ฉันถูกหรือว่าไม่ใช่การปฏิบัติที่ไม่ดีเลย?

agile team code-ownership

— mdelolmo
แหล่งที่มา

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

— Ixrec

"ผู้พัฒนารายหนึ่งควรมุ่งเน้น (และมีเพียงคนเดียวเท่านั้น) " - หากคุณต้องการ SPOF เป็นความคิดที่ดีที่จะทำเช่นนั้น เมื่อเร็ว ๆ นี้ฉันได้กำหนดทฤษฎีเชิงประจักษ์เพื่อให้บุคคลที่คุณต้องการมากที่สุดในสถานการณ์บางอย่าง (" wtf?! " ทำไมเขาถึงเขียนอย่างนั้น? ") โดยทั่วไปแล้วเป็นสิ่งที่ไม่สามารถเข้าถึงได้จริง ๆ

— JensG

@ JensG: meh ฉันมีทฤษฎีเชิงประจักษ์ที่คนที่ฉันต้องการบ่อยที่สุด ("wtf? ทำไมเขาถึงเขียนแบบนั้น?") คือฉันและเป็นปัจจัยรถประจำทางสำหรับ "การจดจำสิ่งที่ควรได้รับการเขียนลง ในเวลานั้น" เป็น 0 มันเป็นเพียงที่โดดเด่นมากขึ้นเมื่อฉันโดนคนอื่นเพราะผมไม่สบายใจเกี่ยวกับมันแทนการตรวจสอบรหัสที่มีอยู่จากรอยขีดข่วนบนประโยชน์ของตัวเอง ;-)

— สตีฟเจสซอพ

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

— JensG

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

— Steve Jessop

คำตอบ:

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

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

— เจสันเค
แหล่งที่มา

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

— JensG

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

— Steve Jessop

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

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

ดังนั้นการกลั่นกรองบางอย่างอาจจะทำให้สิ่งนี้หลุดพ้นจากความคิดที่ไม่ดี

— Telastyn
แหล่งที่มา

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

— Jason K.

@ Jason - แน่นอนว่าควรมีบางคนในทีมที่สะดวกสบายและสามารถทำงานกับโค้ดได้ แต่คน ๆ หนึ่งจะจบลงที่ผู้เชี่ยวชาญในเรื่องที่ทำได้ง่ายที่สุด

— Telastyn

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

— เจสัน K .