Tôi có nên ghi lại một lỗi mà tôi đã phát hiện và vá?

Tôi cho rằng đây là một tình huống phổ biến: Tôi kiểm tra một số mã, phát hiện ra lỗi, sửa lỗi và cam kết sửa lỗi cho kho lưu trữ. Giả sử rằng nhiều người làm việc trong dự án này, trước tiên tôi nên tạo một báo cáo lỗi, tự gán nó và tham khảo nó trong thông báo cam kết (ví dụ: "Sửa lỗi #XYZ. Lỗi là do X và Y. Đã sửa nó bằng Hỏi và R ")? Ngoài ra, tôi có thể bỏ qua báo cáo lỗi và cam kết với một thông báo như "Đã sửa lỗi gây ra A khi B. Lỗi là do X và Y. Đã sửa nó bằng Q và R".

Điều gì được coi là một thực hành tốt hơn?

Nó phụ thuộc vào đối tượng của một báo cáo lỗi là ai.

Nếu nó chỉ được xem xét nội bộ bởi các nhà phát triển, để biết những gì cần được sửa chữa, thì đừng bận tâm. Đó chỉ là tiếng ồn tại thời điểm đó.

Danh sách không đầy đủ các lý do để đăng nhập bằng mọi cách:

• Ghi chú phát hành bao gồm thông tin về các lỗi cố định (đến một số ngưỡng mà lỗi này gặp phải) - đặc biệt là nếu có lỗ hổng bị lộ bởi lỗi này
• Ban quản lý muốn có một khái niệm về "Thời gian sửa lỗi" / "Số lượng lỗi được phát hiện", v.v.
• Khách hàng có thể thấy trạng thái hiện tại của bugtracker (để xem vấn đề của họ có được biết không, v.v.)
• Người kiểm tra có được thông tin về một thay đổi mà họ nên kiểm tra.

Tôi muốn nói, nó phụ thuộc vào việc sản phẩm của bạn có được phát hành với lỗi hay không.

Nếu nó được phát hành với lỗi mà bạn tìm thấy, thì có, hãy tạo một báo cáo lỗi. Chu kỳ phát hành thường có thể kéo dài và bạn không muốn lỗi của mình được báo cáo là sự cố mới trong khi bạn đã sửa nó.

Nếu lỗi của bạn chưa được chuyển đi, thì tôi sẽ không đi theo con đường tương tự. Bây giờ bạn sẽ có người cố gắng tạo lại lỗi của bạn mà họ không thể vì nó chưa được phát hành, về cơ bản là lãng phí thời gian của họ.

Bạn nên làm điều này nếu đó là một lỗi có thể được báo cáo bởi khách hàng. Trường hợp xấu nhất: Bạn sửa lỗi, nhưng không ai biết. Khách hàng báo cáo lỗi. Đồng nghiệp của bạn cố gắng sửa lỗi, nhưng không thể sao chép nó bất cứ điều gì (vì bạn đã sửa nó rồi). Đó là lý do tại sao bạn muốn ghi lại lỗi.

Nó cũng hữu ích nếu bạn thực hiện đánh giá mã, trong đó thông thường mã sẽ được viết cho một số tác vụ và sau đó được xem xét. Trong trường hợp đó, cách khắc phục lỗi đó sẽ tốt hơn, có thể yêu cầu đưa một cái gì đó vào danh sách nhiệm vụ của bạn và sau đó thực hiện tất cả công việc.

Điều này phụ thuộc vào một số yếu tố.

Cả Pieter B và Caleth đều liệt kê một số câu trả lời của họ:

• Có phải lỗi là một phần của bản phát hành chính thức?
• Số lượng lỗi / thời gian dành cho chúng được theo dõi cụ thể?

Cũng có thể có các thủ tục nội bộ để làm theo, thường được hỗ trợ bởi các yêu cầu của chứng nhận. Đối với một số chứng chỉ nhất định, bắt buộc mọi thay đổi trong mã phải có thể truy nguyên theo bản ghi trong trình theo dõi vấn đề.

Ngoài ra, đôi khi các lỗi thậm chí trông tầm thường không tầm thường và vô tội như lần đầu tiên chúng xuất hiện. Nếu bạn âm thầm bó một lỗi như vậy để phân phối một vấn đề không liên quan và lỗi sau đó trở thành vấn đề, điều này sẽ khiến việc theo dõi trở nên khó khăn hơn nhiều, chứ đừng nói đến việc cô lập hoặc hoàn nguyên.

Câu hỏi này chỉ có thể thực sự được trả lời bởi trưởng dự án của bạn, hoặc bất cứ ai chịu trách nhiệm về "quy trình tích tắc".

Nhưng hãy để tôi hỏi một cách khác: tại sao bạn không ghi lại một lỗi bạn đã vá?

Lý do có thể hiểu được duy nhất mà tôi thấy là nỗ lực nộp báo cáo lỗi, cam kết chống lại và đóng nó, là các đơn đặt hàng lớn hơn thời gian để sửa lỗi.

