Các nhà phát triển có nên nhập lỗi vào hệ thống theo dõi lỗi?

Trong khi phát triển (cả tính năng hoặc sửa lỗi), đôi khi tôi tình cờ phát hiện ra các lỗi không liên quan trực tiếp đến những gì tôi đang làm việc. Tôi nên làm gì trong tình huống đó. Chỉ cần sửa nó? Cố gắng nhớ để sửa nó sau? Viết nó xuống đâu đó? Hoặc nhập nó vào hệ thống theo dõi lỗi?

Tôi thường nhập nó vào hệ thống theo dõi lỗi và để quá trình tự diễn ra (ví dụ như xử lý, gán, v.v.). Tuy nhiên tôi hầu như không bao giờ thấy một nhà phát triển khác nhập một lỗi. (Tại sao vậy?)

Nếu bạn phát hiện ra một lỗi, tôi không thể nghĩ ra bất kỳ lý do chính đáng nào để không nhập nó vào hệ thống theo dõi lỗi, cho dù bạn có sửa nó hay không. Rốt cuộc, đó là những gì hệ thống theo dõi lỗi dành cho.

Trong một số trường hợp, có thể có ý nghĩa hơn khi báo cáo nó cho một người QA có nhiều kinh nghiệm xử lý hệ thống, nhưng trong mọi trường hợp, lỗi phải được theo dõi.

Có thể có một số lý do, hợp lệ hoặc không, rằng các nhà phát triển không nên mắc lỗi. Một lý do có thể là hệ thống theo dõi lỗi được hiển thị cho người ngoài và có quá nhiều lỗi được báo cáo có vẻ xấu. Đó là một lý do rất xấu, cần được giải quyết theo một cách khác mà vẫn cho phép các lỗi được theo dõi. Hỏi sếp của bạn.

(Tất nhiên nếu có lỗi trong mã mà bạn vẫn đang làm việc và nó không hiển thị trong bất kỳ thứ gì được phát hành, thì không cần phải theo dõi nó trong hệ thống, mặc dù nhận xét TODO trong mã nguồn có thể là một ý tưởng hay. Để có một trường hợp cực đoan, "Mã này sẽ không được biên dịch vì tôi chưa gõ dấu chấm phẩy ở cuối dòng này" không phải là một lỗi có thể báo cáo.)

Về lý do tại sao các nhà phát triển khác không nhập lỗi, bạn sẽ cần hỏi họ. Có lẽ họ nên.

Bạn phải nhập các lỗi trong hệ thống theo dõi lỗi trong cả hai trường hợp:

• khi lỗi liên quan trực tiếp đến mã bạn đang làm việc,

• khi lỗi liên quan đến mã mà bạn không làm việc ngay bây giờ hoặc phần mà nhà phát triển khác làm việc.

Điều này rất cần thiết, vì hệ thống theo dõi lỗi được tạo ra để ... theo dõi lỗi. Mỗi lỗi. Nếu bạn phát hiện ra điều gì đó sai, đừng chỉ sửa nó. Tài liệu thông qua hệ thống theo dõi lỗi. Khi sau đó, một khách hàng chạy phiên bản phần mềm trước đó sẽ báo lỗi là một bản sao chính xác, bạn sẽ có thể liên kết nó với báo cáo của mình. Nếu bạn không có gì để liên kết, bạn sẽ lãng phí thời gian (hoặc đồng nghiệp của mình) để tìm kiếm lỗi trong các phiên bản trước, sau đó thử giải quyết và cuối cùng thấy rằng lỗi đã được giải quyết một cách kỳ diệu.

Điều này cũng giải thích tại sao các dịch giả tự do phải sử dụng cả hệ thống kiểm soát phiên bản và theo dõi lỗi: hai công cụ này không chỉ dành cho các nhóm.

Không có lý do hợp lệ để không nhập một khiếm khuyết vào hệ thống theo dõi lỗi. Những nơi duy nhất mà tôi đã thấy các bản sửa lỗi được áp dụng mà không theo dõi là vì quá trình này đã bị hỏng cơ bản. Nếu đây là trường hợp, sửa chữa quá trình.

lý do không nhập là:

