Nếu lỗi đã hơn 5 năm tuổi thì đó có phải là một tính năng không? [đóng cửa]


18

Cho phép tôi thêm chi tiết: Tôi làm việc tại một tổ chức có nhiều lập trình viên, người thử nghiệm, nhà phân tích QA, chủ sở hữu sản phẩm, v.v. và đây là điều khiến tôi băn khoăn:

Chúng tôi đã có thể bán phần mềm crappy (mặc dù khá chức năng) trong hơn một thập kỷ. Nó có nhiều tính năng và sản phẩm có tính cạnh tranh, nhưng có một số lỗi nghiêm trọng ngoài đó, cũng như hàng ngàn "cắt giấy" - những phiền toái nhỏ mà khách hàng cần phải làm quen.

Tôi đau đớn khi xem xét một số điều vì tôi tin chắc rằng nếu máy tính không giúp làm cho cuộc sống của chúng ta dễ dàng hơn, thì chúng ta không nên sử dụng chúng. Tôi có niềm tin vào các đồng nghiệp của mình - họ thông minh, có khả năng và có thể cải thiện mọi thứ khi tập trung vào việc đó.

Nhưng, có thể khó gửi các lỗi chống lại một số chức năng cũ mà không thấy chúng bị đóng hoặc quên. "Nó hoạt động như thế đối với các eons" là một câu trả lời điển hình. Ngoài ra, khi QA thực hiện hồi quy, họ có xu hướng tìm kiếm bất cứ thứ gì khác biệt nhiều như bất cứ thứ gì có vẻ không đúng. Vì vậy, một bản sửa lỗi cho một vấn đề cũ có thể được viết thành một lỗi, bởi vì "nó đã từng như vậy trước cả thời của tôi".

Các lập trình viên trẻ trong tôi nghĩ: viết lại điều kỳ dị này! Là một người có cơ hội gần gũi với việc bán hàng, khách hàng, tôi muốn đưa ra một lợi ích của sự nghi ngờ đối với phương pháp này.

Tôi quan tâm đến ý kiến ​​/ kinh nghiệm của bạn là tốt. Hãy cố gắng xem xét rủi ro, chi phí cho lợi ích và các yếu tố phi kỹ thuật khác.


2
Tôi nghĩ bạn có nghĩa là "... làm việc như vậy cho các eons."
Onion-Knight

Không bao giờ viết lại. Trừ khi nó tự sụp đổ (bạn không thể thêm nhiều thứ bị hỏng), bạn sẽ giới thiệu nhiều lỗi hơn sau đó sửa khi bạn quyết định viết lại (cũng như thời gian)

Nếu bạn không mất khách hàng bây giờ, một ngày nào đó bạn sẽ làm được. Ai đó cuối cùng sẽ thuyết phục mọi người rằng phần mềm của họ dễ hơn của bạn. Bây giờ, có lẽ bạn không nên tự giải quyết vấn đề này. Đây là một sự thay đổi văn hóa tại công ty của bạn ... không có gì bạn có thể hoặc nên làm một mình.
Brad

Câu trả lời:


14

Tôi cảm nhận được nỗi đau của bạn.

Nhưng sửa một cái gì đó chỉ vì nó là một lỗi không phải là một lý do đủ tốt.

Bạn phải đảm bảo rằng bản sửa lỗi của bạn sẽ không phá vỡ bất kỳ mã nào khác (không chỉ mã của bạn mà cả mã khách hàng sử dụng mã của bạn). Nếu bạn đưa ra một bản sửa lỗi và điều này phá vỡ mọi hệ thống khách hàng, bạn sẽ có một số khách hàng rất bất mãn.

Có rất nhiều ví dụ nổi tiếng nơi mã mới được viết để thay thế một hệ thống cũ. Trường hợp họ phải bổ sung rõ ràng chức năng của một lỗi trong hệ thống cũ vì người dùng phụ thuộc vào lỗi đó (Không định tên tên nhưng tôi chắc chắn bạn có thể google nó).

Kiểm tra hồi quy về cơ bản là một thử nghiệm về những gì khách hàng của bạn mong đợi xảy ra. Trước khi loại bỏ kiểm tra hồi quy, đảm bảo rằng nó sẽ không làm tổn thương ai đó (điều này gần như không thể áp dụng được). Nếu bạn có thể sửa một lỗi điều này không phá vỡ các bài kiểm tra hồi quy thì đó là một sửa chữa thực sự.


Phần kiểm tra hồi quy là đúng khi cho rằng bạn thực sự biết mức độ phù hợp của kiểm tra.
Pemdas

mặt khác, nếu bạn viết mã GUI, thì sẽ có ít phụ thuộc hơn; người dùng tiến hóa dễ dàng hơn.
Matthieu M.

@Matthieu M.: Hoàn toàn. Thay đổi thói quen sẽ dễ dàng hơn (miễn là bạn đầu tư vào sửa chữa thói quen) hơn là sửa (rất nhiều) hệ thống tự động (hầu hết mọi người sẽ quên ở phòng sau).
Martin York

3

