Hãy tưởng tượng bạn đang tạo một trình phát video bằng JavaScript. Trình phát video này lặp lại video của người dùng bằng cách sử dụng chức năng đệ quy và do đó, trình duyệt sẽ kích hoạt một too much recursion RangeErrorlúc nào đó.

Có lẽ không ai sẽ sử dụng tính năng lặp nhiều như vậy. Ứng dụng của bạn sẽ không bao giờ gây ra lỗi này, ngay cả khi người dùng rời khỏi ứng dụng trong vòng một tuần, nhưng nó vẫn tồn tại. Giải quyết vấn đề sẽ yêu cầu bạn thiết kế lại cách thức hoạt động của vòng lặp trong ứng dụng của bạn, việc này sẽ tốn một khoảng thời gian đáng kể. Bạn làm nghề gì? Tại sao?

• Sửa lỗi

• Để lại lỗi

Không phải bạn chỉ nên sửa lỗi mọi người sẽ vấp ngã sao? Khi nào bugfix trở nên quá mức cần thiết, nếu nó xảy ra?

BIÊN TẬP:

Nếu cách tiếp cận đệ quy không gây ra lỗi thực sự là mối lo ngại đối với bạn, giả sử rằng mỗi lần người chơi lặp một video, một biến sẽ được tăng thêm 1. Sau 2 ⁵³ vòng, biến này sẽ tràn và chương trình của bạn sẽ không thể xử lý nó, đưa ra một ngoại lệ.

Bạn phải thực dụng.

Nếu lỗi không có khả năng được kích hoạt trong thế giới thực và chi phí để sửa chữa cao, tôi nghi ngờ nhiều người sẽ coi đó là một cách sử dụng tài nguyên tốt để khắc phục. Trên cơ sở đó, tôi muốn nói hãy để lại nhưng đảm bảo rằng vụ hack được ghi lại cho bạn hoặc người kế nhiệm của bạn sau vài tháng (xem đoạn cuối).

Điều đó nói rằng, bạn nên sử dụng vấn đề này như một "trải nghiệm học tập" và lần sau khi bạn thực hiện vòng lặp không sử dụng vòng lặp đệ quy không cần thiết.

Ngoài ra, hãy chuẩn bị cho báo cáo lỗi đó. Bạn sẽ ngạc nhiên khi người dùng cuối giỏi chống lại các ranh giới và phát hiện ra các khiếm khuyết. Nếu nó trở thành một vấn đề đối với người dùng cuối, bạn sẽ phải sửa nó - sau đó bạn sẽ vui mừng khi bạn ghi lại vụ hack.

Có một lỗi tương tự trong Windows 95 khiến máy tính gặp sự cố sau 49,7 ngày . Nó chỉ được chú ý vài năm sau khi phát hành, vì rất ít hệ thống Win95 vẫn tồn tại lâu như vậy. Vì vậy, có một điểm: lỗi có thể được đưa ra không liên quan bởi các lỗi khác quan trọng hơn.

Những gì bạn phải làm là đánh giá rủi ro cho toàn bộ chương trình và đánh giá tác động đối với các lỗi riêng lẻ.

• Là phần mềm này trên một ranh giới bảo mật?
• Nếu vậy, lỗi này có thể dẫn đến một khai thác?
• Phần mềm này có "nhiệm vụ quan trọng" đối với người dùng dự định của nó không? (Xem danh sách những thứ mà Java EULA cấm bạn sử dụng nó cho )
• Lỗi có thể dẫn đến mất dữ liệu? Thua lỗ? Mất uy tín?
• Làm thế nào có khả năng lỗi này xảy ra? (Bạn đã bao gồm điều này trong kịch bản của bạn)

Và như vậy. Điều này ảnh hưởng lỗi phân loại , quá trình quyết định mà lỗi để sửa chữa. Khá nhiều phần mềm vận chuyển có danh sách rất dài các lỗi nhỏ chưa được coi là đủ quan trọng để khắc phục.

Các câu trả lời khác đã rất tốt và tôi biết ví dụ của bạn chỉ là một ví dụ, nhưng tôi muốn chỉ ra một phần lớn của quy trình này chưa được thảo luận:

Bạn cần xác định các giả định của mình và sau đó kiểm tra các giả định đó đối với các trường hợp góc.