• Các biện pháp xử lý và trừng phạt dựa trên báo cáo lỗi - không báo cáo, không bị trừng phạt. Trong trường hợp này rời khỏi tổ chức
• Quá trình này là một gánh nặng - phải mất quá nhiều nỗ lực và thời gian để đi vào một khiếm khuyết và đi đến điểm sửa chữa nó. Quá trình nên được thay đổi để cho phép các nhà phát triển theo dõi nhanh một lỗi nhẹ thông qua quy trình xử lý / chấp nhận / cố định.
• Một số nhà phát triển lười biếng / cẩu thả / tin tặc, những người không quan tâm đến tác động của những việc họ làm đối với người khác có thể là gì. Tuyển dụng nhà phát triển chuyên nghiệp.
• Tôi là một ban nhạc một người đàn ông, không nhìn thấy điểm. Đi làm cho một ban nhạc 2 người đàn ông và bạn sẽ ....

Sửa lỗi ngay lập tức có lẽ là một ý tưởng tồi. Đầu tiên, một người khác có thể đang làm việc trên cùng một bản sửa lỗi, dẫn đến nỗ lực trùng lặp và cũng tùy thuộc vào phương pháp phát triển mà bạn đang theo dõi, ưu tiên những gì sẽ làm tiếp theo (sửa lỗi hoặc triển khai một tính năng mới) là nhiều hơn quyết định quản lý sau đó một quyết định phát triển.

Quyết định không rõ ràng, và liên quan đến sự đánh đổi.

(một số) PROS

Theo dõi lỗi là điều cần thiết cho giao tiếp, đặc biệt là trên các đội lớn. Một trong những lợi ích tốt nhất của việc có nhiều mắt với mã là khả năng phát hiện vấn đề sớm hơn và lợi ích đó sẽ bị mất nếu lỗi không được ghi lại hoặc theo dõi khi bạn đang phát triển.

• Thông thường, các lỗi dễ dàng được sửa chữa nhất trong khi bạn đã ở trong một phần của mã, làm việc để hiểu nó.
• Ngay cả trên các đội nhỏ hơn, có rất nhiều lợi ích để có được tinh thần khôn ngoan bằng cách có thể liệt kê các lỗi và tiến bộ trong việc sửa chúng - đôi khi lợi ích tinh thần là rất quan trọng ngay cả đối với các dự án của một người đàn ông.
• Phát hiện lỗi chính xác có thể rất khó khăn sau khi thực tế - nhìn thấy một lỗi trong mã có thể tiết kiệm rất nhiều công việc sau này khi chơi thám tử, cố gắng tìm ra vấn đề ban đầu xảy ra.
• Thật tốt cho sự phát triển chung của bạn khi là nhà phát triển chú ý đến các lỗi khi bạn nhìn thấy chúng và có thói quen cải thiện / dọn dẹp / đọc mã nghiêm túc

Ghi nhật ký lỗi khi bạn tìm thấy chúng, nói chung, là một thói quen tốt cần có.

(một số)

Việc đưa các lỗi vào một hệ thống theo dõi lỗi có thể rất khó khăn và tốn thời gian, và có thể thực sự gây gián đoạn cho công việc phát triển - thường xuyên hơn khi làm việc trong các nhóm lớn. Bạn có thể được dự kiến:

• kiểm tra xem mục nhập của bạn có trùng lặp hay không trước khi nhập (điều này thậm chí có thể ẩn, việc không nhập lỗi của bạn vào hàng đợi chỉ để đóng)
• cung cấp (các) trường hợp kiểm tra lặp lại cho báo cáo của bạn
• chấp nhận các gián đoạn sau này với các câu hỏi về chi tiết lỗi, để chấp nhận / xác minh sửa lỗi khi được viết
• nghĩ về thông tin không liên quan thường được thu thập trong các hệ thống theo dõi lỗi, chẳng hạn như sản phẩm nào có khả năng bị ảnh hưởng nhất, mức độ ưu tiên của lỗi, v.v ...

Đôi khi theo dõi lỗi không chỉ là cách sử dụng hiệu quả nhất thời gian của bạn.

Đây là hai nguyên tắc chung khó có thể cân bằng - tìm ra một chiến lược tốt là một chút nghệ thuật. Trong những tình huống như thế này, tôi nghĩ tốt nhất nên áp dụng phương pháp phỏng đoán linh hoạt, tôi điều chỉnh theo yêu cầu cho một dự án nhất định, nhóm, môi trường làm việc và các kỹ năng chung của bạn. Chiến lược của tôi thường theo một mô hình như sau:

