Chắc trong cuộc đời làm developer, ai đó cũng đôi lần fix bug này lòi bug kia, sửa chỗ này mà không sửa chỗ kia, rồi chắc cũng thất kinh khi khách hàng báo cụm từ DEGRADE. Tôi thì đã khá nhiều lần tái xanh mặt từ quân cho tới lính khi khách hàng báo bug DEGRADE.
Sau dần cũng phọt ra những quy tắc, cách làm nhất định để hạn chế tối đa mấy vụ này.
Thực ra nó cũng chẳng có gì đao to búa lớn cả, các bạn có thể chép nó trên 1 2 sticker dán vào màn hình và nhìn, làm theo hàng ngày mỗi khi xử lý các vấn đề của dự án.
Bộ câu hỏi sau được tôi sử dụng nhiều theo thứ tự xử lý các tác vụ:
1. Chức năng này có ảnh hưởng tới các chức năng nào khác trong cùng một hệ thống?
2. Sửa chữa, làm mới chức năng này như thế nào để không ảnh hưởng tới chức năng cũ đang chạy ổn định?
3. Tôi đã log lại các chỗ, các chức năng tôi đã sửa chữa chưa?
4. Khi commit lên svn, git, tôi xem lại 1 lượt all các file đã thay đổi, các chỗ thay đổi trong file đó đã hợp lý hay chưa. Tưởng đơn giản vậy mà đôi lần cũng phát hiện ra những lỗi sơ đẳng như var_dump, echo quên ko xoá 😀
5. Ghi log cẩn thận, kèm ID issue khi commit
(Cái số 5 này quan trọng lắm nhé. Các ông cứ ghi comment kiểu "Fix bug", xong đến lúc cần điều tra lại về issue đó, tôi đố các ông tìm được đúng revision đã sửa đấy 😀 )
Mấy câu hỏi trên tôi dùng cho chính mình khi xử lý, tuy nhiên việc thông báo cho tester cũng quan trọng lắm nhé.
Trước khi solved issue để đưa cho tester/PO xác nhận thì nên làm gì nhỉ?
Tôi ghi rõ ràng comment vào trong issue và assign lại cho tester với nội dung đơn giản sau:
– Danh sách chức năng bị ảnh hưởng trong lần sửa chữa này
– Tôi đã test issue này và test lại toàn bộ chức năng khác bị ảnh hưởng trong lần sửa chữa này chưa?
Trên đây là một vài thao tác tôi thường làm mỗi khi phải xử lý issue từ ngày xưa. Bây giờ công cụ, tools thay đổi nhiều, việc lập trình có thể đơn giản hoặc phức tạp hơn, tuy nhiên tôi cho rằng cách tư duy trên vẫn còn nguyên giá trị.
Xin chia sẻ lại với anh em 😀