เมื่อใดที่จะยอมแพ้ความเข้ากันได้แบบย้อนหลังเนื่องจากมีการใช้งานอินเตอร์เฟสที่ได้รับการปรับปรุงใหม่ [ปิด]

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

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

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

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

• สื่อสารกับลูกค้า / ลูกค้าของคุณล่วงหน้าก่อนการเปลี่ยนแปลงใด ๆ อธิบายสาเหตุและวิธีการนำไปใช้ การอ้างถึงความปลอดภัยประสิทธิภาพเสถียรภาพและความยืดหยุ่นในอนาคตเนื่องจากเหตุผลทั้งหมดนั้นถูกต้อง
• หากคุณกำลังหยุดพักการทำความสะอาดขอความคิดเห็น
• หากมีนักพัฒนาบุคคลที่สามใด ๆ ตรวจสอบให้แน่ใจว่าคุณได้ใส่ข้อมูลของพวกเขาเช่นกันในแง่ที่เหมาะสม
• หากเป็นไปได้ให้ระบุเลเยอร์ความเข้ากันได้
• ให้คำแนะนำการอัพเกรดที่ครอบคลุม
• ทำการอัพเกรดง่ายและไม่เจ็บปวดที่สุด ลดความเจ็บปวดของผู้ใช้ให้น้อยที่สุดแม้ว่ามันจะช่วยให้คุณทำงานได้มากขึ้นก็ตาม
• หากคุณคิดค่าใช้จ่ายให้ส่วนลดสำหรับการอัปเกรดเป็นเวอร์ชันใหม่
• เพิ่มคุณสมบัติใหม่และมีประโยชน์อย่างน้อยสองสามอย่างในเวอร์ชันใหม่เพื่อกระตุ้นการอัพเกรด สิ่งนี้มีความสำคัญอย่างยิ่งในการทำให้การอัพเกรดน่าสนใจยิ่งขึ้นสำหรับผู้จัดการ
• หากคุณหยุดพักทำให้เป็นครั้งสุดท้ายที่คุณต้องการ นั่นหมายถึงการวางแผนที่ครอบคลุมล่วงหน้าและทำให้แน่ใจว่าทุกอย่างถูกต้อง
• หากคุณมี UI ให้ทำการเปลี่ยนแปลงได้ง่าย คิดว่ารีเฟรชมากกว่าออกแบบใหม่ สำหรับผู้ใช้ที่ไม่ใช่ด้านเทคนิคการเปลี่ยนแปลง UI อย่างมากจากรุ่นหนึ่งเป็นรุ่นอื่นอาจเป็นสาเหตุใหญ่ที่ทำให้เกิดความหงุดหงิด
• เวอร์ชั่นใหม่ของคุณควรมีความเสถียรและมีประสิทธิภาพมากกว่ารุ่นเก่าอย่างเห็นได้ชัด อย่าให้ผู้ใช้ของคุณมีเหตุผลในการส่งการอัปเกรดอีกครั้ง อย่าปล่อยรุ่นใหม่โดยไม่ทำการทดสอบอย่างละเอียดล่วงหน้า (การทดสอบหน่วยการรวมและการทดสอบเบต้า)
• บำรุงรักษาเวอร์ชั่นเก่าพร้อมกันเป็นระยะเวลานาน หากคุณตัดสินใจที่จะเลิกใช้และยุติการสนับสนุนโปรดแจ้งล่วงหน้าอย่างน้อย 6-12 เดือนหากคุณสามารถทำได้
• คุณสามารถที่จะรักษาสองรุ่นพร้อมกันทั้งในแง่ของการเงินและกำลังคนได้หรือไม่? (นอกจากนี้จากมุมมองทางธุรกิจคุณไม่ควรหยุดการสนับสนุนเวอร์ชันเก่าจนกว่าคุณจะสามารถสูญเสียลูกค้าที่เหลือซึ่งติดอยู่กับเวอร์ชันเก่าและไม่ต้องการอัปเกรดจุดนั้นควรอยู่ที่ค่าใช้จ่ายของ รักษาผลกำไรของคุณให้สูงกว่าที่ควรเป็น)
• ให้คำมั่นที่จะทำการปรับปรุงความปลอดภัยเป็นระยะเวลาหนึ่งหลังจากที่เวอร์ชั่นเก่าถูกยกเลิกหากจำเป็น
• การสื่อสารมีขนาดใหญ่ตลอดกระบวนการ อย่าปล่อยให้ผู้ใช้ / ลูกค้า / ลูกค้าของคุณรู้สึกถูกทอดทิ้งในทุกจุด ความภักดีและความหลงใหลของพวกเขาคือรากฐานของธุรกิจของคุณ ตรวจสอบให้แน่ใจว่าคุณตอบคำถามในบล็อกหรือในฟอรัมของคุณ ไม่ควรประเมินปัจจัยทางสังคมต่ำเกินไป

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

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

โดยทั่วไปฉันเห็นด้วยกับ James Anderson จากประสบการณ์ของฉันมีแง่มุมเพิ่มเติมที่อาจรับประกันการพิจารณาและอาจชี้ไปที่ตัวเลือกที่อนุญาตให้มีการพัฒนาอินเทอร์เฟซ

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

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

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

อินเทอร์เฟซเก่าที่เป็นรูปธรรมในกรณีนี้คือเทคโนโลยีเฉพาะแพลตฟอร์มที่อยู่ในกระบวนการของการค่อยๆถูกแทนที่ด้วยส่วนต่อประสานบริการตามเทคโนโลยีกระแสหลักมาตรฐาน

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

อย่างไรก็ตามโปรดทราบว่าวิธีการนี้อาจใช้ไม่ได้กับสถานการณ์ของคุณ แน่นอนว่ามันใช้งานได้กับทีมที่ฉันทำงานด้วย

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

http://www.joelonsoftware.com/items/2008/03/17.html

คำตอบสั้น ๆ คือ Never!

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

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

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

แก้ไขเพื่อชี้แจงเพิ่มเติมนี้

สิ่งที่คุณคิดว่าโปรแกรมเมอร์คือ -

"ฉันจะปรับปรุง API นี้และทำให้ระบบดีที่สุดเท่าที่จะเป็นไปได้และทุกคนจะชื่นชมฉัน"

ผู้ใช้ API ของคุณจะคิดอย่างไร -

"A * * * e เขาคิดว่าเวลาและตารางงานของฉันไม่สำคัญฉันต้องหยุดสิ่งที่ฉันกำลังทำและ refactor รหัสทั้งหมดของฉันโดยไม่มีเหตุผลอื่นนอกจากเพื่อตอบสนองอัตตาของเขาถ้าฉันต้อง refactor แล้วฉันจะเปลี่ยน ไปที่ API อื่นเพื่อให้ติดกับเขา "

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

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

ขณะนี้เรากำลังอัปเกรดระบบบัญชีของเรา บริษัท ที่ทำการอัปเกรดยังรองรับเวอร์ชันที่เข้ากันไม่ได้ก่อนหน้านี้ พวกเขาวางแผนที่จะใช้ข้อมูลและย้ายไปยังระบบใหม่เพื่อให้ (ในทางทฤษฎี) ข้อมูลเก่าทั้งหมดจะอยู่ที่นั่น เราจะจ่ายเงินสองสามร้อยปอนด์สำหรับการแปลงข้อมูล ไม่มีปัญหา.

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

คุณทำงานอย่างหนักเพื่อให้ได้ลูกค้าและรักษาลูกค้าไว้คุณจะช่วยให้ช่วงการเปลี่ยนภาพเป็นอย่างไร