• Luôn ghi nhật ký các vấn đề khi bạn nhìn thấy chúng trong suốt cả ngày, ở đâu đó. Có thể trên một miếng dính, có thể trong một tập tin sang một bên. Có thể tất cả những gì bạn đăng nhập là tên tệp và số dòng, có thể nhiều hơn. Đừng để vấn đề làm gián đoạn dòng suy nghĩ hiện tại của bạn quá nhiều.

• Dành thời gian vào đầu mỗi ngày làm việc mới, như là một phần của sự khởi động cho công việc của bạn, để đối phó với các stickies. Tôi mất 10-15 phút để xem qua danh sách các vấn đề được phát hiện từ ngày hôm trước và thực hiện bất kỳ vấn đề nào sau đây là nhanh nhất:

  • Khắc phục sự cố và cam kết (có thể đối với một bản sửa lỗi hoặc lỗi chính tả). Nếu bạn không được phép cam kết mà không có báo cáo lỗi, hãy tạo một dự án phụ cho các cam kết nhỏ. Khi đủ các bản sửa lỗi tích lũy trong dự án phụ, hãy dành vài giờ bạn cần để ghi lại chúng và cam kết.
  • Ghi nhật ký sự cố trong hệ thống theo dõi lỗi (đối với các sự cố rõ ràng mất nhiều thời gian hơn để khắc phục nhưng không có chi phí quá cao)
  • Ghi lại sự cố trong tài liệu "để xem khi không bận" (tôi thường thêm một "// TODO - cái này có vẻ bị hỏng, sửa nó" vào nguồn). Thường xuyên mất một ngày (tôi cố gắng một lần một tháng) để xem qua danh sách và đăng nhập nó khi thích hợp - yêu cầu tính năng, báo cáo lỗi, thảo luận với người quản lý, v.v ...

Theo thời gian, tôi đã tìm thấy tất cả các loại tinh chỉnh là hữu ích. Ví dụ:

• Trong các môi trường cứng nhắc hơn, tôi có thể giảm tải công việc báo cáo lỗi cho nhóm kiểm tra - thỉnh thoảng hãy kiểm tra để gặp tôi trong một giờ, đưa cho họ danh sách các vấn đề và yêu cầu họ ghi nhật ký. Trong các môi trường mà các bài kiểm tra đăng nhập là một vấn đề lớn, thường thì người kiểm tra sẽ vui mừng vì sự tăng cường miễn phí cho năng suất của họ.
• Một số nhóm từ chối cho phép mọi sửa lỗi không có báo cáo lỗi của khách hàng đằng sau chúng. Tôi sẽ giữ một dự án đầy đủ các bản sửa lỗi ở bên cạnh và ngay lập tức cam kết chúng khi vấn đề liên quan được báo cáo bởi khách hàng, cho các điểm brownie miễn phí.
• Một số đội yêu cầu người "sở hữu" một đoạn mã phải là người sửa lỗi. Tôi sẽ coi mã "chủ sở hữu" như một khách hàng tiềm năng thử nghiệm và thỉnh thoảng gặp gỡ để xử lý các vấn đề

Tôi thấy rằng, nói chung, khi bạn theo loại chiến lược này, ngày càng nhiều đồng nghiệp và các thành viên khác trong công ty sẽ bắt đầu tôn trọng công việc của bạn và cam kết chất lượng. Sau đủ thời gian, bạn sẽ có sự tôn trọng và quyền hạn cần thiết để tối ưu hóa toàn bộ quy trình theo ý thích của bạn. Giữ một mắt ra cho những cơ hội như vậy, và đưa chúng khi thích hợp.

Tôi tin rằng nếu nhà phát triển gặp phải một lỗi không liên quan đến những gì họ đang làm việc và họ sẽ không sửa, họ nên nhập nó vào hệ thống chỉ để có một bản ghi về nó. Theo cách đó, khi QA bắt đầu thử nghiệm (và chúng vẫn chưa được sửa), bạn có thể cung cấp cho chúng danh sách lỗi này dưới dạng "lỗi đã biết" để chúng không bắt đầu báo cáo các lỗi tương tự.

Có lẽ các nhà phát triển khác tìm thấy lỗi sẽ tự mình theo dõi nếu họ có kế hoạch sửa nó, nhưng trong trường hợp đó, họ có nguy cơ 2 nhà phát triển độc lập tìm và sửa cùng một lỗi.