Nhìn vào ví dụ của bạn, tôi thấy một vài giả định:

• Cách tiếp cận đệ quy cuối cùng sẽ gây ra lỗi.
• Không ai sẽ thấy lỗi này vì video mất quá nhiều thời gian để phát để đạt đến giới hạn ngăn xếp.

Những người khác đã thảo luận về giả định đầu tiên, nhưng hãy nhìn vào giả định thứ hai: nếu video của tôi chỉ dài một phần giây thì sao?

Và chắc chắn, có lẽ đó không phải là trường hợp sử dụng rất phổ biến. Nhưng bạn có thực sự chắc chắn rằng không ai sẽ tải lên một video rất ngắn? Bạn đang cho rằng video có thời lượng tối thiểu và thậm chí bạn có thể không nhận ra mình đang giả sử bất cứ điều gì! Giả định này có thể gây ra bất kỳ lỗi nào khác ở những nơi khác trong ứng dụng của bạn không?

Các giả định không xác định là một nguồn lỗi rất lớn.

Như tôi đã nói, tôi biết rằng ví dụ của bạn chỉ là một ví dụ, nhưng quá trình xác định các giả định của bạn (thường khó hơn âm thanh) và sau đó nghĩ đến các ngoại lệ cho các giả định đó là một yếu tố rất lớn trong việc quyết định sử dụng thời gian của bạn.

Vì vậy, nếu bạn thấy mình suy nghĩ "Tôi không cần phải lập trình xung quanh vấn đề này, vì nó sẽ không bao giờ xảy ra" thì bạn nên dành chút thời gian để thực sự kiểm tra giả định đó. Bạn sẽ thường nghĩ về các trường hợp góc có thể phổ biến hơn bạn nghĩ ban đầu.

Điều đó đang được nói, có một điểm mà điều này trở thành một bài tập vô ích. Bạn có thể không quan tâm nếu ứng dụng JavaScript của bạn hoạt động hoàn hảo trên máy tính TI-89, do đó, việc dành bất kỳ khoảng thời gian nào cho việc đó chỉ là lãng phí.

Các câu trả lời khác đã đề cập đến vấn đề này, nhưng đưa ra câu hỏi giữa "điều này quan trọng" và "đây là một sự lãng phí thời gian" không phải là một khoa học chính xác, và nó phụ thuộc vào rất nhiều yếu tố có thể hoàn toàn khác với một người hoặc công ty khác.

Nhưng một phần rất lớn của quá trình đó trước tiên là xác định các giả định của bạn và sau đó cố gắng nhận ra các ngoại lệ đối với các giả định đó.

Tôi khuyên bạn nên đọc bài báo sau:

Độ tin cậy và các mối đe dọa của nó: Một nguyên tắc phân loại

Trong số những thứ khác, nó mô tả các loại lỗi khác nhau có thể xảy ra trong chương trình của bạn. Những gì bạn mô tả được gọi là lỗi không hoạt động , và trong bài báo này, nó được mô tả như sau:

Một lỗi được kích hoạt khi nó tạo ra một lỗi, nếu không nó là không hoạt động. Một lỗi hoạt động là a) một lỗi bên trong trước đó không hoạt động và đã được kích hoạt bởi quá trình tính toán hoặc điều kiện môi trường hoặc b) một lỗi bên ngoài. Kích hoạt lỗi là ứng dụng của một đầu vào (mẫu kích hoạt) cho một thành phần gây ra lỗi không hoạt động để hoạt động. Hầu hết các lỗi nội bộ chu kỳ giữa trạng thái không hoạt động và trạng thái hoạt động của chúng

Đã mô tả điều này, tất cả nắm lấy tỷ lệ lợi ích chi phí. Chi phí sẽ bao gồm ba tham số:

• Làm thế nào thường vấn đề sẽ trình bày chính nó?
• Hậu quả sẽ là gì?
• Bao nhiêu nó làm phiền cá nhân bạn?

