การเป็นเจ้าของรหัสบุคคลนั้นสำคัญหรือไม่ [ปิด]

ฉันอยู่ท่ามกลางการโต้เถียงกับเพื่อนร่วมงานบางคนว่าการเป็นเจ้าของทีมของ codebase ทั้งหมดนั้นดีกว่าการเป็นเจ้าของส่วนประกอบของมันหรือไม่

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

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

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

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

แต่เมื่อแนะนำสิ่งนี้กับเพื่อนร่วมงานของฉันฉันได้รับการผลักกลับมามากมายแน่นอนกว่าที่ฉันคาดไว้มาก

ดังนั้นฉันจึงถามชุมชน: คุณมีความคิดเห็นอย่างไรกับการทำงานกับทีมใน codebase ขนาดใหญ่? มีบางอย่างที่ฉันขาดหายไปเกี่ยวกับการรักษาความเป็นเจ้าของร่วมอย่างระมัดระวังหรือไม่?

ฉันเชื่อว่าการเป็นเจ้าของทีมมีประโยชน์มากกว่าในระยะยาว

คุณเพียงแค่ต้องดูที่ 2 สถานการณ์ต่อไปนี้เพื่อทำความเข้าใจว่าทำไมการมุ่งเน้นความรู้ในจำนวนผู้คนขั้นต่ำจึงไม่เหมาะอย่างยิ่ง:

• สมาชิกในทีมพบอุบัติเหตุที่โชคร้าย
• สมาชิกในทีมพบโอกาสการจ้างงานที่ดีขึ้น

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

เพียงเพราะคุณไม่มีความเป็นเจ้าของส่วนของโค้ดเนื่องจากคุณเขียนมันไม่ได้หมายความว่าคุณจะยังไม่ได้มีลักษณะของ "ความภาคภูมิใจในการสร้างสรรค์ของคุณ" ฯลฯ ฉันไม่เชื่อว่าการเป็นเจ้าของทีมจะยิ่งใหญ่ ลดความรู้สึกส่วนตัวของการเป็นเจ้าของรหัสที่เป็นลายลักษณ์อักษร

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

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

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

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

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

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

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

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

เหตุผลสำหรับสิ่งนี้คือการที่ถ้ามันเป็นความรับผิดชอบของทุกคนมันก็ไม่รับผิดชอบ

ฉันขอแนะนำให้เจ้าของทีมเป็นรายบุคคลด้วยเหตุผลดังต่อไปนี้:

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

ความเชี่ยวชาญเป็นสิ่งที่ดี - สำหรับโค้ดเบสขนาดใหญ่ซึ่งในระยะยาวอาจช่วยประหยัดเวลาในการสื่อสารบ้าง แต่ความเป็นเจ้าของไม่ใช่

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

ฉันต้องไม่เห็นด้วยกับคุณ: ความเป็นเจ้าของทีมของ codebase เป็นตัวเลือกที่ดีกว่าความเป็นเจ้าของส่วนบุคคล

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

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

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

ฉันคิดว่าคุณต้องการทั้งคู่เพราะมีความตึงเครียดระหว่างทั้งสองวิธี

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

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

ฉันคิดว่าการเป็นเจ้าของรหัสแบบรวมดีกว่าการเป็นเจ้าของรหัสส่วนบุคคลอย่างไม่มีใครเทียบ

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

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

ฉันพูดแบบนี้โดยอาศัยประสบการณ์ในโครงการปัจจุบันของฉัน เรามุ่งมั่นที่จะฝึกความเป็นเจ้าของร่วมกัน แต่มีบางส่วนของระบบที่มีความเชี่ยวชาญ - ฉันและอีกคนเป็นเจ้าของระบบสร้างตัวอย่างเช่นมีคนที่ทำงานส่วนใหญ่เกี่ยวกับฟีดข้อมูลขาเข้า อีกคนกำลังทำงานเกี่ยวกับการนำเข้ารูปภาพและอื่น ๆ ในหลายพื้นที่ (โดยเฉพาะอย่างยิ่งฉันต้องสารภาพในพื้นที่ของฉัน!) คุณภาพของรหัสได้รับความเดือดร้อนอย่างจริงจัง - มีข้อผิดพลาดความเข้าใจผิด kludges และแฮ็กที่จะไม่อยู่รอดได้รับความสนใจจากคนอื่น ๆ ในทีม

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

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

ตัวอย่างเช่นเรามีผู้ชายสองคนในทีมของเราที่สร้างหน้าเว็บการดูแลระบบสำหรับผลิตภัณฑ์เซิร์ฟเวอร์ของเรา เราสร้างสคริปต์ฝั่งเซิร์ฟเวอร์แบบกำหนดเองเพื่อให้เราสามารถเรียกใช้ฟังก์ชัน C บนเซิร์ฟเวอร์ได้จากสคริปต์ java หรือ html ของเรา ฉันคิดว่ามันสำคัญกว่าที่คน "เว็บ" ของเราเข้าใจวิธีการใช้เครื่องมือนี้เมื่อเทียบกับการเป็นเจ้าของร่วมของแอปพลิเคชันหน้าเว็บแต่ละหน้า

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

คิดว่าความรับผิดชอบมากขึ้นและความเป็นเจ้าของน้อยลง ท้ายที่สุดผู้ที่เขียนเช็คก็เป็นเจ้าของจริงอยู่ดี

จิมฉันอยู่กับคุณ 100% ฉันอยู่ท่ามกลางการต่อสู้เดียวกันในสถานที่ทำงานของฉัน - ซึ่งเป็นเหตุผลที่ฉันสะดุดคำถามของคุณ

วิธีที่ฉันเห็นคือ: "เมื่อทุกคนเป็นเจ้าของมันไม่มีใครเป็นเจ้าของ"

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

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

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

สำหรับฉันมันขึ้นอยู่กับพลวัตของทีมของคุณ

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

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

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

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

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

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