# 38: Làm thế nào để săn bug?
Dù cho bạn có gọi là lỗi, dị tật, hay kể cả tác dụng phụ thiết kế, thì bạn chả có một cách nào thoát khỏi chúng. Hiểu cách để nộp một bản báo lỗi tốt và biết nên tìm kiếm gì trong đó, là một trong những kỹ năng then chốt giúp project của bạn phát triển một cách trơn tru.
Một bản báo cáo lỗi tốt gồm có ba điều:
- Nguyên nhân gây ra lỗi, càng chi tiết càng tốt, và tần suất xuất hiện của chúng.
- Chúng ta nên thực hiện điều gì, ít nhất là ý kiến của bạn.
- Điều gì đã xảy ra trong thực tế, hoặc ít nhất là những thông tin mà bạn đã ghi nhận được.
Số lượng và chất lượng của toàn bộ thông tin được báo cáo về lỗi đấy không chỉ giúp ta hiểu về bug mà còn giúp ta hiểu hơn về người phát triển. Sự tức giận, chửi bugs(“hàm này như hạch”) cho những nhà phát triển rằng bạn đang có một khoảng thời gian tồi tệ, và đó là tất cả. Một bug với phạm vi rộng khiến nó dễ dàng nhân lên và rồi nhận được sự dè chừng của mọi người ngay cả khi chúng dừng hoạt động.
Các lỗi ấy giống như những cuộc hội thoại, với tất lịch sử ngay đó trước mặt mọi người. Đừng đổ lỗi cho người khác và phủ định sự tồn tại của nó. Thay vào đó hãy hỏi để có thêm thông tin hay tiểu hiểu xem mình đã bỏ lỡ điều gì.
Đầu tiên, hãy thay đổi trạng thái của bugs, v.v… chuyển chúng từ hoạt động sang kết thúc, đó là mệnh đề bạn đặt ra khi nghĩ về bug. Hãy dành thời gian để giải thích lý do để ngăn chặn nó sẽ giúp bạn tiết kiệm hàng giờ tẻ nhạt ngồi chỉnh sửa để rồi làm cho khách hàng và quản lý thất vọng. Thay đổi sự ưu tiên của một bug cũng chính là câu hỏi chung, và chỉ vì nó tầm thường với bạn không có nghĩa là nó không ngăn cản người khác sử dụng sản phẩm.
Thứ hai, đừng khiến việc tìm hiểu về mảng trục trặc bị quá tải bởi lý do cá nhân của bạn. Thay vào đó bạn hãy thử thêm từ “quan trọng” vào trước một chủ đề về một mảng của lỗi có thể giúp bạn dễ dàng thực hiện việc sắp xếp kết quả đến từ một vài bản báo cáo, nhưng đột nhiên chính việc ấy lại trở thành bản copy của các bản báo cáo khác và chắc chắn rằng đó không phải là điều mà bạn mong muốn, hoặc là bạn có thể xoá bớt 1 số mảng ấy để nó phù hợp hơn với mục đích sử dụng ở các bản báo cáo khác. Thay vào đó chúng ta hãy sử dụng một giá trị khác hay một mảng khác để đánh giá lỗi, và tìm hiểu về mục đích của mảng đó để những người khác không phải tự thực hiện lại công việc này.
Chúng ta phải chắc chắn rằng bất kỳ ai cũng có thể dễ dàng phát hiện được lỗi mà cả team chúng ta đang làm việc với nó. Việc này thường có thể được hoàn thành nhờ vào sử dụng một query cụ thể chung. Đồng thời, việc đảm bảo mọi người dùng chung query vô cùng quan trọng và không được cập nhật nó nếu chưa có sự đồng ý đến từ tất cả mọi người trong nhóm.
Cuối cùng hãy luôn ghi nhớ rằng bugs không phải là đơn vị chuẩn của công việc hay của từng dòng code mà chính bugs là đơn vị đo lường chính xác sự nỗ lực tuyệt vời của bạn.