ฉันจะเรียนรู้วิธีที่ถูกต้องในการใช้คุณสมบัติครึ่งหนึ่งได้อย่างไร [ปิด]

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

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

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

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

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

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

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

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

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

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

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

มีเครื่องมือสองอย่างที่ฉันคุ้นเคยที่สนับสนุนกระบวนการประเภทนี้ได้ดี หากโครงสร้างการพัฒนาของคุณนั้นง่าย git โดยใช้ git-flow จะใช้โครงสร้างกิ่งที่ดีซึ่งทำงานได้ดีในทีมขนาดเล็กถึงขนาดกลาง (อาจเป็น 20 นักพัฒนา)

สำหรับทีมพัฒนาขนาดใหญ่หรือที่จำเป็นต้องใช้กลยุทธ์การแยกย่อยที่ซับซ้อนเพื่อสนับสนุน 'สปิน' หลายผลิตภัณฑ์ของคุณ Accurrev นั้นดีที่สุด นักพัฒนาที่ไม่เกี่ยวข้องกับการจัดการการเปลี่ยนแปลงจะบ่นว่ามันยากกว่ารุ่นย่อยอื่น ๆ ... แต่มันสนับสนุนสภาพแวดล้อมการพัฒนาที่ซับซ้อน

มีสองปัญหาที่นี่: หนึ่งคือการใช้คุณสมบัติครึ่ง; อื่น ๆ ที่ทำให้ผลิตภัณฑ์การจัดส่งสินค้าทำงานในระหว่างการพัฒนาอย่างต่อเนื่อง

การใช้คุณสมบัติครึ่งหนึ่ง

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

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

ทำให้ผลิตภัณฑ์การจัดส่งทำงานได้อย่างต่อเนื่อง

มีตัวเลือกไม่กี่ตัวที่นี่:

1. ปิดคุณลักษณะ 'ปิด' ในผลิตภัณฑ์ที่จัดส่ง เพียงเพราะรหัสอยู่ในผลิตภัณฑ์ไม่ได้หมายความว่าจะต้องมีการดำเนินการหรือนำเสนอให้กับผู้ใช้ ข้อเสียคือคุณจะไม่ส่งมอบคุณค่าที่เพิ่มขึ้นให้กับผู้ใช้ของคุณและคุณจะไม่ได้รับข้อเสนอแนะ
2. เปิดเผยขอบของคุณสมบัติให้กับผู้ใช้ของคุณ แสดงสิ่งที่คุณมีและระบุสิ่งที่จะมา
3. ให้ผู้ใช้สลับไปมาระหว่างฟังก์ชั่นใหม่และเก่า บางครั้งต้องมีการบำรุงรักษาสองเส้นทางรหัสที่พร้อมสำหรับผู้ใช้ปลายทาง

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

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

โดยสอนให้พวกเขา (duh)

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

การทำรีวิวเป็นทีมจะช่วยให้ทุกคนเรียนรู้สิ่งที่คุณรู้อยู่แล้ว

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

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

ในความเป็นจริงวิธีการกำหนดค่านี้ถูกอธิบายโดย Martin Fowler เป็นFeature Toggle

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