Làm thế nào để xử lý các lỗi mà người dùng nghĩ là một tính năng?

Câu hỏi :

Cách thích hợp để giải quyết một lỗi mà người dùng cuối nghĩ là một tính năng là gì?

Xây dựng :

Tôi đoán rằng nếu một tỷ lệ lớn người dùng mong đợi nó là một tính năng, thì nó sẽ được để "không trộn" hoặc "cố định" để ổn định hơn? Tuy nhiên, điều gì sẽ xảy ra nếu một tỷ lệ rất nhỏ người dùng mong đợi nó là một tính năng ... giả sử 0,1% hoặc 1% và lỗi này phải được sửa.

Về mặt lý thuyết, vì đây là một sửa lỗi nhỏ, nó có thể đủ điều kiện là MẠNH như được xem xét bởi phiên bản ngữ nghĩa: xyZ Tuy nhiên, vì nó phá vỡ khả năng tương thích ngược (thậm chí chỉ với một vài người dùng) nên nó có thể tăng MAJOR: Xyz Correct? Nó vẫn có thể đủ điều kiện là một VÒI (vì nó không có ý định như một tính năng) miễn là nó được ghi lại?

EDIT: Trong trường hợp cụ thể này, đó là một lỗi trong API của thư viện được sử dụng nội bộ mà các nhà phát triển khác sử dụng.

Tôi đoán rằng nếu một tỷ lệ lớn người dùng mong đợi nó là một tính năng, thì nó sẽ được để "không trộn" hoặc "cố định" để ổn định hơn?

Có lỗi thêm giá trị? Nếu vậy, nó là một tính năng nhiều hơn. Đôi khi, một "lỗi" có thể trở thành một tính năng "thêm giá trị".

Thật khó để trả lời điều này một cách thuyết phục bởi vì mỗi tình huống sẽ khác nhau.

Trong trường hợp cụ thể này, đó là một lỗi trong API của thư viện được sử dụng nội bộ mà các nhà phát triển khác sử dụng.

Trong trường hợp này, tôi sẽ bao gồm một bản sửa lỗi như là một phần của thay đổi đột phá tiếp theo của bạn liên quan đến khả năng tương thích ngược. Bạn thực sự không thể làm điều này một cách nhất quán trong hầu hết các môi trường và có thể có một lịch trình / khung thời gian cho việc này.

Là một nhà phát triển, điều cuối cùng tôi muốn giải quyết là một API có hành vi không chính xác hoặc không nhất quán. Lỗi được coi là này.

Ít nhất, hãy tạo một số loại tài liệu "wiki đã biết với phiên bản hiện tại" trong nội bộ và để bạn có thể đảm bảo tất cả người dùng nội bộ của bạn biết chức năng giống như lỗi. Hy vọng rằng bạn có đủ các bài kiểm tra bao gồm các khu vực nơi mọi người đang sử dụng tính năng sửa lỗi để bạn sẽ thấy nơi / khi mọi thứ bị hỏng khi / nếu bạn sửa lỗi.

Tôi khuyên bạn nên làm cho nó ổn định hơn. Người dùng là nguồn chính của những gì phần mềm của bạn làm. Nếu họ muốn nó, và đã tin tưởng vào nó, tôi sẽ nghĩ lại về việc kéo nó ra.

Một ví dụ điển hình cho điều này là thợ máy "Trượt tuyết" trong trò chơi điện tử "Tribes". Ban đầu là một lỗi trong cách động cơ vật lý xử lý nhảy trên một ngọn đồi, nó đã kết thúc một trong những cơ chế trò chơi cốt lõi. Bạn có thể đọc thêm một chút về nó ở đây , nếu bạn tò mò.

Vì lỗi nằm trong thư viện, đây là một cách tiếp cận khác mà bạn có thể thực hiện:

1. Tạo một bản sao của chức năng thư viện sai lầm. Trong nhiều trường hợp, mọi người chỉ cần thêm một 2tên hàm trong các trường hợp này, nhưng, nếu bạn có những thay đổi khác mà bạn muốn áp dụng cho giao diện của hàm đó, bạn cũng có thể đặt cho nó một tên hoàn toàn khác.

2. Chỉ sửa lỗi trong bản sao (và thực hiện tất cả các thay đổi giao diện khác mà bạn muốn trong khi bạn đang ở đó).

3. Khai báo hàm ban đầu là không dùng nữa.

4. Loại bỏ chức năng ban đầu trong một số phiên bản chính sắp tới.