Tôi sẽ nói thêm rằng ngay cả khi lỗi đã được sửa (điều không nên xảy ra trước khi ghi nó vào trình theo dõi vấn đề), đó là một ý tưởng tốt để theo dõi nó.

Bằng cách này, nếu vấn đề sẽ phát sinh trở lại trong tương lai (hồi quy xảy ra!) Thì tương đối dễ dàng nhận ra vấn đề là "đã được xử lý" và đọc cách khắc phục lần đầu tiên.

Tại sao vậy? Bởi vì hầu hết các nhà phát triển nhìn vào vấn đề họ phải nêu ra và mã họ phải viết và hình dung nó không dễ làm phiền hơn.

Nhưng, liệu đó có phải là điều đúng hay không phụ thuộc vào quá trình của bạn. Bạn có đội QA không? Bạn có nghĩ rằng họ phiền nếu bạn chỉ thay đổi mã sẽ không bị theo dõi? Những gì về đánh giá mã? Nó sẽ bỏ qua bởi vết nứt đó? Còn doanh nghiệp thì sao? Họ có cần biết bạn đã sửa một lỗi để sau này họ không phát sinh lỗi không?

Còn các nhà phát triển khác thì sao? Điều gì xảy ra nếu họ sửa nó theo một cách khác cùng một lúc? Điều gì sẽ xảy ra nếu sau đó họ tìm thấy một lỗi tương tự và tất cả những gì bạn có thể làm là nói "ồ, chết tiệt, tôi biết chúng ta đã có một cái gì đó như thế này trước đây - bây giờ nó là gì?"

Có khoảng một triệu lý do để ghi lại lỗi trong hệ thống theo dõi lỗi. Nếu bạn CHẮC CHẮN, bạn không gặp phải bất kỳ vấn đề nào trong số đó, thì đừng bận tâm. Nhưng nếu bạn không chắc chắn thì bạn nên ghi lại, ngay cả khi hầu hết mọi người không.

Lập trình là một công việc phức tạp về cơ bản. Các lỗi rất phức tạp. Vì vậy, tôi đã sử dụng để đánh giá một lỗi theo hai yếu tố:

1. Làm thế nào thường xuyên loại lỗi như vậy có thể xuất hiện một lần nữa trong tương lai? Cho dù ước tính này là chính xác hay không, hãy tiếp tục ước tính.
2. Khi loại lỗi như vậy xuất hiện trở lại, nó có dễ hiểu không? Điều này là chính xác khi bạn phân tích lỗi này và sửa nó.

Tôi sẽ phân loại một lỗi thành một trong các loại sau:

1. Có khả năng xuất hiện trở lại trong tương lai và dễ hiểu
2. Có khả năng xuất hiện trở lại trong tương lai, nhưng khó hiểu
3. Hiếm khi xuất hiện trở lại trong tương lai, và dễ hiểu
4. Hiếm khi xuất hiện trở lại trong tương lai, nhưng khó hiểu

Trong trường hợp 1, sách dạy nấu ăn hoặc Câu hỏi thường gặp là một thiết bị tốt để nhóm khắc phục các lỗi đó trong tương lai.

Trong trường hợp 2, một bản ghi công phu và dễ hiểu là cần thiết cho nhóm vì sẽ lãng phí công sức nếu một lập trình viên khác chịu đựng các lỗi như vậy một lần nữa. Ví dụ: rò rỉ bộ nhớ.

Trong trường hợp 3, tôi nghĩ đó không phải là vấn đề lớn khi không còn gì để ghi lại vì bạn sẽ không mất quá nhiều thời gian để sửa một lỗi dễ dàng. Ví dụ: một lỗi đánh máy cho id của phần tử trong HTML.

Trong trường hợp 4, các lỗi như vậy tạo ra một vấn đề nan giải. Nó cần một chút thời gian để viết một bản ghi công phu và dễ hiểu để mô tả các lỗi như vậy. Nhưng hồ sơ này hiếm khi được sử dụng trong tương lai. Tuy nhiên, nếu không có hồ sơ, việc xuất hiện những lỗi như vậy sẽ lại là một cuộc đấu tranh. Ví dụ: các lỗi như vậy xuất hiện do vi-rút máy tính trong máy tính của ai đó.