Hai cái đầu tiên rất quan trọng. Nếu đó là một số lỗi sẽ xuất hiện một lần trong một mặt trăng xanh và / hoặc không ai quan tâm đến nó, hoặc có một cách giải quyết hoàn toàn tốt và thực tế, thì bạn có thể ghi nhận nó một cách an toàn như một vấn đề đã biết và chuyển sang một số thách thức hơn và nhiều hơn nữa nhiệm vụ quan trọng. Tuy nhiên, nếu lỗi sẽ khiến một số giao dịch tiền không thành công hoặc làm gián đoạn quá trình đăng ký dài, do đó gây khó chịu cho người dùng cuối, thì bạn phải hành động theo nó. Tham số thứ ba là một cái gì đó tôi mạnh mẽ khuyên chống lại. Theo lời của Vito Corleone:

Nó không mang tính cá nhân. Đó là kinh doanh.

Nếu bạn là một người chuyên nghiệp, hãy để cảm xúc sang một bên và hành động tối ưu. Tuy nhiên, nếu ứng dụng bạn đang viết là sở thích của bạn, thì bạn có liên quan đến cảm xúc và tham số thứ ba có giá trị như bất kỳ điều gì trong việc quyết định có sửa lỗi hay không.

Lỗi đó chỉ chưa được phát hiện cho đến ngày ai đó đưa trình phát của bạn lên màn hình sảnh chạy bài thuyết trình của công ty 24/7. Vì vậy, nó vẫn là một lỗi.

Câu trả lời cho những gì bạn làm? thực sự là một quyết định kinh doanh, không phải là một kỹ thuật:

• Nếu lỗi chỉ ảnh hưởng đến 1% người dùng của bạn và trình phát của bạn thiếu hỗ trợ cho một tính năng được yêu cầu bởi 20% khác, thì sự lựa chọn là hiển nhiên. Tài liệu lỗi, sau đó tiếp tục.
• Nếu lỗi này nằm trong danh sách việc cần làm của bạn, tốt hơn hết là sửa nó trước khi bạn bắt đầu thêm các tính năng mới. Bạn sẽ nhận được những lợi ích của quy trình phát triển phần mềm không khuyết tật và bạn sẽ không mất nhiều thời gian vì dù sao nó cũng nằm trong danh sách của bạn.

Đặc biệt trong các công ty lớn (hoặc các dự án lớn) có một cách rất thực tế để thiết lập những việc cần làm.

Nếu chi phí sửa chữa lớn hơn lợi nhuận mà bản sửa lỗi sẽ mang lại thì hãy giữ lỗi. Viceversa nếu sửa chữa sẽ trả lại nhiều hơn chi phí của nó sau đó sửa lỗi.

Trong kịch bản mẫu của bạn, nó phụ thuộc vào số lượng người dùng bạn sẽ mất so với số lượng người dùng bạn sẽ nhận được nếu bạn phát triển các tính năng mới thay vì sửa lỗi đắt tiền đó.

tl; dr Đây là lý do tại sao RESOLVED/WONTFIXlà một điều. Đừng lạm dụng nó - nợ kỹ thuật có thể chồng chất nếu bạn không cẩn thận. Đây có phải là một vấn đề cơ bản với thiết kế của bạn, có khả năng gây ra các vấn đề khác trong tương lai? Sau đó sửa nó. Nếu không thì? Để nó là cho đến khi nó trở thành một ưu tiên (nếu nó đã từng).

Thực tế có ba lỗi trong tình huống bạn mô tả:

1. Việc thiếu một quy trình để đánh giá tất cả các lỗi đã ghi (bạn đã ghi lại lỗi trong vé / tồn đọng / bất kỳ hệ thống nào bạn có, phải không?) Để xác định xem có nên sửa hay không. Đây là một quyết định quản lý.

2. Việc thiếu các kỹ năng trong nhóm của bạn dẫn đến việc sử dụng các giải pháp bị lỗi như thế này. Điều này là khẩn cấp để có địa chỉ này để tránh các vấn đề trong tương lai. (Bắt đầu học hỏi từ những sai lầm của bạn.)

3. Vấn đề mà video có thể ngừng hiển thị sau một thời gian rất dài.

Trong ba lỗi chỉ (3) có thể không cần phải sửa.

