Sửa một lỗi chưa bao giờ gây ra sự cố cho đến bây giờ


20

Gần đây tôi đã thực hiện một thay đổi khiến một số mã được chạy thường xuyên hơn nhiều so với trước đây. Điều này dẫn đến việc phát hiện ra một lỗi. Lỗi này có khả năng xảy ra bất cứ khi nào mã được chạy nhưng vì nó chạy rất hiếm nên nó không bao giờ nổi lên.

Khi tôi mang đến sự chú ý của nhà phát triển chính, anh ấy muốn tôi hoàn tác thay đổi đã phát hiện ra lỗi thay vì sửa lỗi trích dẫn câu ngạn ngữ, "Nếu nó không bị hỏng, đừng sửa nó".

Rõ ràng với tôi rằng chúng tôi chỉ may mắn cho đến bây giờ nhưng anh ấy sẽ không lắng nghe lý do.

Tôi có nên sửa nó không?

Cập nhật

Người lãnh đạo về mặt kỹ thuật không có bất kỳ thẩm quyền nào đối với tôi. Chỉ cần nhiệm kỳ. Anh ấy là nhà phát triển duy nhất của dự án trong một số năm cho đến một năm trước và tôi nghĩ rằng anh ấy không nhận được sự chỉ trích mang tính xây dựng rất tốt. Đối với những gì xứng đáng, tôi đã không chỉ trích anh ta. Tôi chỉ chỉ ra rằng vì lỗi không bao giờ xuất hiện không có nghĩa là nó không có ở đó.


Đây có phải là một lỗi liên quan đến luồng hoặc cái gì khác?
TheLQ

3
Anh ấy là ông chủ vì một lý do. Khi poop đâm vào quạt, anh ta sẽ là người họ nướng. Nếu anh ta bị rang vì bạn không làm những gì anh ta yêu cầu thì bạn sẽ cần một mái chèo lớn.
Martin York

3
Bạn có thể xây dựng trường hợp xảy ra lỗi ngay cả khi thay đổi của bạn hoàn tác không? Nếu không, có lẽ đó không phải là một lỗi, đó là một fea ^ H ^ H ^ H ^ Hn không có giấy tờ giới hạn.
Steve314

3
Hmm, "Nếu nó bị hỏng, hãy trộn cái gì đó khác." - đó là một cách giải thích tiểu thuyết, tôi sẽ đưa cho anh ta điều đó.
Orble

1
"Nếu nó không bị hỏng, đừng sửa nó"? Nhưng nó đã bị phá vỡ.
StuperUser

Câu trả lời:


26

Tôi sẽ đề nghị rằng nếu bạn có theo dõi lỗi, sau đó gửi nó. Nếu nó quan trọng thì hãy nâng nó lên và khiến nó chú ý. Hãy để cấp trên của bạn hạ cấp nó trong trình theo dõi. Khi mọi thứ đi sai, bạn sẽ có dấu vết giấy.


9
Ghi nhớ: Che Ass của bạn :-)
gruszczy

1
Không may mắn như vậy. Tất cả mọi thứ là chỗ ngồi của quần. Không theo dõi lỗi, không thu thập yêu cầu, không thử nghiệm. Có lẽ thậm chí sẽ không có kiểm soát phiên bản nếu ban quản lý không nhấn mạnh vào nó.
Kenneth Cochran

18
Dựa trên mô tả về môi trường làm việc của bạn, bạn nên gật đầu và mỉm cười khi nhà phát triển chính nói với bạn rằng đừng sửa nó, và sau đó tiếp tục và làm những gì bạn muốn làm bằng mọi cách.
Carson63000

2
Và đừng hỏi những câu hỏi như vậy vào lần tới :-)
gruszczy

2
@codeelegance: "Không theo dõi lỗi, không thu thập yêu cầu, không kiểm tra. Có lẽ thậm chí sẽ không có kiểm soát phiên bản nếu ban quản lý không nhấn mạnh vào nó." - Mẹ Maria ngọt ngào của Chúa !! 1 !! Môi trường đó hoàn toàn trớ trêu với tên người dùng của bạn. :)
Bàn Bobby

8

Cá nhân tôi sẽ sửa nó, trừ khi nó đòi hỏi một nỗ lực đáng kể hơn so với giá trị của nó. "Nếu nó không bị hỏng, đừng sửa nó" thật kinh khủng khi áp dụng cho phần mềm.

Nếu nhà phát triển chính của bạn là ông chủ của bạn và anh ta nói đừng chạm vào nó, thì trong trường hợp đó tôi sẽ không làm thế.


2
Làm thế nào muộn trong chu kỳ là họ? Đây có thể là một vụ tự tử tiềm năng.
Công việc

8
"Nếu nó không bị hỏng, đừng sửa nó" là một quy tắc hoàn toàn tốt để áp dụng cho phần mềm - chỉ khi phần mềm bị hỏng.
Steve314

Nếu nó không bị hỏng, đừng sửa nó, áp dụng cho phần mềm tùy thuộc vào định nghĩa của mã bị hỏng là gì. Ngay khi bạn ngồi xuống và nhìn chằm chằm vào mã rõ ràng cần phải sửa, nó sẽ bị hỏng. Ngay khi bạn bắt đầu thực hiện các giải pháp cho mã bị hỏng, bạn thực sự đang làm việc ngược lại và theo thời gian, mã bị hỏng sẽ ngày càng khó khắc phục hơn ...
Ernelli

2

Hầu hết các câu trả lời và ý kiến ​​đề nghị giảm nhẹ trách nhiệm cho quyết định bằng cách tạo một báo cáo lỗi và để người khác thực hiện cuộc gọi.

