Bug là gì? Những lợi ích tới từ việc “chiến đấu” có bug là gì? Đấy là 1 câu hỏi ko mấy vui vẻ, bởi có lẽ gần như lập trình viên đều muốn khiến tính năng new, chứ chả mấy ai thích buộc phải bảo trì siêu phẩm có sẵn hay là repair bug.
Tune, có cá nhân tôi, việc tìm và repair bug đem lại siêu nhiều niềm vui cũng như thời cơ học hỏi, vươn lên là nghề nghiệp. Sau đây là 1 số tổng kết của tôi về:
- Bug là gì? 4 lợi ích của việc repair bug
- Phương pháp ghi lại bug hiệu quả
- 3 bài học lớn và 18 kinh nghiệm xương máu về repair bug
Xem việc khiến Developer chất tại ITviec
Learn the English model right here.
Bug là gì? Debug là gì? Fixbug là gì?
Bug là gì? Bug là những lỗi phần mềm trong chương trình hoặc hệ thống máy tính khiến cho kết quả ko chính xác hoặc ko hoạt động như mong muốn. – Theo Wikipedia
Debug là quy trình kiếm tìm và tìm ra lỗi trong phần mềm trước lúc launching, đưa siêu phẩm tới tay khách hàng. Debug diễn ra ngay sau khoản thời gian những dòng code trước tiên được viết và tiếp tục được thực hành cho tới lúc hài hòa có những unit khác của lập trình tạo thành 1 sản phầm phần mềm hoàn chỉnh.
Fixbug (sửa lỗi) là quy trình triển khai ngay sau debug, nhằm duy trì hoặc nâng cao chất lượng siêu phẩm.
Những loại bug phổ thông} nhất
Theo Browserstack, có 6 loại bug phổ thông} mà những developer thường gặp buộc phải nhất:
1. Bug chức năng (Purposeful Bug)
Những lỗi chức năng được hợp tác có chức năng của 1 thành phần phần mềm cụ thể. Thí dụ: Nút Đăng nhập ko cho phép khách hàng đăng nhập, nút Thêm vào giỏ hàng ko cập nhật giỏ hàng, hộp kiếm tìm ko phản hồi truy vấn của khách hàng, v.v.
Nói 1 phương pháp dễ hiểu, bất kỳ thành phần nào trong ứng dụng hoặc trang net ko hoạt động như dự kiến đều được gọi là bug chức năng.
2. Bug logic (Logical Bug)
Thông thường, lỗi logic sẽ khiến gián đoạn quy trình khiến việc dự kiến của phần mềm và khiến cho ứng dụng hoạt động ko chính xác. Những bug này có thể dẫn tới hành vi phần mềm ko mong muốn và thậm chí là sự cố đột ngột.
Lỗi logic chủ yếu xảy ra do developer diễn giải sai logic của ứng dụng. Thí dụ về lỗi logic bao gồm:
- Gán giá trị cho biến sai
- Chia 2 số thay đổi vì cùng chúng có nhau dẫn tới kết quả ko mong muốn
3. Bug quy trình khiến việc (Workflow Bug)
Lỗi quy trình khiến việc được hợp tác có hành trình của khách hàng (điều hướng) của 1 ứng dụng phần mềm. Ta lấy dí dụ về 1 trang net để khách hàng điền biểu mẫu về lịch sử y tế của họ. Sau thời điểm điền vào biểu mẫu, khách hàng có bố tùy thuộc} chọn để lựa chọn:
- Lưu
- Lưu và thoát
- Trang trước
Từ những tùy thuộc} chọn có sẵn, ví dụ khách hàng nhấp vào “Lưu và thoát”, khách hàng có ý định lưu thông tin đã nhập và tiếp theo thoát. Tuy nhiên, ví dụ nhấp vào nút Lưu và Thoát dẫn tới việc thoát khỏi biểu mẫu mà ko lưu thông tin, đấy chính là tới bug liên quan tới quy trình khiến việc.
4. Bug cấp đơn vị (Unit Degree Bug)
Những bug tại cấp độ đơn vị siêu phổ thông} và chúng thường dễ sửa hơn. Lúc những module ban đầu của những thành phần được vươn lên là, developer sẽ thực hành unit testing để đảm bảo rằng những đoạn code bé đang hoạt động như mong đợi. Đây là giai đoạn mà những developer gặp buộc phải nhiều bug khác nhau ko được tìm ra trong những giai đoạn viết mã.
Thí dụ: Trường hợp bạn cần tạo biểu mẫu 1 trang, unit check sẽ xác minh xem đa số những trường đầu vào có chấp nhận đầu vào thích hợp hay ko và những nút hoạt động đúng chức năng hay ko. Trong trường hợp 1 trường ko chấp nhận những ký tự động hoặc số thích hợp, những nhà vươn lên là sẽ gặp buộc phải bug cấp đơn vị.
Những bug tại cấp độ đơn vị dễ xác định hơn lúc developer chỉ cần xử lý 1 lượng code tương đối bé. Developer có thể theo dõi lỗi chính xác và repair những bug này ngay tức thời.
5. Bug tích hợp cấp hệ thống (System-Degree Integration Bug)
Bug tích hợp cấp hệ thống chủ yếu xuất hiện lúc 2 hoặc nhiều đơn vị code do những developer khác nhau viết ko tương tác có nhau. Những bug này chủ yếu xảy ra do sự mâu thuẫn hoặc ko tương thích giữa 2 hoặc nhiều thành phần.
Thông thường, những lỗi như vậy siêu khó theo dõi và repair vì những nhà vươn lên là cần đánh giá 1 đoạn code lớn hơn. Chúng cũng tốn nhiều thời kì để tái tạo.
Sự cố tràn bộ nhớ và giao diện ko thích hợp giữa giao diện khách hàng ứng dụng và cơ sở dữ liệu là những dí dụ phổ thông} về lỗi tích hợp cấp hệ thống.
6. Bug bên cạnh giới hạn (Out of Certain Bug)
Lỗi bên cạnh giới hạn xuất hiện lúc khách hàng hệ thống tương tác có giao diện khách hàng theo phương pháp ko chủ ý. Những lỗi này xảy ra lúc khách hàng cuối nhập 1 giá trị hoặc 1 tham số nằm bên cạnh giới hạn dùng bên cạnh ý muốn.
Thí dụ: Người mua nhập 1 số siêu lớn hoặc siêu bé hoặc nhập giá trị đầu vào của 1 kiểu dữ liệu ko xác định.
Những bug này thường xuất hiện dưới dạng xác thực trong quy trình đánh giá chức năng của ứng dụng net hoặc cellular app.
Lợi ích của việc gặp bug là gì?
Trong từng trường hợp, bạn đều có thể học đôi điều về phong phương pháp lập trình, siêu phẩm hoặc về lĩnh vực mà phần mềm đang hoạt động.
Trên hết, có 4 lí do chính, cũng là 4 niềm vui quan yếu nhất mà việc repair bug có thể đem lại cho lập trình viên như sau:
Từng bug luôn dạy bạn điều gì đấy
Suggestions luôn là chìa khóa của vươn lên là siêu phẩm và đồng thời cũng là triết lý cốt lõi của mô hình agile.
Cả unit testing và iterative growth đều nhằm đưa ra suggestions nhanh hơn. Sở hữu unit testing, bạn nhận được suggestions về việc code có chạy hay ko. Sở hữu từng launch, bạn có thể lắng nghe suggestions của khách hàng về những tính năng new.
Báo cáo bug cũng là hình thức suggestions khác về code của bạn.
Có thể có siêu nhiều nguyên nhân gây ra 1 bug. Thí dụ:
- Bạn có những câu lệnh if lồng nhau và vô tình lại đặt lệnh else tại sai nhánh.
- Giả định ko chính xác. Chẳng hạn: truy xuất 1 thuộc tính ko tồn tại, thế là dính NullPointerException
- Ko bao quát hết những trường hợp. Chẳng hạn, bạn buộc phải trả về 1 giá trị khác đi ví dụ hàm được gọi có tham số X
- Hoặc, khách hàng dùng phần mềm theo phương pháp mà bạn ko ngờ tới (nhưng vẫn hợp lệ), và thế là bùm! Dính bug!
Đào sâu tìm hiểu nguyên nhân gây ra bug, bạn sẽ đúc kết được nhiều bài học quý giá.
Code của bạn sẽ dễ debug hơn
1 lúc đã buộc phải bỏ công sức, thời kì ra để tìm và repair bug, tự động khắc bạn sẽ muốn viết code càng dễ debug càng phải chăng. Bởi vì sẽ siêu khốn khổ ví dụ ko có mọi dữ liệu cần thiết.
1 vấn đề cực kì dễ gặp là những Exceptions (biệt lệ) ko chứa dữ liệu hữu ích.
Thí dụ như, có 1 đoạn code bắc buộc giá trị từ 0 – 20. Bao nhiêu lần bạn dính exception chỉ vỏn vẹn “Unlawful worth”? Nó hoàn toàn không hỗ trợ gì ví dụ bạn buộc phải sửa lỗi. Chẳng hạn, ví dụ như giá trị 21 được nhập vào, exception nên nói là “Unlawful worth: 21, not in vary 0 – 20”.
Việc hiển thị giá trị được nhập vào cùng có khoảng giá trị mong muốn, rõ ràng vô cùng hữu ích. Giá trị hiện tại có thể là 21, -128 hay 65535. Chúng đều giúp bạn có manh mối để tìm ra lỗi, hơn là dòng “Unlawful worth” ngắn gọn.
Ngay cả Steve McConnell thi thoảng cũng phá luật này trong cuốn sách tuyệt vời Code Full. Chẳng hạn, trong chương 15, McConnell nêu ra vấn đề tìm ra 1 kiểu ký tự động ko mong muốn, nhưng thông tin lỗi lại ko hiển thị ký tự động đấy.
Như vậy, từng lúc tìm và repair bug, bạn cần tự động hỏi: liệu có thể thay đổi đổi điều gì trong code để sau này ko gặp buộc phải những bug dạng này ko? Liệu có phương pháp nào hoặc điều gì mình nên khiến, để sau này tìm ra những bug dạng này dễ dàng hơn ko?
Việc khiến Developer TP. HCM
Việc khiến Developer Hà Nội
Repair bug đem lại niềm vui cho cả bạn và khách hàng
1 trong những niềm vui mà công việc lập trình mang trong mình lại, theo tôi, đấy là khiến điều có ích cho người khác. Repair bug cũng đem tới niềm vui tương tự động, và thậm chí còn nhanh chóng hơn.
Bởi lẽ, để tạo ra 1 tính năng new cần tốn khá nhiều thời kì, trong lúc việc repair 1 bug có thể chỉ cần 1 giờ đồng hồ. Từng bug được repair xong sẽ đem tới khoái cảm đã hoàn thành/đạt được điều gì. Và đấy là 1 cảm giác tuyệt vời!
Repair bug cũng đem lại niềm vui cho khách hàng (dù nghe có vẻ oái oăm). Trường hợp ngay từ đầu ko có bug, ko buộc phải repair bug, thì chẳng buộc phải khách hàng sẽ vui hơn sao?. Nhưng, từ kinh nghiệm hơn 20 5 lập trình và “chiến đấu” có bug, tôi dám khẳng định: khách hàng thực sự hài lòng từng lúc nhận về bug đã được repair xong nhanh chóng.
Vấn đề là vậy: Mọi mọi người đều biết SẼ LUÔN CÓ BUG! Cho nên, miễn là có người sẵn sàng repair thực nhanh ngay lúc bug được khui ra.
Thư giãn có video: Repair bug “chất” như Vinh Râu
Niềm vui của việc giải câu đố
Siêu nhiều lập trình viên thích giải câu đố, như chơi trò Sudoku, giải ô chữ, giải đố vui toán học, hay tham dự những thử thách lập trình.
Thậm chí, đọc truyện trinh thám làm thịt người cũng đem lại siêu nhiều hứng khởi: bạn lần theo những manh mối để tìm hiểu mọi chuyện đã diễn ra như thế nào.
Debug và repair bug cũng vậy. Từng bug là 1 bí mật cần khám phá.
Thông thường, phản ứng trước tiên của bạn lúc trông thấy 1 báo cáo bug sẽ là: Ko thể nào! Tại sao có thể xảy ra bug này được?!?
Và cũng từ đấy, bạn khởi đầu hành trình khám phá bí mật. Bạn lần theo những manh mối. Logs nói gì? Có báo cáo lỗi nào từ hệ thống ko? Tại thời điểm đấy, hệ thống có xảy ra vấn đề gì khác hay ko? Sắp đây có mẫu gì bị thay đổi đổi ko – phần mềm new, thay đổi đổi cấu hình, lưu lượng truy cập liên quan?
Phương pháp hiệu quả nhất để ghi lại bug là gì?
Nguyên nhân của việc cần buộc phải ghi lại bug là gì? Để bạn có thể học hỏi hiệu quả nhất từ những bug bạn đã repair. Phương pháp mà tôi dùng là luôn dành ra vài phút để ghi chú lại những thông tin: mô tả bug, phương pháp repair, bài học kinh nghiệm.
Nguyên tắc
- Chỉ ghi chú những bug khó nhằn hoặc thực sự thú vị. Đây ko buộc phải là bug tracker.
- Ghi chú những bug do chính mình gây ra. (Trừ trường hợp bug của người khác nhưng đủ thú vị).
- Ghi lại bug ngay sau khoản thời gian repair xong. Hạn chế nhớ nhầm, nhớ ko chi tiết.
Phương pháp ghi lại bug
Tôi thường dùng type dưới đây để ghi lại bug dưới dạng file textual content (bugs.txt). Bạn có thể tham khảo thông qua dí dụ sau:
Thông tin nền:
- Ngày: 2004-08-17
- Triệu chứng: Vòng lặp vô tận lúc giải mã tín hiệu Q.931.
- Nguyên nhân: Lúc tìm thấy id của 1 thành phần chưa biết trong tín hiệu Q.931, ta tìm phương pháp bỏ qua nó bằng phương pháp lấy chiều dài, và đi lại con trỏ pos tương ứng có độ dài tìm được. Tuy nhiên, có trường hợp độ dài bằng 0 khiến ta liên tục bỏ qua cùng 1 id.
- Phương pháp tìm ra: Nhờ có vào phân tách tín hiệu SETUP lấy từ hint của Ethereal tại Nortel. Tín hiệu của họ có độ dài 1016 bytes, nhưng MSX_MAX_LEN chỉ có 1000. Bình thường ta sẽ nhận 1 tín hiệu bị cắt từ widespread/Communication.cxx, nhưng tại đây lúc phân phối dữ liệu quản lý để phân tách, khoảng bộ nhớ vượt quá array bị truy cập, và vô tình nó bằng 0, khiến xuất hiện lỗi. Để sửa lỗi, tôi đã thêm vào vài lệnh print trong phần code phân tách Q.931. Nhưng might mắn là dữ liệu lại bằng 0.
Phương pháp sửa – Quy trình sửa:
- Sửa: Trường hợp chiều dài tìm thấy bằng 0, đặt nó lại bằng 1. Như vậy chúng ta sẽ luôn đi tiếp được.
- Sửa trong file(s): callh/q931_msg.cxx
- Thủ phạm là tôi: Đúng vậy.
- Thời kì sửa bug: 1 giờ.
Bài học rút ra được:
- Bài học: Đặt “niềm tin lầm chỗ” vào dữ liệu của tín hiệu gửi tới. Giá trị dữ liệu có thể quá lớn khiến chương trình chạy sai. Bên cạnh ra lúc chiều dài bằng 0 cũng có thể là 1 dấu hiệu xấu.
Cha bài học lớn dành cho lập trình viên
Về coding
Những lỗi phạm buộc phải trong code? Có buộc phải đã quên 1 else-part? Có buộc phải 1 lệnh gọi hệ thống bị thất bại, nhưng hồi đáp chưa được test? Làm cho sao chỉnh sửa code để giảm thiểu những vấn đề này trong tương lai?
- Trình tự động sự kiện
Lúc xử lý sự kiện, những câu hỏi sau sẽ siêu có ích:
- Liệu sự kiện có thể tới theo trật tự động khác được ko?
- Sẽ thế nào ví dụ ko nhận được sự kiện này? Sẽ thế nào ví dụ sự kiện này diễn ra 2 lần liên tục?
- Thậm chí, ví dụ nó ko bao giờ xảy ra, bugs tại những phần khác của hệ thống (hoặc của những hệ thống khác có tương tác) vẫn có thể khiến cho nó xảy ra.
- Quá sớm
Loại này là 1 trường hợp đặc biệt của phần “Trình tự động sự kiện” tại trên. Nhưng bởi vì nó gây ra 1 số lỗi siêu khó tìm nên nó được đặt ra riêng.
Chẳng hạn, ví dụ tín hiệu nhận được quá sớm, trước lúc những tiến trình thiết lập và khởi động hoàn thành, khả năng chương trình sẽ có những diển tả kỳ lạ.
1 dí dụ khác: Lúc 1 kết nối được đánh dấu là down ngay cả trước lúc nó được đưa vào danh sách idle. Lúc buộc phải tìm lỗi này, chúng ta luôn mặc định rằng nó bị đánh dấu down trong lúc đang tại trong danh sách idle (nhưng lúc đấy tại sao nó ko được lấy ra khỏi danh sách?).
Đấy là 1 sai lầm trong nhận thức của chúng ta lúc ko xét tới trường hợp có những thứ xảy ra quá sớm.
- “Loại chết êm đềm”
1 trong số những lỗi khó tìm ra nhất là lúc chúng lặng lẽ ra đi và chương trình tiếp tục được thực thi mà ko quăng ra exception nào.
Chẳng hạn như những lệnh gọi hệ thống (bind chẳng hạn) trả về mã lỗi nhưng ko được đánh giá.
Hoặc như, phần code để phân tách tín hiệu chỉ đơn giản return lúc bắt gặp 1 thành phần ko hợp lệ, trong lúc đáng lẽ buộc phải quăng lỗi.
Chương trình tiếp tục chạy trong trạng thái sai, khiến cho debug càng khó hơn. Nói chung phải chăng nhất là 1 lỗi nên được quăng ra càng sớm càng phải chăng.
- If
Lệnh if có nhiều điều kiện, if (a or b), đặc biệt là lúc được nối lại có nhau, if (x) else if (y), gây ra quá trời lỗi cho tôi.
Dù cho câu lệnh if về mặt khái niệm quá đơn giản đi, chúng vẫn dễ bị sai lúc có nhiều điều kiện đi kèm.
Thời gian này} tôi cố gắng viết code đơn giản hơn để giảm thiểu buộc phải xử lý những câu if phức tạp.
- Else
Cũng có quá trời lỗi là do ko xét tới trường hợp bỏ qua lệnh else. Sắp như đa số trường hợp, luôn buộc phải có 1 lệnh else cho từng câu if. Hơn nữa, ví dụ bạn đặt 1 biến bên trong lệnh if, khả năng cao là bạn buộc phải đặt nó tại những chỗ khác nữa.
1 dí dụ siêu liên quan là những đoạn lệnh đánh giá cờ (flag). Quá dễ dàng lúc đặt điều kiện để bật cờ, nhưng lại siêu hay quên đặt điều kiện để đặt lại cờ. Để lá cờ bật liên tục có khả năng cao là sẽ có lỗi về sau.
- Thay đổi đổi những giả định
Những lỗi khó phòng giảm thiểu nhất trong giai đoạn đầu thường là do thay đổi đổi giả định.
Chẳng hạn, ban đầu có thể chỉ có 1 sự kiện buyer từng ngày. Thế là siêu nhiều code được viết có giả định này. 1 thời kì sau, thiết kế thay đổi đổi cho phép nhiều sự kiện buyer diễn ra trong ngày. Lúc chuyện này xảy ra, có thể siêu khó để thay đổi đổi hết đa số trường hợp bị liên quan bởi thiết kế new.
Nói chung ko khó để tìm đa số những phần phụ thuộc hiển nhiên. Loại khó là tìm ra những phần phụ thuộc tiềm ẩn bên trong thiết kế cũ.
Chẳng hạn có thể có phần code thu thập đa số sự kiện của prospects trong 1 ngày nhất định. 1 giả định hiển nhiên có thể là kết quả trả về ko bao giờ lớn hơn số lượng prospects.
Tôi ko biết phương pháp nào phải chăng để đề phòng những trường hợp này, ví dụ bạn nào biết thì gợi ý giúp tôi có nhé.
- Logging
Điều tối quan yếu là có nhận thức về những gì chương trình hoạt động, đặc biệt trong những chương trình có logic phức tạp.
Cần dĩ nhiên chắn logging được đặt vừa đủ và đúng chỗ, để bạn có thể lý luận tại sao chương trình lại chạy như vậy.
Lúc mọi thứ hoạt động trơn tru thì ko sao, nhưng ngay lúc chương trình xảy ra lỗi (chuyện ko thể giảm thiểu khỏi), ít ra bạn sẽ thấy sung sướng vì đã logging đúng chỗ.
Xem thêm Nghề lập trình viên quá trau chuốt code là tự động hại mình?
Về Testing
Có những bug rõ ràng nên được “khui” ra ngay trong quy trình check. Trường hợp vậy, phần check nào đã thiếu sót – unit, practical, hay system? Take a look at case nào đã bị thiếu?
- 0 và null
Luôn dĩ nhiên chắn đánh giá có giá trị 0 và null (ví dụ có thể). Đối có chuỗi, cần lưu ý chuỗi rỗng, và chuỗi là null.
1 dí dụ khác: đánh giá trường hợp đứt kết nối TCP trước lúc bất cứ dữ liệu (zero bytes) nào được gửi.
Bỏ qua việc đánh giá những trường hợp trên là nguyên nhân số 1 khiến cho bug lọt khỏi phần check của tôi.
- Thêm vào và xóa đi
Thường những tính năng new sẽ dính tới chuyện thêm những thiết lập new vào hệ thống, chẳng hạn như 1 kiểu định dạng new số điện thoại.
Thường thì bạn sẽ đánh giá xem có thể thêm định dạng new hay ko, nhưng tôi thấy là siêu dễ quên đánh giá trường hợp xóa định dạng cũ.
- Xử lý lỗi
Phần code dùng để xử lý lỗi thường siêu khó đánh giá. Phải chăng nhất là nên có những check tự động động để đánh giá phần này, nhưng đôi lúc việc này trở nên bất khả.
1 mẹo tôi hay dùng là sửa code tạm thời để kích hoạt phần xử lý lỗi. Dễ nhất là lật ngược điều kiện if lại, chẳng hạn như chuyển if error_count > 0 thành if error_count == 0.
1 dí dụ khác là giả vờ viết sai tên 1 column trong database để kích hoạt lỗi.
- Dùng dữ liệu đầu vào ngẫu nhiên
1 phương pháp đánh giá khác có thể dùng để tìm ra bug là dùng dữ liệu đầu vào ngẫu nhiên.
Chẳng hạn như, phần giải mã ASN.1 của giao thức H.323 hoạt động trên dữ liệu nhị phân. Bằng phương pháp gửi những bytes ngẫu nhiên để giải mã, chúng tôi đã tìm ra siêu nhiều lỗi trong phần này.
1 dí dụ khác là tạo ra những cuộc gọi thử nghiệm, có thời kì gọi, độ trễ lúc trả lời, bên nào ngắt máy trước, v.v.. được tạo ra ngẫu nhiên. Những cuộc gọi này khiến lộ ra 1 đống bug, đặt biệt là lúc chúng xen vào những sự kiện xảy ra sắp như cùng lúc.
- Đánh giá hành động ko mong muốn có thực sự KHÔNG diễn ra
Thường testing liên quan tới xem thử hành động mong muốn có xảy ra ko. Nhưng lại siêu dễ bỏ qua trường hợp ngược lại – đánh giá hành động ko mong muốn thực sự ko diễn ra.
- Tự động khiến device
Tôi thường tự động khiến những device bé để check dễ hơn.
Thí dụ, lúc lúc tôi khiến việc có giao thức SIP cho VoIP, tôi viết 1 đoạn mã bé có thể trả lời có headers và giá trị tôi mong muốn. Đoạn mã này giúp tôi đánh giá những trường hợp đặc biệt dễ dàng hơn.
1 dí dụ khác là 1 chương trình dòng lệnh chuyên dùng để gọi API.
Bằng phương pháp khởi đầu bé, và dần dần vươn lên là thêm tính năng cho nó, cuối cùng tôi có trong nay những công cụ siêu hữu dụng. Lợi ích của việc này là tôi có những công cụ đúng như tôi mong muốn.
Xem thêm: Những sai lầm thường gặp của QA/Tester
Về Debugging
Phương pháp nhanh hơn để “khui” bug là gì? Tôi đã dùng đúng device chưa? Có buộc phải tôi đã phỏng đoán quá nhiều? Tôi có cần logging phải chăng hơn ko?
- Thảo luận
Trường hợp bạn hỏi tôi phương pháp hiệu quả nhất để xử lý bug là gì? Tôi sẽ trả lời là thảo luận có đồng nghiệp. Trong lúc tìm phương pháp giải thích cho họ hiểu vấn đề gặp buộc phải là gì, tôi cũng đồng thời hiểu sâu và rõ hơn về nó.
Thêm nữa, dù ko quen thuộc có code trong câu hỏi, thường họ sẽ có mẫu nhìn khách quan để chỉ ra vấn đề có thể phát sinh từ đâu.
Đây là phương pháp cực kì hiệu quả giúp tôi giải quyết những bug khó nhằn nhất.
- Chu đáo tới từng tiểu tiết
Lúc việc debug ngốn quá nhiều thời kì, thì thường là do tôi đã suy đoán sai.
Thí dụ, tôi nghĩ vấn đề xảy ra tại 1 technique nào đấy, trong lúc thực tế ko đời nào chuyện đấy xảy ra.
Hoặc, 1 ngoại lệ xảy ra trái có ngoại lệ tôi suy đoán. Hoặc, tôi nghĩ phần mềm chạy model new nhất, trong lúc thực ra nó lại chạy 1 model cũ hơn.
Cho nên, hãy dĩ nhiên chắn bạn đã đánh giá lại đa số chi tiết thay đổi vì mặc định mọi thứ. Thực dễ để thấy những gì bạn mong muốn thấy, hơn là những gì thực sự tại đấy.
- Thay đổi đổi new nhất
Lúc những thứ từng hoạt động tự động dưng trục trặc, thường là do những thay đổi đổi new nhất gây nên.
Có trường hợp, bạn chỉ thay đổi đổi logging, track 1 lỗi trong logging đã gây nên sự cố lớn hơn nhiều.
Để dễ truy tìm những sự cố kiểu này, bạn nên commit những thay đổi đổi khác nhau trong những commit khác nhau, và ghi chú rõ ràng về việc thay đổi đổi.
- Tin tại khách hàng
Đôi lúc khách hàng report 1 vấn đề nào đấy, ý nghĩ trước tiên của tôi là: Ko thể nào! Chắn chắn họ nhầm lẫn chứ chuyện đấy sao xảy ra được! Nhưng rồi, hóa ra họ đã report đúng.
Những kinh nghiệm thương đau đã dạy tôi rằng: Hãy tin tại khách hàng.
Dĩ nhiên tôi vẫn buộc phải đánh giá lại để xem mọi thứ đã được thiết lập đúng chưa. Nhưng tôi đã gặp siêu nhiều trường hợp kì quặc xảy ra bởi vì 1 thiết lập ko thường gặp, 1 phương pháp dùng ko được dự đoán trước, hay giả định ban đầu của tôi rằng chúng buộc phải như vậy. Và thế là chương trình chạy sai.
- Take a look at phần đã sửa
Sau thời điểm đã sửa xong, bước tiếp theo bạn cần khiến có bug là gì? Lúc bug đã sửa xong thì bạn buộc buộc phải check lại. Trước tiên, hãy chạy code mà ko dùng phần đã sửa và theo dõi bug. Tiếp tục, dùng phần đã sửa và chạy lại check case.
Tuân theo những bước trên sẽ giúp bạn dĩ nhiên chắn bug đấy thực sự là bug, và phần đã sửa thực sự hiệu quả. Đơn giản nhưng cần thiết.
Xem thêm 1 số bài viết hay về Testing:
- QA là gì? QC là gì?
- Automation Tester là gì?
- Những kỹ năng cần thiết để phát triển thành Tester nhiều năm kinh nghiệm.
Trường hợp bạn nghĩ những chia sẻ này có thể giúp ích cho bạn bè hoặc đồng nghiệp thì đừng ngại nhấn nút Share bên dưới nhé!
Và đừng quên tham khảo hàng trăm việc khiến Developer chất trên ITviec!