Có rất nhiều câu trả lời ở đây thảo luận về việc đánh giá chi phí của lỗi được khắc phục thay vì để lại nó. Tất cả chúng đều chứa những lời khuyên tốt, nhưng tôi muốn nói thêm rằng chi phí của một lỗi thường bị đánh giá thấp, có thể bị đánh giá thấp. Lý do là các con bọ hiện tại làm vấy bẩn vùng biển để tiếp tục phát triển và bảo trì. Làm cho người kiểm tra của bạn theo dõi một số lỗi "sẽ không sửa" trong khi điều hướng phần mềm của bạn cố gắng tìm các lỗi mới làm cho công việc của họ chậm hơn và dễ bị lỗi hơn. Một vài lỗi "sẽ không sửa" không có khả năng ảnh hưởng đến người dùng cuối vẫn sẽ khiến quá trình phát triển tiếp tục chậm hơn và kết quả sẽ trở nên khó khăn hơn.

Một điều tôi đã học được trong những năm viết mã là một lỗi sẽ quay trở lại. Người dùng cuối sẽ luôn khám phá nó và báo cáo lại. Cho dù bạn có sửa lỗi hay không thì "chỉ là" vấn đề ưu tiên và thời hạn.

Chúng tôi đã có một số lỗi lớn (theo ý kiến ​​của tôi là chính) đã quyết định sửa lỗi trong một bản phát hành, chỉ để trở thành một điểm dừng hiển thị cho bản phát hành tiếp theo vì người dùng cuối tình cờ gặp lại nó nhiều lần. Ngược lại, ngược lại - chúng tôi đã cố gắng sửa một lỗi trong một tính năng không ai sử dụng, nhưng nó rất hữu ích cho việc quản lý để xem.

Có ba điều ở đây:

Nguyên tắc

Đây là một mặt của đồng tiền. Chừng mực nào đó, tôi cảm thấy nó là tốt để nhấn mạnh vào sửa chữa lỗi (hoặc triển khai xấu, ngay cả khi họ "làm việc"), ngay cả khi không ai chú ý đến nó.

Nhìn vào nó theo cách này: vấn đề thực sự không nhất thiết là lỗi, trong ví dụ của bạn, nhưng thực tế là một lập trình viên nghĩ rằng đó là một ý tưởng tốt để thực hiện vòng lặp theo cách này, ngay từ đầu. Rõ ràng ngay từ giây phút đầu tiên, đây không phải là một giải pháp tốt. Bây giờ có hai khả năng:

• Các lập trình viên không chú ý. Chà ... một lập trình viên nên phát triển trực giác về cách mã của anh ta chạy. Nó không giống như đệ quy là một khái niệm rất khó khăn. Bằng cách sửa lỗi (và đổ mồ hôi qua tất cả các công việc bổ sung), anh ta có thể học được điều gì đó và ghi nhớ nó, nếu chỉ để tránh công việc bổ sung trong tương lai. Nếu lý do được rằng ông không có đủ thời gian, quản lý có thể biết rằng các lập trình viên làm cần thêm thời gian để tạo mã chất lượng cao hơn.

• Các lập trình viên đã thông báo, nhưng coi đó là "không thành vấn đề". Nếu điều này còn lại để đứng vững, thì một nền văn hóa của laissez-faire được phát triển sẽ, cuối cùng, sẽ dẫn đến những lỗi mà nó thực sự gây tổn thương. Trong trường hợp đặc biệt này, ai quan tâm. Nhưng điều gì sẽ xảy ra nếu lập trình viên đó đang phát triển một ứng dụng ngân hàng vào lần tới và quyết định rằng một chòm sao nào đó sẽ không bao giờ xảy ra. Sau đó, nó làm. Thời gian tồi tệ

Chủ nghĩa thực dụng

Đây là mặt khác. Tất nhiên, bạn có thể, trong trường hợp cụ thể này, không sửa lỗi. Nhưng xem ra - có chủ nghĩa thực dụng, và sau đó là chủ nghĩa thực dụng. Chủ nghĩa thực dụng tốt là nếu bạn tìm thấy một giải pháp nhanh chóng nhưng vững chắc, có cơ sở cho một vấn đề. Tức là bạn tránh các công cụ quá mức, nhưng những điều bạn thực sự thực hiện vẫn được cân nhắc kỹ lưỡng. Chủ nghĩa thực dụng xấu là khi bạn chỉ cần hack một cái gì đó cùng hoạt động "chỉ như vậy" và sẽ phá vỡ ở cơ hội đầu tiên.