Vì tôi không có trình theo dõi lỗi (và tôi nghi ngờ bất kỳ ai khác ngoài tôi sẽ sử dụng nó nếu chúng tôi làm vậy), tôi đã làm điều tốt nhất tiếp theo. Tôi đã đi qua đầu của nhà phát triển chính. Sau khi giải thích tình hình cho quản lý, họ thấy mọi thứ theo cách của tôi. Họ bảo tôi sửa nó đúng cách và bỏ qua yêu cầu của khách hàng tiềm năng. Họ nói rằng họ sẽ làm nhẵn bất kỳ chiếc lông xù nào nếu anh ta phát hiện ra sự khuất phục và phàn nàn.

Không phải là một giải pháp lý tưởng nhưng ít nhất lỗi đã được sửa.


Bạn đã làm việc trong chuỗi chỉ huy, và như vậy che mông của bạn. Sử dụng phần mềm theo dõi lỗi là điều mà công ty của bạn nên xem xét, ít nhất nó sẽ giúp theo dõi những thứ như thế này và các yêu cầu tính năng, v.v.
Berin Loritsch

2

Nhắc nhở anh ấy cụm từ là "Nếu nó không bị hỏng, đừng sửa nó" và không "Nếu khách hàng không chú ý đến nó, đừng sửa nó".


1

Bạn có lý do gì cho sự thay đổi bạn đã thực hiện? Nếu bạn không thể chỉ ra những thay đổi mà người dùng sẽ trải qua hoặc nợ kỹ thuật đã được xóa, tôi sẽ đứng về phía nhà phát triển chính về việc nói chỉ cần thay đổi lại vì điều này chỉ làm mọi thứ tồi tệ hơn.


Tôi có ít nhất một vài lựa chọn khác nhau ở đây:

Nếu bạn cứ tiếp tục và sửa lỗi, bạn có nguy cơ thêm nhiều lỗi vào hỗn hợp có thể gây tác dụng ngược với tâm trí của tôi. Tùy thuộc vào bạn có bao nhiêu kinh nghiệm và tự tin tránh một số bất ngờ khó chịu có thể là hướng dẫn của tôi ở đây.

Nếu bạn làm những gì bạn được bảo phải làm, đó chỉ là cảm giác tội lỗi sẽ là vấn đề hay còn hơn thế nữa? Tôi đang tự hỏi điều gì sai ở đây ngoài những thứ được gọi là nguyên tắc và giá trị. Tôi có nghĩa là như một trò đùa nhưng cũng là một điểm trung thực của những gì sai với ý tưởng này?


Sự thay đổi là cần thiết để sửa một lỗi khác. Khách hàng tiềm năng đề nghị tôi đặt các điều kiện giới hạn tần suất chạy mã thay vì khắc phục nguyên nhân gây ra lỗi. Cả lỗi tôi đã sửa và lỗi tôi phát hiện đều là các nút chặn hiển thị.
Kenneth Cochran

3
Trong trường hợp đó, nó cần phải được sửa chữa đúng. Sử dụng các điều kiện xoay quanh một vấn đề chỉ đơn thuần là khắc phục thảm họa, VÀ nó thêm nhiều mã mới, điều này còn nhiều sai sót. Đó là một giải pháp xấu (thậm chí là ngớ ngẩn).
quick_now

1

Trong khi bản năng áp đảo của tôi sẽ là sửa các lỗi không che giấu vấn đề, có những kịch bản khi tôi sẽ giữ mũi và che giấu vấn đề.

  1. Mã được sử dụng trong nội bộ và đôi khi, do đó hậu quả của lỗi có thể quản lý được trong công ty.
  2. Những cân nhắc thương mại áp đảo đòi hỏi phải vận chuyển ngày hôm nay và sửa lỗi có thể được đưa ra 2 tuần sau đó với những hậu quả tối thiểu.

Về mặt chuyên môn, tôi không thích những câu trả lời này, và sẽ nói rõ trong nội bộ rằng ether của những tình huống này đã xảy ra.


0

Cuối cùng, bạn không nên làm bất cứ điều gì mà cấp trên của bạn nói rõ ràng là không. Tôi tin rằng điều tốt nhất để làm ở vị trí của bạn là tạo một báo cáo lỗi trong bất kỳ cơ sở dữ liệu theo dõi lỗi nào bạn có. bằng cách này, ít nhất mọi người đều nhận thức được vấn đề và ai đó có thẩm quyền hơn có thể quyết định phải làm gì với nó.


0

Sao chép chức năng lỗi, áp dụng sửa chữa, đổi tên nó, có thể ngụy trang một chút và thay vào đó gọi nó.

Dựa trên hai bình luận lỗi showstopper của bạn, lựa chọn tốt nhất của bạn có thể là tuân theo thư pháp luật, nhưng bỏ qua tinh thần của nó.

Rõ ràng là có một nhược điểm mã hóa cắt và dán, nhưng có vẻ như đó sẽ là vấn đề nhỏ nhất của bạn.


1
ý tưởng tồi, nếu tôi bắt gặp một trong những lập trình viên của mình làm điều tương tự, tôi sẽ sa thải anh ta ngay tại chỗ, đó là cách đảm bảo để gây ra thiệt hại cho mã và cho bất kỳ ai phải duy trì mã đó.
Miki Watts

@Miki - trong trường hợp này, hãy cho tôi biết chính xác ý tưởng không phải là xấu? Vui lòng giải thích làm thế nào để đưa một lỗi trở lại bởi vì nó đã tạo ra một lỗi khác (dù sao đó cũng có) rõ ràng hơn là một điều tốt. Đối với việc bắn vào điều đó, tôi sẽ tranh luận về việc sa thải mang tính xây dựng, vì nhà phát triển không có nhiều sự lựa chọn.
Steve314
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.