Tất nhiên bạn nên nhập nó. Hoặc ít nhất là báo cáo cho người QA của bạn nếu đó là quá trình bình thường của bạn.

Ngay cả khi bạn chỉ tự sửa lỗi, bạn sẽ muốn có một bản ghi về sự thay đổi để sau đó có thể kiểm tra để đảm bảo rằng bản sửa lỗi thực sự hoạt động và đã không có hồi quy. Người dùng cũng có thể báo cáo lỗi tại một số điểm và nếu nó trong hệ thống và được đánh dấu là đã sửa, những người hỗ trợ của bạn có thể nói với họ rằng nó đã được xử lý.

Thật vậy, bạn nên ghi lại chúng trong hệ thống, và trong trường hợp nó không được thực hành thì thật tốt khi bắt đầu.

Trước đây, tôi là thành viên của một nhóm sản phẩm và chúng tôi đã phát hành phiên bản beta của một sản phẩm mới và đôi khi chúng tôi thỉnh thoảng phát hiện ra các lỗi mà tại đó chúng tôi thường ghi chú và gửi thư cho những người tương ứng xử lý các mô-đun (chúng tôi có một hệ thống theo dõi lỗi, nhưng chúng tôi đã không nghĩ đến việc đẩy chúng ở đó). Sau này khi nhiều ngày trôi qua, các mục trong thư bắt đầu bị bỏ qua vì những ưu tiên khác và cuối cùng dẫn đến một số đêm mất ngủ.

Sau đó, đập một ngày, Niết bàn! Tại sao chúng tôi không sử dụng trình theo dõi lỗi, ngay cả khi bạn tìm thấy thứ gì đó có vẻ giống như lỗi và có thể đó không phải là lỗi (suy nghĩ của bạn về quy trình này là sai / thiếu sót). Nó ít nhất chiếm trong danh sách mà sau đó có thể được kiểm tra và quan trọng nhất trong tất cả các phản hồi về lý do tại sao nó quan trọng hoặc mặt trái của nó là hoàn hảo và đó là cách nó nên hoạt động vì lý do 1 ... 2 ... .

Bây giờ bạn có danh sách và cũng cho những người đã hiểu sai một số phần của ứng dụng, họ có phản hồi dựa trên đó họ có thể làm rõ suy nghĩ của họ. Chiến thắng nghịch cảnh.

Giả sử mã đã được thử nghiệm (và đặc biệt nếu được phát hành) hoàn toàn.

Có một số lý do cho việc này:

Bộ nhớ - Hệ thống thực sự không thể quên lỗi, bất kỳ nhà phát triển nào cũng có thể.

Số liệu - Số lượng lỗi được tìm thấy, đã đóng và thời gian thực hiện có thể là số liệu dễ nắm bắt tốt để cho bạn biết chất lượng mã của bạn đang tiến triển như thế nào

Tính cấp thiết - Có vẻ như là điều quan trọng nhất trên thế giới đối với nhà phát triển, tuy nhiên thời gian dành cho việc khắc phục vấn đề này có thể được dành tốt hơn cho thứ gì đó mà người dùng cuối muốn trước (xem thêm bộ nhớ).

Sao chép - Có thể nó đã bị phát hiện và đang được người khác kiểm tra / sửa chữa. Mặt khác, nó có thể đã phạm lỗi của quy tắc khẩn cấp và đã được đưa ra. Tất nhiên, thực tế là bạn đã tìm thấy nó một lần nữa không có nghĩa là nó không nên được thực hiện, điều đó có thể có nghĩa là (vì nó tiếp tục phát triển) hiện đang khẩn cấp hơn để khắc phục.

Phân tích nguyên nhân gốc rễ - Lỗi dễ khắc phục nhất là lỗi chưa từng có. Có thể là nhóm nên xem xét lỗi này để tìm hiểu xem nó đã xảy ra như thế nào. Đây là definativley không phải để trừng phạt người chịu trách nhiệm (điều đó không bao giờ giúp đỡ) mà để tìm hiểu làm thế nào có thể tránh được tình huống trong tương lai.

Phân tích tác động rộng hơn - Lỗi rẻ nhất để tìm là lỗi bạn đã biết trước khi tìm thấy. Bằng cách xem xét lỗi này (đặc biệt là sau khi thực hiện phân tích nguyên nhân gốc), có thể nhanh chóng thấy rõ rằng vấn đề này có thể tồn tại ở những nơi khác trong mã. Kết quả là nhóm có thể chọn đi tìm nó trước khi nó ngẩng cái đầu xấu xí của mình vào một thời điểm đáng xấu hổ hơn.