Thất bại nhanh, thất bại nặng nề

Nếu nghi ngờ, thất bại nhanh và thất bại nặng nề.

Điều này có nghĩa, trong số những người khác, mã của bạn thông báo tình trạng lỗi, không phải môi trường.

Trong ví dụ này, điều tối thiểu bạn có thể làm là làm cho nó không xảy ra lỗi thời gian chạy cứng ("vượt quá độ sâu ngăn xếp" hoặc tương tự), bằng cách thay thế nó bằng một ngoại lệ cứng của chính bạn. Ví dụ, bạn có thể có bộ đếm toàn cầu và tự ý quyết định rằng bạn bảo lãnh sau 1000 video (hoặc bất kỳ số nào đủ cao không bao giờ xảy ra trong sử dụng bình thường và đủ thấp để vẫn hoạt động trong hầu hết các trình duyệt). Sau đó đưa ra ngoại lệ đó (có thể là ngoại lệ chung, ví dụ: RuntimeExceptiontrong Java hoặc một chuỗi đơn giản trong JavaScript hoặc Ruby) một thông điệp có ý nghĩa. Bạn không cần phải đi đến mức tạo ra một loại ngoại lệ mới hoặc bất cứ điều gì bạn làm trong ngôn ngữ lập trình cụ thể của bạn.

Bằng cách này, bạn có

• ... ghi lại vấn đề bên trong mã.
• ... làm cho nó trở thành một vấn đề quyết định. Bạn biết rằng ngoại lệ của bạn sẽ xảy ra. Bạn không phải là người thích thay đổi công nghệ trình duyệt cơ bản (hãy nghĩ về không chỉ trình duyệt PC, mà cả điện thoại thông minh, máy tính bảng hoặc công nghệ tương lai).
• ... Làm cho nó dễ dàng để sửa nó khi cuối cùng bạn cần phải sửa nó. Nguồn gốc của vấn đề được chỉ ra bởi thông điệp của bạn, bạn sẽ nhận được một backtrack có ý nghĩa và tất cả điều đó.
• ... vẫn lãng phí thời gian để xử lý lỗi "thực" (hãy nhớ rằng, bạn không bao giờ mong đợi lỗi xảy ra).

Quy ước của tôi là tiền tố các thông báo lỗi như vậy với từ "Paranoia:". Đây là một dấu hiệu rõ ràng với tôi và mọi người khác mà tôi không bao giờ nghĩ rằng lỗi đó sẽ xuất hiện. Tôi rõ ràng có thể tách chúng ra khỏi các ngoại lệ "thực". Nếu tôi thấy một cái như thế trong GUI hoặc logfile, tôi biết chắc chắn rằng tôi có một vấn đề nghiêm trọng - rốt cuộc tôi không bao giờ nghĩ chúng sẽ xảy ra. Tại thời điểm này , tôi chuyển sang chế độ crunch (với một cơ hội tốt để giải quyết nó một cách nhanh chóng và khá dễ dàng, vì tôi biết chính xác vấn đề xảy ra ở đâu, cứu tôi khỏi rất nhiều gỡ lỗi giả).

Một bài đăng trên bàn của một nhà phát triển cao cấp tại nơi làm việc của tôi nói

Nó có giúp được ai không?

Tôi nghĩ đó thường là điểm khởi đầu tốt cho quá trình suy nghĩ. Luôn có rất nhiều thứ để sửa chữa và cải thiện - nhưng bạn thực sự thêm bao nhiêu giá trị? ... cho dù đó là về khả năng sử dụng, độ tin cậy, khả năng bảo trì, khả năng đọc, hiệu suất ... hoặc bất kỳ khía cạnh nào khác.

Ba điều tôi suy nghĩ:

Đầu tiên , tác động của một lỗi được xác định cần phải được điều tra kỹ lưỡng trước khi quyết định để lại lỗi trong mã có thể được đưa ra một cách có trách nhiệm. (Trong ví dụ của bạn, tôi đã từng nghĩ về việc rò rỉ bộ nhớ, ngăn xếp ngày càng tăng và điều này có thể làm cho trình duyệt của bạn chậm hơn và chậm hơn với mỗi lần đệ quy.) Việc điều tra kỹ lưỡng này thường mất nhiều thời gian hơn sửa lỗi, vì vậy tôi muốn sửa lỗi trong hầu hết các trường hợp.

