Fix Bug Là Gì

Bug là gì? Những lợi ích đến từ việc “chiến đấu” với bug là gì? Đó là một câu hỏi không mấy vui vẻ, bởi có lẽ hầu hết lập trình viên đều muốn làm tính năng mới, chứ chả mấy ai thích phải bảo trì sản phẩm có sẵn hay là fix bug.

Bạn đang xem: Fix bug là gì

Bạn đang xem: Fix bug là gì

Song, với cá thể tôi, việc tìm và fix bug đem lại rất nhiều niềm vui cũng như thời cơ học hỏi, tăng trưởng nghề nghiệp. Sau đây là 1 số ít tổng kết của tôi về :Bug là gì? 4 lợi ích của việc fix bugCách ghi lại bug hiệu quả3 bài học lớn và 18 kinh nghiệm xương máu về fix bugBug là gì ? 4 quyền lợi của việc fix bugCách ghi lại bug hiệu quả3 bài học kinh nghiệm lớn và 18 kinh nghiệm tay nghề xương máu về fix bug

Bạn đang đọc: Fix bug là gì

Xem việc làm Developer chất tại thienmaonline.vn

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 làm cho kết quả không chính xác hoặc không hoạt động như mong muốn. – Theo Wikipedia

Debug là quá trình tìm kiếm và phát hiện lỗi trong phần mềm trước khi launching, đưa sản phẩm đến tay người dùng. Debug diễn ra ngay sau khi những dòng code đầu tiên được viết và tiếp tục được thực hiện cho đến khi kết hợp với những unit khác của lập trình tạo thành một sản phầm phần mềm hoàn chỉnh.

Fixbug (sửa lỗi) là quá trình triển khai ngay sau debug, nhằm duy trì hoặc nâng cao chất lượng sản phẩm.

Lợi ích của việc gặp bug là gì?

Trong mỗi trường hợp, bạn đều hoàn toàn có thể học đôi điều về phong thái lập trình, mẫu sản phẩm hoặc về nghành nghề dịch vụ mà ứng dụng đang hoạt động giải trí .Trên hết, có 4 lí do chính, cũng là 4 niềm vui quan trọng nhất mà việc fix bug hoàn toàn có thể đem lại cho lập trình viên như sau :

Mỗi bug luôn dạy bạn điều gì đó

Feedback luôn là chìa khóa của tăng trưởng mẫu sản phẩm và đồng thời cũng là triết lý cốt lõi của quy mô agile .Cả unit testing và iterative development đều nhằm mục đích đưa ra feedback nhanh hơn. Với unit testing, bạn nhận được feedback về việc code có chạy hay không. Với mỗi release, bạn hoàn toàn có thể lắng nghe feedback của người mua về những tính năng mới .Báo cáo bug cũng là hình thức feedback khác về code của bạn .Có thể có rất nhiều nguyên do gây ra một bug. Ví dụ :Bạn có các câu lệnh if lồng nhau và vô tình lại đặt lệnh else ở sai nhánh.Giả định không chính xác. Chẳng hạn: truy xuất một thuộc tính không tồn tại, thế là dính NullPointerExceptionKhông bao quát hết các trường hợp. Chẳng hạn, bạn phải trả về một giá trị khác đi nếu hàm được gọi với tham số XHoặc, khách hàng sử dụng phần mềm theo cách mà bạn không ngờ tới (nhưng vẫn hợp lệ), và thế là bùm! Dính bug!Bạn có những câu lệnh if lồng nhau và vô tình lại đặt lệnh else ở sai nhánh. Giả định không đúng chuẩn. Chẳng hạn : truy xuất một thuộc tính không sống sót, thế là dính NullPointerExceptionKhông bao quát hết những trường hợp. Chẳng hạn, bạn phải trả về một giá trị khác đi nếu hàm được gọi với tham số XHoặc, người mua sử dụng ứng dụng theo cách mà bạn không ngờ tới ( nhưng vẫn hợp lệ ), và thế là bùm ! Dính bug !Đào sâu khám phá nguyên do gây ra bug, bạn sẽ đúc rút được nhiều bài học kinh nghiệm quý giá .

Code của bạn sẽ dễ debug hơn

