กำลังมองหาวิธีที่ดีกว่าในการรวมการปรับโครงสร้างเชิงลึกเข้ากับการพัฒนาตามคุณลักษณะ


9

คำชี้แจงปัญหา:

ได้รับ:

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

ปัญหา:

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

เราได้ลอง:

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


สิ่งที่เราได้รับคำแนะนำ:

ลิงก์ไปยังบทความ (pdf)
สร้างสาขาเพิ่มเติมสำหรับการเปลี่ยนโครงสร้าง (RB) เป็นระยะให้ตรงกันกับ MB ผ่านการผสานจาก MB ไปยัง RB หลังจาก RB มีความเสถียรเราจะเปลี่ยนต้นแบบเป็น RB และสร้างสาขาใหม่สำหรับการปรับโครงสร้างเพิ่มเติม นี่คือแผน แต่ที่นี่ฉันคาดหวังว่านรกที่แท้จริงของการรวม MB กับ RB หลังจากรวม FB เข้ากับ MB

ข้อได้เปรียบหลัก: ผู้เชี่ยวชาญที่มีเสถียรภาพส่วนใหญ่เวลา

มีทางเลือกใดที่ดีกว่าในการใช้ผลิตภัณฑ์นี้?


1
การปรับปรุงที่เป็นไปได้ (แทนที่จะเป็นทางเลือก) ให้กับกระบวนการที่คุณเสนอ: เครื่องมือผสาน TFS นั้นค่อนข้างยากเมื่อเทียบกับยูทิลิตี้กระจายทางเลือกต่างๆ หากคุณยังไม่ได้ทำเช่นนั้นคุณอาจพบว่าการผสานด้วยตนเองนั้นมีความเจ็บปวดน้อยลงหากคุณกำหนดค่าไคลเอนต์ TFS ให้ใช้ยูทิลิตี้ nicer diff แทนเครื่องมือในตัว คุณอาจพบว่าเครื่องมืออรรถประโยชน์ TFS Power Tools ของ Microsoft เป็นประโยชน์ มันให้ความสามารถในการเรียกใช้ความแตกต่างระหว่างเซ็ตการแก้ไขหรือสาขามากกว่าระหว่างแต่ละไฟล์
Brian

คำตอบ:


1

ฉันมีสถานการณ์ที่คล้ายกันในอดีต ฉันทำอะไรลงไป:

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

  • ในขั้นตอนของการรวม 2 โซลูชัน (ทำให้สถาปัตยกรรม + คุณสมบัตินำมาใช้ใหม่จากโครงการเก่า) มีเพียงสิ่งเดียวที่ถูกปล่อยออกมา (คุณสมบัติใหม่) ที่ทำกับผลิตภัณฑ์เก่า อย่างไรก็ตามรุ่นใหม่มีเพียงการแก้ไขข้อบกพร่องที่สำคัญ มีการเผยแพร่น้อยมากในผลิตภัณฑ์เก่า ดังนั้นสิ่งที่เปลี่ยนแปลงจึงถูกรวมเข้ากับโซลูชันใหม่ได้อย่างง่ายดาย

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.