Thứ hai , lỗi có xu hướng có tác động nhiều hơn người ta nghĩ lúc đầu. Chúng ta đều rất quen thuộc với mã làm việc vì đây là trường hợp "bình thường". Mặt khác, lỗi là một "ngoại lệ". Tất nhiên, tất cả chúng ta đã thấy rất nhiều lỗi, nhưng chúng ta đã thấy cách làm việc nhiều mã hơn nói chung. Do đó, chúng tôi có nhiều kinh nghiệm hơn về cách hoạt động của mã làm việc so với cách mã lỗi hoạt động. Có những cuốn sách về mã làm việc và những gì nó sẽ làm trong tình huống nào. Gần như không có gì về hành vi của mã lỗi.

Lý do cho điều này rất đơn giản: Lỗi không phải là trật tự mà là sự hỗn loạn . Họ thường có một dấu vết trật tự còn lại trong họ (hoặc đặt nó theo cách khác: Họ không phá hủy hoàn toàn trật tự), nhưng bản chất lỗi của họ là phá hủy trật tự mà lập trình viên muốn. Hỗn loạn có xu hướng bất chấp được ước tính chính xác. Thật khó để nói một chương trình có lỗi sẽ làm gì hơn những gì một chương trình đúng sẽ làm chỉ vì nó không phù hợp với mô hình tinh thần của chúng ta nữa.

Thứ ba , ví dụ của bạn chứa khía cạnh sửa lỗi có nghĩa là phải thiết kế lại chương trình. . Thiết kế lại sẽ là một cách để khôi phục lại sự tin tưởng đó.

Tất cả những gì đã nói , các chương trình là những thứ mà mọi người sử dụng, và một tính năng bị thiếu hoặc một lỗi thứ hai, thực sự cồng kềnh ở nơi khác có thể được ưu tiên hơn trong việc sửa lỗi của bạn. Tất nhiên sau đó đi theo cách thực dụng và làm những việc khác trước. Nhưng đừng bao giờ quên rằng một ước tính nhanh đầu tiên về tác động của một lỗi có thể hoàn toàn sai.

Xác suất thấp / Hậu quả nhẹ = Sửa chữa linh mục thấp

• Nếu xác suất xuất hiện rất thấp
• Nếu hậu quả của sự chậm trễ là nhẹ
• Sau đó, lỗi không gây ra mối đe dọa, sau đó không phải là một sửa chữa ưu tiên.

Nhưng điều này không thể trở thành một cái nạng cho các nhà phát triển lười biếng ...

• "Độ trễ rất thấp" thậm chí có nghĩa là gì?
• "Hậu quả nhẹ" thậm chí có nghĩa là gì?

Để xác định xác suất xuất hiện rất thấp và hậu quả là nhẹ, nhóm phát triển phải hiểu mã, mô hình sử dụng và bảo mật.

Hầu hết các nhà phát triển đều ngạc nhiên rằng những điều họ nghĩ ban đầu sẽ không bao giờ xảy ra, thực sự xảy ra rất nhiều

Hệ thống giáo dục của chúng tôi không dạy xác suất và logic rất tốt. Hầu hết mọi người, bao gồm hầu hết các kỹ sư phần mềm có logic bị hỏng và trực giác dễ bị hỏng. Kinh nghiệm với các vấn đề trong thế giới thực và kinh nghiệm với các mô phỏng mở rộng là cách duy nhất tôi biết để khắc phục điều này.

Đối đầu với trực giác của bạn với dữ liệu trong thế giới thực

Điều quan trọng là tạo một số nhật ký để có thể theo các mô hình sử dụng. Điền mã với các xác nhận về những điều bạn nghĩ không nên xảy ra. Bạn sẽ ngạc nhiên khi họ làm. Bằng cách đó bạn sẽ có thể đối đầu với trực giác của mình với dữ liệu cứng và tinh chỉnh nó.

Ví dụ của tôi về một vấn đề nhẹ và một biện pháp kiểm soát