Cách tiếp cận này đặc biệt hữu ích cho các chức năng có giao diện bị hỏng cơ bản: Bạn không phá vỡ mã người dùng ngay lập tức, nhưng bạn đưa ra cảnh báo thích đáng cho bất kỳ ai dựa vào mã bị hỏng để chuyển sang sử dụng mã cố định. Và ngay cả khi mọi người không chú ý đến cảnh báo, họ thực sự không thể đổ lỗi cho bạn một khi bạn thực sự loại bỏ chức năng bị hỏng.

Trong trường hợp cụ thể này, đó là một lỗi trong API của thư viện được sử dụng nội bộ mà các nhà phát triển khác sử dụng.

Nếu những nhà phát triển khác nghĩ rằng hành vi đó là một tính năng, có khả năng họ đã sử dụng nó và đã xây dựng phần mềm hoạt động dựa trên nó. Sửa lỗi có thể sẽ phá vỡ mã hiện tại của họ và họ sẽ đổ lỗi cho bạn vì điều này. Điều này làm cho việc sửa lỗi trở thành một sự đánh đổi và bạn phải xem xét

• ví dụ, việc sửa lỗi có thực sự quan trọng không, vì có nguy cơ cao cho phép người dùng API của bạn gặp sự cố với ứng dụng của họ trong trường hợp lỗi không được sửa? Hay đây chỉ là về tính nhất quán của API?

• hoặc điều quan trọng hơn là giữ cho phần mềm hiện có ổn định và thư viện của bạn tương thích ngược?

Câu trả lời cho câu hỏi không phải lúc nào cũng đơn giản, bạn phải tính đến số lượng người dùng API có thể có của bạn, số lượng công việc tiềm năng họ sẽ phải thay đổi phần mềm của họ, số lượng phần mềm sẽ bị hỏng nếu bạn thay đổi API , nhưng cũng có những rủi ro về những gì có thể xảy ra nếu bạn không sửa API.

Chỉ vì bạn ghi lại sự thay đổi lỗi trong "danh sách các thay đổi vi phạm trong bản phát hành chính tiếp theo" không làm cho khách hàng của bạn hài lòng - nếu bạn làm điều này, nên có ít nhất một số bằng chứng lý do tại sao bạn không thể để API như nó là trước đây. Thường thì việc giữ khả năng tương thích ngược là quan trọng hơn sửa lỗi. Vì vậy, hãy khắc phục chỉ khi bạn có thể ước tính tác động đến cơ sở người dùng và phần mềm của họ và bạn chắc chắn rằng bạn sẽ không tạo ra những nỗ lực vô lý cho họ khi họ cố gắng cập nhật lên bản phát hành thư viện mới nhất của bạn. Và nếu bạn không có đủ thông tin để ước tính tốt về điều này, có lẽ tốt hơn là không thay đổi hành vi.

(Và vâng, nếu bạn định thực hiện thay đổi API không tương thích ngược, số phiên bản của bạn phải thể hiện rõ điều này, không quan trọng bạn có đặt tên đó là "lỗi" hay không).

Nắm lấy nó. Nó có thể làm cho toàn bộ sản phẩm của bạn.

GunZ: The Duel (một trò chơi trực tuyến) có một lỗi mà bạn có thể khai thác và liên tục lạm dụng để thay đổi gần như toàn bộ lối chơi (được gọi là K-Style; tìm kiếm trên YouTube). Nó làm cho toàn bộ cách trò chơi trở nên thách thức hơn; nó đòi hỏi kỹ năng và làm cho nó trở nên tuyệt vời và thú vị .. thú vị đến nỗi ngay cả những người điều hành cũng công khai sử dụng nó làm phong cách chơi chính của họ.
Đó là những gì tạo nên trò chơi.
Tôi đã không chơi trong nhiều năm nhưng cho đến ngày nay, với tư cách là một game thủ, nó là một trong những trò chơi yêu thích của tôi mọi thời đại bởi vì nó dựa trên kỹ năng và rất thú vị, và tất cả những điều tuyệt vời này chỉ vì một lỗi.

Cuối cùng họ đã sửa nó, nhưng mọi người ghét nó đến mức các nhà phát triển nghiêm túc trả lại nó.

Vì vậy, câu trả lời của tôi là ổn định và duy trì nó (tái cấu trúc nếu cần).

Câu chuyện hay đó đang được nói, tôi không nghĩ câu trả lời tương tự áp dụng cho bất cứ điều gì không có lợi thế trực tiếp. Nếu lỗi của bạn gây ra sự kiện gây ra lợi thế, thông thường sẽ thông minh hơn để sửa lỗi và tìm cách khác để đạt được bất cứ điều gì có thể. Nếu nó nằm ngoài phạm vi, hãy xem xét loại bỏ nó ra khỏi phạm vi hoặc tạo một mô-đun khác (có thể là một mô-đun nhỏ) để giới thiệu nó. Về cơ bản: không vi phạm nguyên tắc trách nhiệm duy nhất .