Trong trường hợp này, vấn đề không phải là lỗi rất dễ sửa, mà là thủ tục giấy tờ mất quá nhiều thời gian. Nó thực sự không nên. Đối với tôi, chi phí để tạo vé Jira là nhấn c, sau đó nhập tóm tắt 1 dòng ngắn và nhấn Enter. Mô tả thậm chí không phải là chi phí, vì tôi có thể cắt và dán nó vào thông điệp cam kết, cùng với số vấn đề. Vào cuối, . c <Enter>và vấn đề được đóng lại. Mà sôi xuống đến 5 phím bấm trên đầu.

Tôi không biết về bạn, nhưng điều đó đủ nhỏ để biến nó thành chính sách trong các dự án nhỏ để ghi lại mọi lỗi theo cách này.

Lợi ích rất rõ ràng - có khá nhiều người có thể dễ dàng làm việc với hệ thống bán vé như Jira, nhưng không phải với mã nguồn; cũng có những báo cáo được tạo ra từ hệ thống vé, nhưng không phải từ nguồn. Bạn chắc chắn muốn sửa lỗi của mình trong đó, để tìm hiểu về các phát triển có thể xảy ra, như một luồng lỗi nhỏ 1 dòng tăng dần, có thể cung cấp cho bạn cái nhìn sâu sắc về các vấn đề về quy trình hoặc bất cứ điều gì. Ví dụ, tại sao bạn phải thường xuyên sửa lỗi nhỏ như vậy (giả sử nó xảy ra thường xuyên)? Có thể là các bài kiểm tra của bạn không đủ tốt? Là lỗi thay đổi tên miền, hoặc lỗi mã? Vân vân.

Quy tắc tôi tuân theo là nếu phần bạn đang làm việc chưa bao giờ được phát hành và thậm chí nó chưa chạy và chưa có người dùng nào nhìn thấy, hãy sửa mọi lỗi nhỏ bạn thấy nhanh chóng và tiếp tục. Khi phần mềm đã được phát hành và đang trong quá trình sản xuất và một số người dùng đã nhìn thấy nó, mọi lỗi bạn thấy đều nhận được báo cáo lỗi và được xem xét.

Tôi đã thấy rằng những gì tôi nghĩ là một lỗi là một tính năng cho người khác. Bằng cách sửa lỗi mà không sửa các lỗi đó, tôi có thể tạo ra một lỗi thay vì sửa nó. Đưa vào báo cáo lỗi những dòng bạn sẽ thay đổi để sửa lỗi và kế hoạch của bạn về cách khắc phục.

Tóm lại: Nếu mô-đun này chưa bao giờ được sản xuất, hãy sửa mọi lỗi bạn thấy nhanh chóng và làm theo thông số kỹ thuật. Nếu mô-đun đã được sản xuất, hãy báo cáo mọi lỗi dưới dạng báo cáo lỗi cần được xem xét trước khi sửa.

Có .

Có một số câu trả lời đã phơi bày các tình huống trong đó đáng để tạo một báo cáo lỗi. Một số câu trả lời. Và chúng khác nhau.

Câu trả lời duy nhất là không ai biết. Những người khác nhau, vào những thời điểm khác nhau , sẽ có những ý kiến ​​khác nhau về vấn đề này.

Vì vậy, bây giờ, khi gặp một lỗi, bạn có hai giải pháp:

• suy ngẫm liệu có đáng để mở báo cáo lỗi hay không, có thể hỏi ý kiến ​​của đồng nghiệp ... và sau đó, trong một số trường hợp, rất tiếc rằng bạn đã không làm vì ai đó đang hỏi về nó và nếu bạn đã có báo cáo thì bạn có thể chỉ cho họ thấy điều đó
• chỉ cần tạo báo cáo

Tạo báo cáo nhanh hơn và nếu nó không ... tự động hóa nó.

Làm thế nào để tự động hóa nó? Giả sử rằng trình theo dõi của bạn hỗ trợ tập lệnh, chỉ cần tạo tập lệnh mà bạn có thể gọi và sẽ sử dụng thông báo cam kết (tiêu đề và nội dung) để gửi báo cáo lỗi và đóng ngay lập tức, với bản sửa đổi cam kết được liên kết để theo dõi.

Tôi sẽ đồng ý tất cả các câu trả lời khác đều đưa ra các quy tắc tốt và một số thậm chí chạm vào điểm này, tuy nhiên tôi nghĩ rằng chỉ có câu trả lời thực sự chắc chắn ở đây.

Chỉ cần hỏi người quản lý của bạn . Vâng, người quản lý của bạn hoặc dự án dẫn đầu dự án hoặc chủ scrum, vv tùy thuộc vào cách cấu trúc nhóm của bạn.

Có nhiều hệ thống thực hành tốt và kém khác nhau nhưng cách duy nhất để biết bạn đang làm điều đúng đắn cho nhóm của bạn là hỏi.

Một vài điều trong cuộc trò chuyện hành lang kéo dài một phút sẽ làm: "Này (sếp), nếu tôi sửa một lỗi nhỏ chỉ mất vài phút thì có đáng để đặt vé cho nó hay tôi chỉ nên đề cập đến nó trong tin nhắn cam kết của mình? " và bạn sẽ biết chắc chắn. Tất cả các thực hành tốt trên thế giới là vô ích nếu phương pháp đó làm phiền nhóm của bạn và người quản lý của bạn.