นานแค่ไหนที่จะรอก่อนที่จะลบวิธีการเลิก? [ปิด]

ฉันกำลังรักษา API สาธารณะและต้องเลิกใช้วิธีการ

มีกฎทั่วไปเกี่ยวกับจำนวนเดือน / ปี / รุ่นก่อนการลบฉันควรคัดค้านวิธีการหรือไม่?

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

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

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

ตามหลักการแล้ว API ของคุณจะใช้semverเพื่อให้การเปลี่ยนแปลงใด ๆ ทำให้หมายเลขเวอร์ชันหลักเพิ่มขึ้น ในทางปฏิบัติมันเป็นที่พึงปรารถนาที่จะทำเช่นนี้แทบจะไม่เคย หาก API ของคุณได้รับการติดตั้งผ่านตัวจัดการแพคเกจบางอย่างคุณอาจต้องการสร้างชื่อแพ็กเกจใหม่หลังจากการเปลี่ยนแปลงที่ไม่สมบูรณ์เพื่อให้การอัปเกรดแบบง่ายไม่ทำให้เกิดข้อขัดแย้ง (เช่นmyapi2 v2.123.4vs myapi3 v3.2.1) อาจไม่จำเป็นหากผู้จัดการแพคเกจของคุณรองรับการพึ่งพาเวอร์ชันที่เข้มงวดมากขึ้น (เช่นข้อกำหนดการพึ่งพาเช่น~v2.120ที่ไม่รวมv3.*) แต่ชื่อแพคเกจที่แตกต่างกันมีข้อได้เปรียบที่รุ่นที่เข้ากันไม่ได้สามารถใช้งานร่วมกันได้อย่างง่ายดาย แม้เมื่อใช้ semver ก็สามารถมีเหตุผลที่จะมีช่วงเวลาการคัดค้าน

Semver อาจไม่สามารถใช้ได้เสมอไป จากนั้นการสื่อสารนโยบายความมั่นคงที่ชัดเจนก็สำคัญกว่า ตัวอย่างเช่น:

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

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

นอกเหนือจากการทำเครื่องหมายส่วนต่าง ๆ ของ API ว่าเลิกใช้แล้วคุณควรทำให้เลิกใช้อย่างกว้างขวาง ตัวอย่างเช่น:

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

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

เป็นการดีที่คุณต้องการรอจนกว่าจะไม่มีใครใช้วิธีที่เลิกใช้แล้วอีกต่อไป เมื่อพิจารณาว่าคุณใช้ API สาธารณะมันเป็นเรื่องง่ายที่จะติดตาม แต่คุณอาจต้องรอเป็นเวลานาน

ในปี 2558 Google มีปัญหาคล้ายกันกับ stlport API บนระบบปฏิบัติการ Android พวกเขาเลิกใช้แล้วและต้องการลบ แต่แอปจำนวนมากยังคงใช้งานอยู่ พวกเขาพบทางออกที่ฉลาด:

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

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

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

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

ฉันขอแนะนำให้คุณลบวิธีการที่ไม่สนับสนุนเมื่อคุณได้รับบางอย่างจากการลบ :

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

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

ก่อนอื่นคุณควรพิจารณาว่าคุณต้องการเลิกใช้แล้วหรือล้าสมัย

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

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

คำตอบนั้นขึ้นอยู่กับบริการที่คุณให้กับลูกค้าของคุณ

ปลายด้านหนึ่งของสุดโต่งมีข้อผิดพลาดใน Windows.h จากยุค Win 3.1 ที่แพร่กระจายเป็นเวลาสองทศวรรษเพราะ Microsoft เชื่อมั่นในความเข้ากันได้ย้อนหลังอย่างมาก

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

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

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

ฉันกำลังรักษา API สาธารณะและต้องเลิกใช้วิธีการ

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

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

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

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

(สัญลักษณ์แสดงหัวข้อย่อยที่สองที่สองได้รับการคุ้มครองอย่างดีในคำตอบอื่น ๆ แต่ฉันคิดว่าคนแรกเป็นเรื่องใหม่)

สำหรับโครงการสาธารณะให้ลบออกเฉพาะเมื่อคุณต้องการเท่านั้น

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

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

deprecation != eventual_removal. หาก API เป็นอันตรายคุณจะลบออก หากเป็นรุ่นเก่าให้ทิ้งไว้และบันทึกการแทนที่ไว้