วิธีการจัดการข้อบกพร่องที่ผู้ใช้คิดว่าเป็นคุณสมบัติ?


15

คำถาม :

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

การทำอย่างละเอียด :

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

ในทางทฤษฎีเนื่องจากนี่เป็นการแก้ไขบั๊กเล็กน้อยจึงสามารถมีคุณสมบัติเป็น PATCH โดยพิจารณาจากการกำหนดเวอร์ชันแบบ semantic: xyZ อย่างไรก็ตามเนื่องจากความเข้ากันได้แบบย้อนกลับ มันจะยังคงมีคุณสมบัติเป็นแพทช์ (เพราะมันไม่ได้มีวัตถุประสงค์เพื่อเป็นคุณสมบัติ) ตราบใดที่มันเป็นเอกสาร?

แก้ไข: ในกรณีเฉพาะนี้มันเป็นข้อผิดพลาดใน API ของห้องสมุดที่ใช้ภายในที่นักพัฒนาอื่นใช้


8
คุณสมบัติข้อบกพร่องทั้งหมดไม่ใช่เหรอ ;)
Lawrence Aiello

2
ระบุสวิตช์ในเวอร์ชันใหม่ที่ปิดโดยค่าเริ่มต้นและเมื่อเปิดใช้จะเลียนแบบพฤติกรรมแบบเดิมหรือไม่ เกิดขึ้นทุกครั้ง ไม่มีข่าว, ไปต่อ
rwong


บางครั้งคุณสมบัติไม่มีอะไรมากกว่าข้อบกพร่องตามที่อธิบายไว้โดยฝ่ายการตลาด
Dan Pichelman

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

คำตอบ:


7

ฉันคาดเดาว่าหากมีผู้ใช้จำนวนมากคาดหวังว่ามันจะเป็นฟีเจอร์มันควรจะอยู่ที่ "ไม่ได้ผสม" หรือ "คงที่" เพื่อให้มีเสถียรภาพมากขึ้นหรือไม่

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

เป็นการยากที่จะตอบคำถามนี้โดยสรุปเพราะทุกสถานการณ์จะแตกต่างกัน

ในกรณีเฉพาะนี้เป็นข้อผิดพลาดใน API ของไลบรารีที่ใช้ภายในที่นักพัฒนารายอื่นใช้

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

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

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


10

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

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


3
คุณสมบัติของกฎหมาย
Deduplicator

2
อีกตัวอย่างวิดีโอเกมที่ยอดเยี่ยมคือความสามารถในการยกเลิกการย้ายไปสู่การเคลื่อนไหวอื่นใน Street Fighter รุ่นเก่า ( en.wikipedia.org/wiki/… ) เดิมทีมันเป็นบั๊กมันได้กลายเป็น "ฟีเจอร์"
Michael

8

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

  1. สร้างโคลนของฟังก์ชันไลบรารีที่ผิดพลาด ในหลายกรณีผู้คนเพียงต่อท้าย2ชื่อฟังก์ชั่นในกรณีเหล่านี้ แต่ถ้าคุณมีการเปลี่ยนแปลงอื่น ๆ ที่คุณต้องการนำไปใช้กับอินเทอร์เฟซของฟังก์ชันนั้นคุณอาจให้ชื่อที่แตกต่างกันโดยสิ้นเชิง

  2. แก้ไขข้อผิดพลาดในโคลนเท่านั้น (และดำเนินการเปลี่ยนแปลงส่วนต่อประสานอื่น ๆ ทั้งหมดที่คุณต้องการในขณะที่คุณกำลังทำอยู่)

  3. ประกาศฟังก์ชั่นเดิมตามที่คัดค้าน

  4. ลบฟังก์ชั่นดั้งเดิมในการออกรุ่นสำคัญบางรุ่น

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


1
ในกรณีพิเศษนี้ฟังก์ชั่น "แตกหัก" อาจมีชีวิตอยู่อย่างไม่มีกำหนดเนื่องจากมีพฤติกรรมที่แตกต่างกัน (และมีคุณค่า) โดยพื้นฐาน
RubberDuck

โคลนนี้ทำอะไรได้ดีกว่าเวอร์ชันหลักใหม่โดยใช้การกำหนดเวอร์ชันทางความหมาย
Kat

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

4

ในกรณีเฉพาะนี้เป็นข้อผิดพลาดใน API ของไลบรารีที่ใช้ภายในที่นักพัฒนารายอื่นใช้

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

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

  • หรือมันสำคัญกว่าที่จะทำให้ซอฟต์แวร์ที่มีอยู่เดิมมีเสถียรภาพ

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

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

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


1

ยอมรับมัน มันสามารถทำให้ผลิตภัณฑ์ทั้งหมดของคุณ

GunZ: The Duel (เกมออนไลน์) มีข้อผิดพลาดที่คุณสามารถใช้ประโยชน์และใช้ในทางที่ผิดเพื่อเปลี่ยนการเล่นเกมทั้งหมด (เรียกว่า K-Style; ค้นหาบน YouTube) มันทำให้ทั้งเกมมีความท้าทายมากขึ้น มันใช้ทักษะและทำให้มันเป็นเรื่องที่น่าอัศจรรย์และสนุก .. สนุกมากเลยแม้แต่ผู้ดูแลก็ใช้มันเป็นสไตล์การเล่นหลักอย่างเปิดเผย
มันเป็นสิ่งที่ทำให้เกม
ฉันไม่ได้เล่นเป็นเวลาหลายปี แต่จนถึงทุกวันนี้ในฐานะนักเล่นเกมมันเป็นหนึ่งในเกมที่ฉันชอบตลอดกาลเพราะมันมีพื้นฐานจากความสามารถและความสนุกมาก

ในที่สุดพวกเขาก็ซ่อมมันได้ แต่ผู้คนเกลียดที่มากจน devs ดักฟังมันอย่างจริงจัง

ดังนั้นคำตอบของฉันคือทำให้เสถียรและรักษามันไว้ (refactor ถ้าจำเป็น)


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

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