một số điều cần xem xét khi quyết định sửa lỗi ... không bao gồm tất cả.

  • Có quan trọng (hệ thống gặp sự cố)? ... rõ ràng những cái này được sửa
  • Có phải khách hàng thường phàn nàn về nó? Đây có thể là một lỗi vì trong mã bị lỗi hoặc có thể là lỗi yêu cầu, chẳng hạn như tính năng này không thân thiện với người dùng hoặc họ mong đợi nó hoạt động khác đi.
  • Từ quan điểm kinh doanh có lợi hơn để sửa lỗi hoặc thực hiện một tính năng mới?
  • Có phải lỗi yêu cầu thay đổi kiến ​​trúc đáng kể hay nó nằm trong một phần của hệ thống được phụ thuộc rất nhiều bởi các hệ thống con khác? Điều này có thể tác động mạnh mẽ đến thời gian thử nghiệm và làm phức tạp phạm vi kiểm tra cần thiết cần thiết để xác nhận lỗi? Nếu nó thực sự cũ, đôi khi rất khó để hiểu chính xác những gì khác sẽ ảnh hưởng trong hệ thống bằng cách sửa đổi phần lỗi của mã.
  • Bạn đang mất khách hàng tiềm năng vì một hệ thống lỗi

Về việc mất khách hàng tiềm năng - điều đó rất khó đối với tôi và ngay cả đối với bán hàng / tiếp thị, nhưng tỷ lệ duy trì vẫn cao (mặc dù chi phí chuyển đổi cũng cao). Có thể cho rằng bạn khó có thể biết liệu bạn có làm tốt hơn A hay không, trừ khi bạn thực hiện kiểm tra A / B đúng cách.
Công việc

1
Tôi không chắc làm thế nào có thể áp dụng điều này trong trường hợp của bạn, nhưng chúng tôi thường (Một phần tư) có một cuộc họp với các kỹ sư bán hàng của chúng tôi để thảo luận về các vấn đề trong lĩnh vực đã ngăn họ bán hàng. Điều này có thể bao gồm các tính năng bị thiếu hoặc một cái gì đó hoạt động kém từ góc độ tương tác người dùng ... ect.
Pemdas

3

Xác định lỗi. "Thông số kỹ thuật được sắp xếp theo ngày, nhưng được sắp xếp theo số lượng giao dịch" không nhất thiết là lỗi trong mã. Đó có thể là một thay đổi không có giấy tờ - đôi khi, ở đâu đó, ai đó đã yêu cầu thay đổi thứ tự sắp xếp nhưng thông số kỹ thuật, yêu cầu, hướng dẫn sử dụng (thậm chí các nút và nhãn trên UI) không thay đổi để phù hợp và không ai bận tâm. Việc bạn xuất hiện và thay đổi nó thành "theo ngày" sẽ gây ra sự hỗn loạn và để bạn cập nhật ui, thông số kỹ thuật, hướng dẫn sử dụng, về cơ bản là lãng phí thời gian của bạn, ngoại trừ một chút "lý thuyết cửa sổ bị hỏng . "

Một số thứ rõ ràng là lỗi. Nếu bạn nhấp vào nút này, nó sẽ nổ tung. Hoặc, nếu bạn nhấp vào nút này vào thứ Hai, nó sẽ nổ tung. Trừ khi ai đó đã giao nhiệm vụ cho bạn đầu tư thời gian để hiểu lý do tại sao, bạn có thể dành rất nhiều nỗ lực để điều tra. Và một khi bạn tìm hiểu lý do tại sao, bạn cũng không thể thay đổi nó, bởi vì điều đó sẽ phá hỏng thứ gì đó quan trọng hơn đối với người dùng hoặc quản lý.

Nếu bạn thấy "sự chậm chạp" - rò rỉ bộ nhớ, mã rõ ràng cần một số quy ước tối ưu hóa, thụt lề và đặt tên không khớp với bạn - thật là hấp dẫn để khắc phục một ngày nào đó khi bạn không có gì khác để làm, hoặc vào thời gian riêng của bạn . Tuy nhiên, các "sửa lỗi" này làm xáo trộn lịch sử trong kiểm soát nguồn vì ít hoặc không có lợi ích, những thảm họa rủi ro như "chúng tôi không bao giờ biên dịch mô-đun đó vì nhị phân chúng tôi sử dụng trong sản xuất được xây dựng từ mã bị mất và bạn chỉ ghi đè lên nó ", Và có thể làm phiền nghiêm trọng những người có" lỗi "mà bạn đang" sửa chữa ".

Tôi đề nghị một đối một với sếp của bạn. Giải thích điều gì đang làm phiền bạn - đó có phải là phong cách mã hóa, những điều mà bạn chắc chắn phải gây khó chịu cho người dùng, con số không chính xác, sự không nhất quán hoặc thảm họa đang chờ xảy ra? Sau đó yêu cầu hướng dẫn và (đây là chìa khóa) mang nó.


2

Nếu bạn muốn sửa một lỗi đã cũ, bạn sẽ phải cẩn thận để không phá vỡ bất kỳ chức năng hiện có nào. Nếu có các bài kiểm tra đơn vị, việc này dễ hơn, nhưng với độ tuổi ngụ ý của công ty và phần mềm, chúng không tồn tại. Tôi khuyên bạn nên xem qua cuốn sách Tái cấu trúc của Martin Fowler bởi vì nó hướng dẫn cách tái cấu trúc đúng cách và sửa lỗi trong khi cố gắng giảm thiểu tác dụng phụ. Tôi cũng sẽ khuyên bạn nên đảm bảo rằng công ty vẫn ổn khi bạn vượt qua những lỗi cũ trong thời gian thường xuyên. Họ chỉ có thể cho phép bạn làm điều này nếu bạn làm quá giờ ngoài giờ.

Ngoài ra, nếu một lỗi đã trở thành một tính năng tức là nó thực sự được sử dụng bởi các máy khách vì nó cung cấp một cái gì đó, hãy đảm bảo cung cấp một sự thay thế phù hợp khi họ muốn hành vi đó (hoặc chỉ ghi lại nó như một tính năng thay vì một lỗi).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.