Trong một trang web thương mại điện tử mà tôi đã làm việc cách đây rất lâu, một lập trình viên khác đã mắc một lỗi: Trong một số điều kiện tối nghĩa, hệ thống đã ghi nợ khách hàng ít hơn một xu so với đăng ký trong nhật ký. Tôi phát hiện ra lỗi vì tôi đã thực hiện các báo cáo để xác định sự khác biệt giữa nhật ký và tài khoản để làm cho hệ thống kế toán trở nên linh hoạt hơn. Tôi không bao giờ sửa lỗi này vì sự khác biệt là rất nhỏ. Sự khác biệt được tính toán hàng ngày và thấp hơn US $ 2,00 hàng tháng. Thực tế là chúng tôi đã phát triển một hệ thống hoàn toàn mới mà trong một năm sẽ thay thế hệ thống hiện tại. Không có ý nghĩa để chuyển hướng các nguồn lực từ dự án có khả năng sinh lợi để sửa chữa một cái gì đó có giá US $ 2,00 hàng tháng và phải chịu một biện pháp kiểm soát thích hợp.

Phần kết luận

Có, có những lỗi không cần phải sửa ngay lập tức, điều đó không đủ quan trọng để trì hoãn phát triển tính năng mới. Tuy nhiên, hệ thống phải có quyền kiểm soát tính đại diện của lỗi này để đảm bảo nó nhỏ vì chúng ta không thể tin vào trực giác của chính mình.

Tôi nghĩ rằng đây là đặt câu hỏi sai từ đầu.

Câu hỏi không phải là "tôi nên sửa lỗi này hay tôi không nên sửa lỗi này". Bất kỳ nhà phát triển có một khoảng thời gian giới hạn. Vì vậy, câu hỏi là "điều hữu ích nhất mà tôi có thể làm trong một giờ, hoặc bốn giờ hoặc một tuần" là gì.

Nếu sửa lỗi đó là điều hữu ích nhất để làm, bởi vì nó cải thiện phần mềm với số lượng lớn nhất cho hầu hết mọi người, sau đó sửa lỗi. Nếu bạn có thể thực hiện các cải tiến lớn hơn ở nơi khác, bằng cách thêm các tính năng mà mọi người đang thiếu hoặc bằng cách sửa một lỗi quan trọng hơn, thì hãy làm những việc khác. Và điểm thưởng thêm cho bất cứ điều gì làm cho sự phát triển trong tương lai của bạn hiệu quả hơn.

Sửa lỗi luôn là một quá mức cần thiết

Trước tiên hãy phân loại phần lỗi .

Đây có phải là một lỗi trung thực không , ví dụ như lỗi một lần hoặc bóng biến đổi thoát khỏi các bài kiểm tra? Trong trường hợp này, tôi chắc chắn hy vọng rằng ngoài việc "khắc phục" sự cố bạn cũng đã viết các bài kiểm tra đơn vị mới, đã có cơ hội để cấu trúc lại mã gần đó, trong đó tất cả các công việc sau là công việc hữu ích .

Tuy nhiên, nếu đó thực sự là một lỗi thiết kế như trong trường hợp của bạn, bạn nên đánh giá lại thiết kế hoặc trong trường hợp xấu nhất, hãy tắt tính năng này.

Vì vậy, xin đừng cố gắng sửa nó.

Tất nhiên bạn có thể làm tồi tệ hơn --- bạn có thể thử phương pháp hack-upon-hack . Video looping là một hack (kiến trúc xấu và có sự phá vỡ được biết đến). Bạn có thể thêm vào một giới hạn vòng lặp , để sau N lần lặp (mà bạn đã kiểm tra nằm dưới giới hạn trình duyệt), vòng lặp chấm dứt.

Sự phân nhánh là rõ ràng, bây giờ bạn phải hỗ trợ cả mã bị hỏng và giới hạn vòng lặp mới.

PS xin lỗi cho quan điểm cực đoan.

PPS Một lưu ý về thuật ngữ: bạn không thể "sửa" một lỗi. Có lẽ một bác sĩ thú y có thể, nhưng chúng ta đừng đến đó ;-). Các vấn đề được giải quyết hoặc "sửa chữa", trong khi các lỗi được loại bỏ hoặc xử lý xung quanh.