Một khi đã phải bỏ sức lực lao động, thời hạn ra để tìm và fix bug, tự khắc bạn sẽ muốn viết code càng dễ debug càng tốt. Bởi vì sẽ rất khốn khổ nếu không có mọi tài liệu thiết yếu .Một yếu tố cực kỳ dễ gặp là những Exceptions ( biệt lệ ) không chứa tài liệu hữu dụng .Ví dụ như, có một đoạn code nhu yếu giá trị từ 0 – 20. Bao nhiêu lần bạn dính exception chỉ vỏn vẹn “ Illegal value ” ? Nó trọn vẹn không giúp gì nếu bạn phải sửa lỗi. Chẳng hạn, nếu như giá trị 21 được nhập vào, exception nên nói là “ Illegal value : 21, not in range 0 – 20 ” .Việc hiển thị giá trị được nhập vào cùng với khoảng chừng giá trị mong ước, rõ ràng vô cùng hữu dụng. Giá trị hiện tại hoàn toàn 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 “ Illegal value ” 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 Complete. Chẳng hạn, trong chương 15, McConnell nêu ra trường hợp phát hiện một kiểu ký tự không mong ước, nhưng thông tin lỗi lại không hiển thị ký tự đó .Như vậy, mỗi khi tìm và fix bug, bạn cần tự hỏi : liệu hoàn toàn có thể biến hóa điều gì trong code để sau này không gặp phải những bug dạng này không ? Liệu có cách nào hoặc điều gì mình nên làm, để sau này tìm ra những bug dạng này thuận tiện hơn không ?Việc làm Developer TP. TP HCMViệc làm Developer TP.HN

Fix bug đem lại niềm vui cho cả bạn và khách hàng

Một trong những niềm vui mà việc làm lập trình mang lại, theo tôi, đó là làm điều có ích cho người khác. Fix bug cũng đem đến niềm vui tương tự như, và thậm chí còn còn nhanh gọn hơn .Bởi lẽ, để tạo ra một tính năng mới cần tốn khá nhiều thời hạn, trong khi việc fix một bug hoàn toàn có thể chỉ cần một giờ đồng hồ đeo tay. Mỗi bug được fix xong sẽ đem đến khoái cảm đã hoàn thành xong / đạt được điều gì. Và đó là một cảm xúc tuyệt vời !Fix bug cũng đem lại niềm vui cho người mua ( dù nghe có vẻ như oái oăm ). Nếu ngay từ đầu không có bug, không phải fix bug, thì chẳng phải người mua sẽ vui hơn sao ?. Nhưng, từ kinh nghiệm tay nghề hơn 20 năm lập trình và “ chiến đấu ” với bug, tôi dám khẳng định chắc chắn : người mua thực sự hài lòng mỗi khi nhận về bug đã được fix xong nhanh gọn .

Vấn đề là vậy: Tất cả 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 fix thật nhanh ngay khi bug được khui ra.

Thư giãn với video : Fix bug “ chất ” như Vinh Râu

Niềm vui của việc giải câu đố

Rất 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 gia những thử thách lập trình .Thậm chí, đọc truyện trinh thám giết người cũng đem lại rất nhiều hứng khởi : bạn lần theo những manh mối để khám phá mọi chuyện đã diễn ra như thế nào .Debug và fix bug cũng vậy. Mỗi bug là một huyền bí cần mày mò .Thông thường, phản ứng tiên phong của bạn khi trông thấy một báo cáo giải trình bug sẽ là : Không thể nào ! Tại sao hoàn toàn có thể xảy ra bug này được ? ! ?Và cũng từ đó, bạn mở màn hành trình dài mày mò huyền bí. Bạn lần theo những manh mối. Logs nói gì ? Có báo cáo lỗi nào từ mạng lưới hệ thống không ? Tại thời gian đó, mạng lưới hệ thống có xảy ra yếu tố gì khác hay không ? Gần đây có cái gì bị đổi khác không – ứng dụng mới, đổi khác thông số kỹ thuật, lưu lượng truy vấn tác động ảnh hưởng ?

Cách hiệu quả nhất để ghi lại bug là gì?

Lý do của việc cần phải ghi lại bug là gì ? Để bạn hoàn toàn có thể học hỏi hiệu suất cao nhất từ những bug bạn đã fix. 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 : miêu tả bug, cách fix, bài học kinh nghiệm kinh nghiệm tay nghề .

Nguyên tắc