Lượng thời gian dành cho những điều này (nếu có) phần lớn phụ thuộc vào mức độ trưởng thành và chất lượng của mã. Phân tích nguyên nhân gốc rễ có thể là quá mức cần thiết cho một nhóm nhỏ làm việc về mã trình diễn, nhưng một nhóm lớn về phát triển quan trọng trong kinh doanh có lẽ cần phải học các bài học một cách hiệu quả và hiệu quả.

Từ kinh nghiệm, có hai lý do rộng rãi mà các nhà phát triển tránh sử dụng công cụ:

1. Công cụ xử lý lỗi và / hoặc quy trình được coi là quá nặng cho sự phát triển
2. Các nhà phát triển tìm thấy thử thách tinh thần trong việc sửa lỗi thú vị hơn những thứ họ đang làm.

Mục 1 ngụ ý rằng một hệ thống tốt hơn / đơn giản hơn có thể được yêu cầu; hoặc cách khác, một sự biện minh hấp dẫn hơn của hệ thống hiện tại có thể theo thứ tự.

Mục 2 phải là một dấu hiệu cảnh báo hữu ích cho lãnh đạo phát triển về phân bổ nhiệm vụ hiện tại.

Tôi hầu hết đồng ý với FrustratedWithFormsDesign nhưng tôi nghĩ nó còn rõ ràng hơn nếu toàn bộ vấn đề được chia thành hai lĩnh vực:

• Báo cáo lỗi.
• Sửa lỗi.

Chúng thường được coi là giống nhau và tách chúng ra gần như chắc chắn sẽ giúp ích rất nhiều.

Chúng có thể được xử lý với: Báo cáo lỗi: - đưa nó vào hệ thống, như mọi người nói.

Sửa lỗi: - Mỗi tuần hoặc hai tuần (điều chỉnh lịch trình phát triển của bạn, v.v.) mọi người cùng tham gia vào dự án và quyết định nên sửa cái gì, bởi ai, v.v ... Đây là tất cả mọi người ở trên cùng một trang và có thể thấy những gì cần được thực hiện. Trong Agile Development, đây là cuộc họp Lập kế hoạch Sprint.

Một công cụ tốt mà mọi người muốn sử dụng cũng tạo ra sự khác biệt lớn. Tôi thích Pivotal Tracker và nó đã vượt qua bài kiểm tra 'công cụ thực sự hữu ích' của tôi khi tôi bắt đầu sử dụng nó chỉ để theo dõi những điều tôi muốn làm hoặc sửa chữa trong các dự án riêng của mình!

Nếu bạn thấy một cái gì đó thì hãy nói điều gì đó!

Tôi thậm chí nhập các báo cáo lỗi về các mô-đun của riêng mình vì tôi không muốn làm gián đoạn nhiệm vụ hiện tại của mình. Và tôi có thể đảm bảo tất cả các bước để sao chép được bao gồm :-)

Và thậm chí còn tốt hơn khi người khác có thể thấy rằng bạn đã liệt kê một cái gì đó là một lỗi đã biết. Họ muốn biết người khác cũng đã tìm thấy nó.

Tôi nghĩ rằng đây là một câu hỏi chính trị nhiều hơn là một câu hỏi về bestpractice.

• không có lỗi đổ lỗi cho sombody?
• khách hàng có thể đọc các mục lỗi và thấy rằng có lỗi về mặt quảng cáo. Đây có phải là một vấn đề danh tiếng cho công ty của bạn?
• Đây thực sự là một lỗi hay một tính năng mà bạn không biết?
• Ai sẽ trả tiền sửa lỗi?

Theo tôi, đó là một cách tốt để thêm các lỗi không tầm thường vào hệ thống theo dõi nhưng ban quản lý phải quyết định cách đối phó với điều này.

Đối với các trường hợp không tầm thường, bạn không nên khắc phục sự cố mà không hỏi ý kiến ​​người khác để đảm bảo rằng

• Đây thực sự là một lỗi và không phải là một tính năng
• sombody khác có thể kiểm tra bản sửa lỗi và đảm bảo rằng bản sửa lỗi không giới thiệu một lỗi mới khác (hồi quy)