Chỉ ghi chú những bug khó nhằn hoặc thực sự thú vị. Đây không 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 khi fix xong. Tránh nhớ nhầm, nhớ không chi tiết.

Cách ghi lại bug

Chỉ ghi chú những bug khó nhằn hoặc thực sự mê hoặc. Đây không 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 đủ mê hoặc ). Ghi lại bug ngay sau khi fix xong. Tránh nhớ nhầm, nhớ không chi tiết cụ thể .Tôi thường dùng form dưới đây để ghi lại bug dưới dạng file text ( bugs.txt ). Bạn hoàn toàn có thể tìm hiểu thêm trải qua ví dụ sau :

Thông tin nền:

Cách sửa – Quá trình sửa:

Sửa: Nếu 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.

Xem thêm: Sailing On Or About Là Gì - Định Nghĩa, Ví Dụ, Giải Thích

Sửa trong file(s): callh/q931_msg.cxxThủ phạm là tôi: Đúng vậy.Thời gian sửa bug: 1 giờ.Nếu chiều dài tìm thấy bằng 0, đặt nó lại bằng 1. Như vậy tất cả chúng ta sẽ luôn đi tiếp được. callh / q931_msg. cxxĐúng vậy. 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 làm chương trình chạy sai. Ngoài ra khi chiều dài bằng 0 cũng có thể là một dấu hiệu xấu.

Ba bài học lớn dành cho lập trình viên

Về coding

Đặt “ niềm tin lầm chỗ ” vào tài liệu của tín hiệu gửi tới. Giá trị tài liệu hoàn toàn có thể quá lớn làm chương trình chạy sai. Ngoài ra khi chiều dài bằng 0 cũng hoàn toàn có thể là một tín hiệu xấu .

Những lỗi phạm phải trong code ? Có phải đã quên một else-part ? Có phải một lệnh gọi mạng lưới hệ thống bị thất bại, nhưng trả lời chưa được check ? Làm sao chỉnh sửa code để tránh những yếu tố này trong tương lai ?Trình tự sự kiệnTrình tự sự kiệnKhi xử lý sự kiện, những câu hỏi sau sẽ rất có ích :Liệu sự kiện có thể đến theo trật tự khác được không?Sẽ thế nào nếu không nhận được sự kiện này? Sẽ thế nào nếu sự kiện này diễn ra hai lần liên tiếp?Thậm chí, nếu nó không bao giờ xảy ra, bugs ở 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 nó xảy ra.Quá sớmLiệu sự kiện hoàn toàn có thể đến theo trật tự khác được không ? Sẽ thế nào nếu không nhận được sự kiện này ? Sẽ thế nào nếu sự kiện này diễn ra hai lần liên tục ? Thậm chí, nếu nó không khi nào xảy ra, bugs ở những phần khác của mạng lưới hệ thống ( hoặc của những mạng lưới hệ thống khác có tương tác ) vẫn hoàn toàn có thể khiến nó xảy ra .Cái này là một trường hợp đặc biệt quan trọng của phần “ Trình tự sự kiện ” ở trên. Nhưng chính bới nó gây ra một số ít lỗi rất khó tìm nên nó được đặt ra riêng .Chẳng hạn, nếu tín hiệu nhận được quá sớm, trước khi những tiến trình thiết lập và khởi động hoàn tất, năng lực chương trình sẽ có những bộc lộ kỳ lạ .Một ví dụ khác : Khi một liên kết được lưu lại là down ngay cả trước khi nó được đưa vào list idle. Khi phải tìm lỗi này, tất cả chúng ta luôn mặc định rằng nó bị ghi lại down trong khi đang ở trong list idle ( nhưng lúc đó tại sao nó không được lấy ra khỏi list ? ) .Đó là một sai lầm đáng tiếc trong nhận thức của tất cả chúng ta khi không xét đến trường hợp có những thứ xảy ra quá sớm .“Cái chết êm đềm”“ Cái chết êm đềm ”Một trong số những lỗi khó phát hiện nhất là khi chúng lặng lẽ ra đi và chương trình liên tục được thực thi mà không quăng ra exception nào .

Xem thêm: Tải Sherlock Holmes: The Devil'S Daughter Full Việt Hóa, Sherlock Holmes

Chẳng hạn như các lệnh gọi hệ thống (bind chẳng hạn) trả về mã lỗi nhưng không được kiểm tra.